rfc2693.txt

中、英文RFC文档大全打包下载完全版 .

   Ten years after Kohnfelder's thesis, the ISO X.509 recommendation was
   published as part of X.500.  X.500 was to be a global, distributed
   database of named entities: people, computers, printers, etc.  In
   other words, it was to be a global, on-line telephone book.  The
   organizations owning some portion of the name space would maintain
   that portion and possibly even provide the computers on which it was
   stored.  X.509 certificates were defined to bind public keys to X.500
   path names (Distinguished Names) with the intention of noting which
   keyholder had permission to modify which X.500 directory nodes.  In
   fact, the X.509 data record was originally designed to hold a
   password instead of a public key as the record-access authentication
   mechanism.

   The original X.500 plan is unlikely ever to come to fruition.
   Collections of directory entries (such as employee lists, customer
   lists, contact lists, etc.) are considered valuable or even
   confidential by those owning the lists and are not likely to be
   released to the world in the form of an X.500 directory sub-tree.
   For an extreme example, imagine the CIA adding its directory of
   agents to a world-wide X.500 pool.

   The X.500 idea of a distinguished name (a single, globally unique
   name that everyone could use when referring to an entity) is also not
   likely to occur.  That idea requires a single, global naming
   discipline and there are too many entities already in the business of
   defining names not under a single discipline.  Legacy therefore
   militates against such an idea.



Ellison, et al.               Experimental                      [Page 6]

RFC 2693                SPKI Certificate Theory           September 1999


2.3 X.509, PEM and PGP

   The Privacy Enhanced Mail [PEM] effort of the Internet Engineering
   Task Force [RFC1114] adopted X.509 certificates, but with a different
   interpretation.  Where X.509 was originally intended to mean "the
   keyholder may modify this portion of the X.500 database", PEM took
   the certificate to mean "the key speaks for the named person".  What
   had been an access control instrument was now an identity instrument,
   along the lines envisioned by Diffie, Hellman and Kohnfelder.

   The insistence on X.509 certificates with a single global root
   delayed PEM's adoption past its window of viability.  RIPEM, by Mark
   Riordan of MSU, was a version of PEM without X.509 certificates.  It
   was distributed and used by a small community, but fell into disuse.
   MOSS (a MIME-enhanced version of PEM, produced by TIS (www.tis.com))
   made certificate use optional, but received little distribution.

   At about the same time, in 1991, Phil Zimmermann's PGP was introduced
   with a different certificate model.  Instead of waiting for a single
   global root and the hierarchy of Certificate Authorities descending
   from that root, PGP allowed multiple, (hopefully) independent but not
   specially trusted individuals to sign a <name,key> association,
   attesting to its validity.  The theory was that with enough such
   signatures, that association could be trusted because not all of
   these signer would be corrupt.  This was known as the "web of trust"
   model.  It differed from X.509 in the method of assuring trust in the
   <name,key> binding, but it still intended to bind a globally unique
   name to a key.  With PEM and PGP, the intention was for a keyholder
   to be known to anyone in the world by this certified global name.

2.4 Rethinking Global Names

   The assumption that the job of a certificate was to bind a name to a
   key made sense when it was first published.  In the 1970's, people
   operated in relatively small communities.  Relationships formed face
   to face.  Once you knew who someone was, you often knew enough to
   decide how to behave with that person.  As a result, people have
   reduced this requirement to the simply stated: "know who you're
   dealing with".

   Names, in turn, are what we humans use as identifiers of persons.  We
   learn this practice as infants.  In the family environment names work
   as identifiers, even today.  What we learn as infants is especially
   difficult to re-learn later in life.  Therefore, it is natural for
   people to translate the need to know who the keyholder is into a need
   to know the keyholder's name.





Ellison, et al.               Experimental                      [Page 7]

