rfc2693.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,494 行 · 第 1/5 页

   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.






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


   However, if a SDSI name is ever to occur outside of a certificate,
   the name space within which it is defined must be identified.  This
   gives rise to the Fully Qualified SDSI Name.  That name is a public
   key followed by one or more names relative to that key.  If there are
   two or more names, then the string of names is a SDSI name chain.
   For example,

        (name (hash sha1 |TLCgPLFlGTzgUbcaYLW8kGTEnUk=|) jim therese)

   is a fully qualified SDSI name, using the SHA-1 hash of a public key
   as the global identifier defining the name space and anchoring this
   name string.

2.9 Fully Qualified X.509 Names

   An X.509 Distinguished Name can and sometimes must be expressed as a
   Fully Qualified Name.  If the PEM or original X.500 vision of a
   single root for a global name space had come true, this wouldn't be
   necessary because all names would be relative to that same one root
   key.  However, there is not now and is not likely ever to be a single
   root key.  Therefore, every X.509 name should be expressed as the
   pair

        (name <root key> <leaf name>)

   if all leaf names descending from that root are unique.  If
   uniqueness is enforced only within each individual CA, then one would
   build a Fully Qualified Name chain from an X.509 certificate chain,
   yielding the form

        (name <root key> <CA(1)> <CA(2)> ... <CA(k)> <leaf name>).

2.10 Group Names

   SPKI/SDSI does not claim to enforce one key per name.  Therefore, a
   named group can be defined by issuing multiple (name,key)
   certificates with the same name -- one for each group member.

3. Authorization

   Fully qualified SDSI names represent globally unique names, but at
   every step of their construction the local name used is presumably
   meaningful to the issuer.  Therefore, with SDSI name certificates one
   can identify the keyholder by a name relevant to someone.







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


   However, what an application needs to do, when given a public key
   certificate or a set of them, is answer the question of whether the
   remote keyholder is permitted some access.  That application must
   make a decision.  The data needed for that decision is almost never
   the spelling of a keyholder's name.

   Instead, the application needs to know if the keyholder is authorized
   for some access.  This is the primary job of a certificate, according
   to the members of the SPKI WG, and the SPKI certificate was designed
   to meet this need as simply and directly as possible.

   We realize that the world is not going to switch to SPKI certificates
   overnight.  Therefore, we developed an authorization computation
   process that can use certificates in any format.  That process is
   described below in section 6.

   The various methods of establishing authorization are documented
   below, briefly.  (See also [UPKI])

3.1 Attribute Certificates

   An Attribute Certificate, as defined in X9.57, binds an attribute
   that could be an authorization to a Distinguished Name.  For an
   application to use this information, it must combine an attribute
   certificate with an ID certificate, in order to get the full mapping:

        authorization -> name -> key

   Presumably the two certificates involved came from different issuers,
   one an authority on the authorization and the other an authority on
   names.  However, if either of these issuers were subverted, then an
   attacker could obtain an authorization improperly.  Therefore, both
   the issuers need to be trusted with the authorization decision.

3.2 X.509v3 Extensions

   X.509v3 permits general extensions.  These extensions can be used to
   carry authorization information.  This makes the certificate an
   instrument mapping both:

        authorization -> key

   and

        name -> key

   In this case, there is only one issuer, who must be an authority on
   both the authorization and the name.



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


   Some propose issuing a master X.509v3 certificate to an individual
   and letting extensions hold all the attributes or authorizations the
   individual would need.  This would require the issuer to be an
   authority on all of those authorizations.  In addition, this
   aggregation of attributes would result in shortening the lifetime of
   the certificate, since each attribute would have its own lifetime.
   Finally, aggregation of attributes amounts to the building of a
   dossier and represents a potential privacy violation.

   For all of these reasons, it is desirable that authorizations be
   limited to one per certificate.

