[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-spki-cert-examples-00.txt
On Fri, 5 Dec 1997 Internet-Drafts@ns.ietf.org wrote:
-> A New Internet-Draft is available from the on-line Internet-Drafts directories.
-> This draft is a work item of the Simple Public Key Infrastructure Working Group
-> of the IETF.
-> Title : SPKI Examples
-> Author(s) : B. Lampson, T. Ylonen, R. Rivest, W. Frantz,
-> C. Ellison, B. Thomas
-> Filename : draft-ietf-spki-cert-examples-00.txt
-> Pages : 9
-> Date : 04-Dec-97
I think that the document has serious flaws and should be ammended, as
well as the document draft-ietf-spki-cert-theory-00.txt (on which it is
based and already previously commented). Specifically, my comments are
given below for each point.
-> With the proliferation of public key cryptography on the Internet,
-> there arises a need for certification of keys. In the literature,
-> the word ''certificate'' has generally been taken to mean ''identity
-> certificate'': a signed statement which binds a key to the name of an
This is wrong. In the technical literature (eg, A. Menezes et al., Handook
of Applied Cryptography, CRC Press, New York, 1997), certification is
defined as "endorsement of information by a trusted entity", where
"endorsement" can take several meanings as defined by a CPS and
"information" can be any data, such as a photo, a pseudonym, an alias, a
key, a birth name, a X.509 DN, an e-mail, etc. Further, X.509 (and PGP)
clearly lay out several purposes besides name binding for certificates, as
given by the extensions in X.509v3, including authorizations such as the
possibility to be used as a root-cert for signing other certs, etc.
Further, X.509 (the standard alluded to as "generally") does not say that
"it binds a key to the name of an individual". Here, there are actually
three entities and respective bindings: key, name, individual. The
definitions of key, name and their binding are handled by X.509, whereas
the binding of either with an individual (and the respective
qualifications of the individual) are handled by the CA's CPS -- which is
outside the scope of X.509. The same happens for PGP.
In other words, when X.509 certifies names in DNs, it does not certify
"foo real-world" but certifies "foo real-world data" -- where the
distinction is that "foo real-world data" has no semantics on the data
being valid or not, because the data are just being used as data (ie,
copied as received) and as such compared with the DN. Here, X.509 does
not attempt to reach behind names to individuals, for example to verify if
"foo real-world" and the DN are consistent. That is outside the scope of
X.509 and is handled by the CPS.
-> and has the intended meaning of delegating authority from
-> that named individual to the public key. (See, for example, RFC
-> 1422.) This process is designed to copy a relationship between two
-> entities from the physical world into the digital world.
No, the intended meaning (and the design reasoning) of certificates such
as X.509 (and PGP) is to provide for a security framework to be reached as
a function of the various CPSs and how they are to be interpreted by each
-> The Internet itself changed the world from the one in which identity
-> certificates made sense.
This is neither new nor an Internet fenomenum. [cf Bohm] Even in those
countries where the law requires that every person should have an official
name, it is doubtful that any two people would never have the same name,
even within one country. And there are many countries, such as the United
Kingdom, where people can change their names without formality or official
records, and can use several names for different purposes, none of which
are more truly theirs than any other. (Authors and entertainers commonly
use several names).
-> We now deal with people we have never met
-> and never will, which makes their names meaningless to us, but we
-> still need to verify whether they are authorized to perform some
-> action, achieve some access, sign some document, etc.
-> SPKI certificates were designed to perform that function by directly
-> specifying the <permission,key> binding which is of interest in the
-> digital world.
This is a contradiction. The first paragraph says that we need to verify
whether "people" are authorized to perform some action, whereas the second
paragraph says that such verification will be performed on a "key".
These are two entirely different concepts because for SPKI certificates
there is no identity other than the key (there is no entity
authentication, just key authentication) and all actions are performed
only in the digital world of keys. So, SPKI has no binding between digital
world entities and physical world (ie, legal, accountable) entities -- ie,
the "people" mentioned in the first paragraph (which are of interest for
Net commerce, EDI, bank operations, etc.). To contrast, X.509 allows for
such binding to exist and to be defined by each CA under its CPS policies,
allowing for miscreants to be legally persecuted.
(These problems are not to be solved by SPKI, but by a "subpoena
certificate" as Carl Ellison has named it, which is a service to be paid
for by the user and which will be treated in the future. Which has nothing
to do with the SPKI proposal and which certainly brings up problems of its
-> As merged with SDSI, the current certificate format
-> also allows someone to bind a key to a name in their own private name
-> space. The certificate structure presented here allows permissions
-> to be delegated to SDSI-named individuals or to raw keys.
Use of "their own private name space" means that the SDSI name space is
local -- which can be equally accomplished by using the certificate
structure of X.509 or PGP, with aliases or pseudonyms. Of course, local
names can only be locally meaningful and must be always isolated from any
global context (where they may even collide) such as a legal framework --
which makes them useless in a world PKI. Further, permissions delegated to
SDSI-named individuals or to raw keys have no legal or accountable meaning
to outside parties and could only be useful in a parochial Internet.
Dr.rer.nat. E. Gerck firstname.lastname@example.org