RFC 2693                SPKI Certificate Theory           September 1999


   Computer applications need to make decisions about keyholders.  These
   decisions are almost never made strictly on the basis of a
   keyholder's name.  There is some other fact about the keyholder of
   interest to the application (or to the human being running the
   application).  If a name functions at all for security purposes, it
   is as an index into some database (or human memory) of that other
   information.  To serve in this role, the name must be unique, in
   order to serve as an index, and there must be some information to be
   indexed.

   The names we use to identify people are usually unique, within our
   local domain, but that is not true on a global scale.  It is
   extremely unlikely that the name by which we know someone, a given
   name, would function as a unique identifier on the Internet.  Given
   names continue to serve the social function of making the named
   person feel recognized when addressed by name but they are inadequate
   as the identifiers envisioned by Diffie, Hellman and Kohnfelder.

   In the 1970's and even through the early 1990's, relationships formed
   in person and one could assume having met the keyholder and therefore
   having acquired knowledge about that person.  If a name could be
   found that was an adequate identifier of that keyholder, then one
   might use that name to index into memories about the keyholder and
   then be able to make the relevant decision.

   In the late 1990's, this is no longer true.  With the explosion of
   the Internet, it is likely that one will encounter keyholders who are
   complete strangers in the physical world and will remain so.  Contact
   will be made digitally and will remain digital for the duration of
   the relationship.  Therefore, on first encounter there is no body of
   knowledge to be indexed by any identifier.

   One might consider building a global database of facts about all
   persons in the world and making that database available (perhaps for
   a fee).  The name that indexes that database might also serve as a
   globally unique ID for the person referenced.  The database entry
   under that name could contain all the information needed to allow
   someone to make a security decision.  Since there are multiple
   decision-makers, each interested in specific information, the
   database would need to contain the union of multiple sets of
   information.  However, that solution would constitute a massive
   privacy violation and would probably be rejected as politically
   impossible.

   A globally unique ID might even fail when dealing with people we do
   know.  Few of us know the full given names of people with whom we
   deal.  A globally unique name for a person would be larger than the
   full given name (and probably contain it, out of deference to a



Ellison, et al.               Experimental                      [Page 8]

RFC 2693                SPKI Certificate Theory           September 1999


   person's fondness for his or her own name).  It would therefore not
   be a name by which we know the person, barring a radical change in
   human behavior.

   A globally unique ID that contains a person's given name poses a
   special danger.  If a human being is part of the process (e.g.,
   scanning a database of global IDs in order to find the ID of a
   specific person for the purpose of issuing an attribute certificate),
   then it is likely that the human operator would pay attention to the
   familiar portion of the ID (the common name) and pay less attention
   to the rest.  Since the common name is not an adequate ID, this can
   lead to mistakes.  Where there can be mistakes, there is an avenue
   for attack.

   Where globally unique identifiers need to be used, perhaps the best
   ID is one that is uniform in appearance (such as a long number or
   random looking text string) so that it has no recognizable sub-field.
   It should also be large enough (from a sparse enough name space) that
   typographical errors would not yield another valid identifier.

2.5 Inescapable Identifiers

   Some people speak of global IDs as if they were inescapable
   identifiers, able to prevent someone from doing evil under one name,
   changing his name and starting over again.  To make that scenario
   come true, one would have to have assignment of such identifiers
   (probably by governments, at birth) and some mechanism so that it is
   always possible to get from any flesh and blood person back to his or
   her identifier.  Given that latter mechanism, any Certificate
   Authority desiring to issue a certificate to a given individual would
   presumably choose the same, inescapable name for that certificate.  A
   full set of biometrics might suffice, for example, to look up a
   person without danger of false positive in a database of globally
   assigned ID numbers and with that procedure one could implement
   inescapable IDs.

   The use of an inescapable identifier might be possible in some
   countries, but in others (such as the US) it would meet strong
   political opposition.  Some countries have government-assigned ID
   numbers for citizens but also have privacy regulations that prohibit
   the use of those numbers for routine business.  In either of these
   latter cases, the inescapable ID would not be available for use in
   routine certificates.

   There was a concern that commercial Certificate Authorities might
   have been used to bring inescapable names into existence, bypassing
   the political process and the opposition to such names in those
   countries where such opposition is strong.  As the (name,key)



Ellison, et al.               Experimental                      [Page 9]

RFC 2693                SPKI Certificate Theory           September 1999


   certificate business is evolving today, there are multiple competing
   CAs each creating disjoint Distinguished Name spaces.  There is also
   no real block to the creation of new CAs.  Therefore a person is able
   to drop one Distinguished Name and get another, by changing CA,
   making these names not inescapable.

2.6 Local Names

   Globally unique names may be politically undesirable and relatively
   useless, in the world of the Internet, but we use names all the time.

   The names we use are local names.  These are the names we write in
   our personal address books or use as nicknames or aliases with e-mail
   agents.  They can be IDs assigned by corporations (e.g., bank account
   numbers or employee numbers).  Those names or IDs do not need to be
   globally unique.  Rather, they need to be unique for the one entity
   that maintains that address book, e-mail alias file or list of
   accounts.  More importantly, they need to be meaningful to the person
   who uses them as indexes.

   Ron Rivest and Butler Lampson showed with SDSI 1.0 [SDSI] that one
   can not only use local names locally, one can use local names
   globally.  The clear security advantage and operational simplicity of
   SDSI names caused us in the SPKI group to adopt SDSI names as part of
   the SPKI standard.

2.6.1 Basic SDSI Names

   A basic SDSI 2.0 name is an S-expression with two elements: the word
   "name" and the chosen name.  For example,

        george:  (name fred)

   represents a basic SDSI name "fred" in the name space defined by
   george.

2.6.2 Compound SDSI Names

   If fred in turn defines a name, for example,

        fred:  (name sam)

   then george can refer to this same entity as

        george:  (name fred sam)






Ellison, et al.               Experimental                     [Page 10]

RFC 2693                SPKI Certificate Theory           September 1999


2.7 Sources of Global Identifiers

   Even though humans use local names, computer systems often need
   globally unique identifiers.  Even in the examples of section 2.6.2
   above, we needed to make the local names more global and did so by
   specifying the name-space owner.

   If we are using public key cryptography, we have a ready source of
   globally unique identifiers.

   When one creates a key pair, for use in public key cryptography, the
   private key is bound to its owner by good key safeguarding practice.
   If that private key gets loose from its owner, then a basic premise
   of public key cryptography has been violated and that key is no
   longer of interest.

   The private key is also globally unique.  If it were not, then the
   key generation process would be seriously flawed and we would have to
   abandon this public key system implementation.

   The private key must be kept secret, so it is not a possible
   identifier, but each public key corresponds to one private key and
   therefore to one keyholder.  The public key, viewed as a byte string,
   is therefore an identifier for the keyholder.

   If there exists a collision-free hash function, then a collision-free
   hash of the public key is also a globally unique identifier for the
   keyholder, and probably a shorter one than the public key.

2.8 Fully Qualified SDSI Names

   SDSI local names are of great value to their definer.  Each local
   name maps to one or more public keys and therefore to the
   corresponding keyholder(s).  Through SDSI's name chaining, these
   local names become useful potentially to the whole world.  [See
   section 2.6.2 for an example of SDSI name chaining.]

   To a computer system making use of these names, the name string is
   not enough.  One must identify the name space in which that byte
   string is defined.  That name space can be identified globally by a
   public key.

   It is SDSI 1.0 convention, preserved in SPKI, that if a (local) SDSI
   name occurs within a certificate, then the public key of the issuer
   is the identifier of the name space in which that name is defined.