3.3 SPKI Certificates

   A basic SPKI certificate defines a straight authorization mapping:

        authorization -> key

   If someone wants access to a keyholder's name, for logging purposes
   or even for punishment after wrong-doing, then one can map from key
   to location information (name, address, phone, ...) to get:

        authorization -> key -> name

   This mapping has an apparent security advantage over the attribute
   certificate mapping.  In the mapping above, only the

        authorization -> key

   mapping needs to be secure at the level required for the access
   control mechanism.  The

        key -> name

   mapping (and the issuer of any certificates involved) needs to be
   secure enough to satisfy lawyers or private investigators, but a
   subversion of this mapping does not permit the attacker to defeat the
   access control.  Presumably, therefore, the care with which these
   certificates (or database entries) are created is less critical than
   the care with which the authorization certificate is issued.  It is
   also possible that the mapping to name need not be on-line or
   protected as certificates, since it would be used by human
   investigators only in unusual circumstances.








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


3.4 ACL Entries

   SDSI 1.0 defined an ACL, granting authorization to names.  It was
   then like an attribute certificate, except that it did not need to be
   signed or issued by any key.  It was held in local memory and was
   assumed issued by the owner of the computer and therefore of the
   resource being controlled.

   In SPKI, an ACL entry is free to be implemented in any way the
   developer chooses, since it is never communicated and therefore does
   not need to be standardized.  However, a sample implementation is
   documented, as a certificate body minus the issuer field.  The ACL
   entry can have a name as a subject, as in SDSI 1.0, or it can have a
   key as a subject.  Examples of the latter include the list of SSL
   root keys in an SSL capable browser or the file .ssh/authorized_keys
   in a user's home UNIX directory.  Those ACLs are single-purpose, so
   the individual entries do not carry explicit authorizations, but SPKI
   uses explicit authorizations so that one can use common authorization
   computation code to deal with multiple applications.

4. Delegation

   One of the powers of an authorization certificate is the ability to
   delegate authorizations from one person to another without bothering
   the owner of the resource(s) involved.  One might issue a simple
   permission (e.g., to read some file) or issue the permission to
   delegate that permission further.

   Two issues arose as we considered delegation: the desire to limit
   depth of delegation and the question of separating delegators from
   those who can exercise the delegated permission.

4.1 Depth of Delegation

   There were three camps in discussing depth of delegation: no control,
   boolean control and integer control.  There remain camps in favor of
   each of these, but a decision was reached in favor of boolean
   control.

4.1.1 No control

   The argument in favor of no control is that if a keyholder is given
   permission to do something but not the permission to delegate it,
   then it is possible for that keyholder to loan out the empowered
   private key or to set up a proxy service, signing challenges or
   requests for the intended delegate.  Therefore, the attempt to
   restrict the permission to delegate is ineffective and might back-
   fire, by leading to improper security practices.



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


4.1.2 Boolean control

   The argument in favor of boolean control is that one might need to
   specify an inability to delegate.  For example, one could imagine the
   US Commerce Department having a key that is authorized to declare a
   cryptographic software module exportable and also to delegate that
   authorization to others (e.g., manufacturers).  It is reasonable to
   assume the Commerce Department would not issue permission to delegate
   this further.  That is, it would want to have a direct legal
   agreement with each manufacturer and issue a certificate to that
   manufacturer only to reflect that the legal agreement is in place.

4.1.3 Integer control

   The argument in favor of integer control is that one might want to
   restrict the depth of delegation in order to control the
   proliferation of a delegated permission.

4.1.4 The choice: boolean

   Of these three, the group chose boolean control.  The subject of a
   certificate or ACL entry may exercise any permission granted and, if
   delegation is TRUE, may also delegate that permission or some subset
   of it to others.

   The no control argument has logical appeal, but there remains the
   assumption that a user will value his or her private key enough not
   to loan it out or that the key will be locked in hardware where it
   can't be copied to any other user.  This doesn't prevent the user
   from setting up a signing oracle, but lack of network connectivity
   might inhibit that mechanism.

   The integer control option was the original design and has appeal,
   but was defeated by the inability to predict the proper depth of
   delegation.  One can always need to go one more level down, by
   creating a temporary signing key (e.g., for use in a laptop).
   Therefore, the initially predicted depth could be significantly off.

   As for controlling the proliferation of permissions, there is no
   control on the width of the delegation tree, so control on its depth
   is not a tight control on proliferation.