rfc2693.txt

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

   The argument for delegated authorization as opposed to ACLs can be
   seen in the following example.

   Imagine a firewall proxy permitting telnet and ftp access from the
   Internet into a network of US DoD machines.  Because of the
   sensitivity of that destination network, strong access control would
   be desired.  One could use public key authentication and public key
   certificates to establish who the individual keyholder was.  Both the
   private key and the keyholder's certificates could be kept on a
   Fortezza card.  That card holds X.509v1 certificates, so all that can
   be established is the name of the keyholder.  It is then the job of
   the firewall to keep an ACL, listing named keyholders and the forms
   of access they are each permitted.

   Consider the ACL itself.  Not only would it be potentially huge,
   demanding far more storage than the firewall would otherwise require,
   but it would also need its own ACL.  One could not, for example, have
   someone in the Army have the power to decide whether someone in the
   Navy got access.  In fact, the ACL would probably need not one level
   of its own ACL, but a nested set of ACLs, eventually reflecting the
   organization structure of the entire Defense Department.

   Without the ACLs, the firewall could be implemented in a device with
   no mass storage, residing in a sealed unit one could easily hold in
   one hand.  With the ACLs, it would need a large mass storage device
   that would be accessed not only while making access control decisions
   but also for updating the ACLs.

   By contrast, let the access be controlled by authorization
   certificates.  The firewall would have an ACL with one entry,
   granting a key belonging to the Secretary of Defense the right to
   delegate all access through the firewall.  The Secretary would, in



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


   turn, issue certificates delegating this permission to delegate to
   each of his or her subordinates.  This process would iterate, until
   some enlisted man would receive permission to penetrate that firewall
   for some specific one protocol, but not have permission to delegate
   that permission.

   The certificate structure generated would reflect the organization
   structure of the entire Defense Department, just as the nested ACLs
   would have, but the control of these certificates (via their issuance
   and revocation) is distributed and need not show up in that one
   firewall or be replicated in all firewalls.  Each individual
   delegator of permission performs a simple task, well understood.  The
   application software to allow that delegation is correspondingly
   simple.

5. Validity Conditions

   A certificate, or an ACL entry, has optional validity conditions.
   The traditional ones are validity dates: not-before and not-after.
   The SPKI group resolved, in discussion, that on-line tests of various
   kinds are also validity conditions.  That is, they further refine the
   valid date range of a certificate.  Three kinds of on-line tests are
   envisioned: CRL, re-validation and one-time.

   When validity confirmation is provided by some online test, then the
   issuer of those refinements need not be the issuer of the original
   certificate.  In many cases, the business or security model for the
   two issuers is different.  However, in SPKI, the certificate issuer
   must specify the issuer of validity confirmations.

5.1 Anti-matter CRLs

   An early form of CRL [Certificate Revocation List] was modeled after
   the news print book that used to be kept at supermarket checkout
   stands.  Those books held lists of bad checking account numbers and,
   later, bad credit card numbers.  If one's payment instrument wasn't
   listed in the book, then that instrument was considered good.

   These books would be issued periodically, and delivered by some means
   not necessarily taking a constant time.  However, when a new book
   arrived, the clerk would replace the older edition with the new one
   and start using it.  This design was suited to the constraints of the
   implementation: use of physical books, delivered by physical means.
   The book held bad account numbers rather than good ones because the
   list of bad accounts was smaller.






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


   An early CRL design followed this model.  It had a list of revoked
   certificate identifiers.  It also had a sequence number, so that one
   could tell which of two CRLs was more recent.  A newer CRL would
   replace an older one.

   This mode of operation is like wandering anti-matter.  When the
   issuer wants to revoke a certificate, it is listed in the next CRL to
   go out.  If the revocation is urgent, then that CRL can be released
   immediately.  The CRL then follows some dissemination process
   unrelated to the needs of the consumers of the CRL.  If the CRL
   encounters a certificate it has listed, it effectively annihilates
   that certificate.  If it encounters an older CRL, it annihilates that
   CRL also, leaving a copies of itself at the verifiers it encounters.

   However, this process is non-deterministic.  The result of the
   authorization computation is at least timing dependent.  Given an
   active adversary, it can also be a security hole.  That is, an
   adversary can prevent revocation of a given certificate by preventing
   the delivery of new CRLs.  This does not require cryptographic level
   effort, merely network tampering.

   SPKI has ruled out the use of wandering anti-matter CRLs for its
   certificates.  Every authorization computation is deterministic,
   under SPKI rules.

5.2 Timed CRLs

   SPKI permits use of timed CRLs.  That is, if a certificate can be
   referenced in a CRL, then the CRL process is subject to three
   conditions.

   1.  The certificate must list the key (or its hash) that will sign
       the CRL and may give one or more locations where that CRL might
       be fetched.

   2.  The CRL must carry validity dates.

   3.  CRL validity date ranges must not intersect.  That is, one may
       not issue a new CRL to take effect before the expiration of the
       CRL currently deployed.

   Under these rules, no certificate that might use a CRL can be
   processed without a valid CRL and no CRL can be issued to show up as
   a surprise at the verifier.  This yields a deterministic validity
   computation, independent of clock skew, although clock inaccuracies
   in the verifier may produce a result not desired by the issuer.  The
   CRL in this case is a completion of the certificate, rather than a
   message to the world announcing a change of mind.



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


   Since CRLs might get very large and since they tend to grow
   monotonically, one might want to issue changes to CRLs rather than
   full ones.  That is, a CRL might be a full CRL followed by a sequence
   of delta-CRLs.  That sequence of instruments is then treated as a
   current CRL and the combined CRL must follow the conditions listed
   above.

5.3 Timed Revalidations

   CRLs are negative statements.  The positive version of a CRL is what
   we call a revalidation.  Typically a revalidation would list only one
   certificate (the one of interest), although it might list a set of
   certificates (to save digital signature effort).

   As with the CRL, SPKI demands that this process be deterministic and
   therefore that the revalidation follow the same rules listed above
   (in section 5.2).

5.4 Setting the Validity Interval

   Both timed CRLs and timed revalidations have non-0 validity
   intervals.  To set this validity interval, one must answer the
   question: "How long are you willing to let the world believe and act
   on a statement you know to be false?"

   That is, one must assume that the previous CRL or revalidation has
   just been signed and transmitted to at least one consumer, locking up
   a time slot.  The next available time slot starts after this validity
   interval ends.  That is the earliest one can revoke a certificate one
   learns to be false.

   The answer to that question comes from risk management.  It will
   probably be based on expected monetary losses, at least in commercial
   cases.

5.5 One-time Revalidations

   Validity intervals of length zero are not possible.  Since
   transmission takes time, by the time a CRL was received by the
   verifier, it would be out of date and unusable.  That assumes perfect
   clock synchronization.  If clock skew is taken into consideration,
   validity intervals need to be that much larger to be meaningful.

   For those who want to set the validity interval to zero, SPKI defines
   a one-time revalidation.






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


   This form of revalidation has no lifetime beyond the current
   authorization computation.  One applies for this on-line, one-time
   revalidation by submitting a request containing a nonce.  That nonce
   gets returned in the signed revalidation instrument, in order to
   prevent replay attacks.  This protocol takes the place of a validity
   date range and represents a validity interval of zero, starting and
   ending at the time the authorization computation completes.

5.6 Short-lived Certificates

   A performance analysis of the various methods of achieving fine-grain
   control over the validity interval of a certificate should consider
   the possibility of just making the original certificate short-lived,
   especially if the online test result is issued by the same key that
   issued the certificate.  There are cases in which the short-lived
   certificate requires fewer signatures and less network traffic than
   the various online test options.  The use of a short-lived
   certificate always requires fewer signature verifications than the
   use of certificate plus online test result.

   If one wants to issue short-lived certificates, SPKI defines a kind
   of online test statement to tell the user of the certificate where a
   replacement short-lived certificate might be fetched.

5.7 Other possibilities

   There are other possibilities to be considered when choosing a
   validity condition model to use.

5.7.1 Micali's Inexpensive On-line Results

   Silvio Micali has patented a mechanism for using hash chains to
   revalidate or revoke a certificate inexpensively.  This mechanism
   changes the performance requirements of those models and might
   therefore change the conclusion from a performance analysis [ECR].

5.7.2 Rivest's Reversal of the CRL Logic

   Ron Rivest has written a paper [R98] suggesting that the whole
   validity condition model is flawed because it assumes that the issuer
   (or some entity to which it delegates this responsibility) decides
   the conditions under which a certificate is valid.  That traditional
   model is consistent with a military key management model, in which
   there is some central authority responsible for key release and for
   determining key validity.






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


   However, in the commercial space, it is the verifier and not the
   issuer who is taking a risk by accepting a certificate.  It should
   therefore be the verifier who decides what level of assurance he
   needs before accepting a credential.  That verifier needs information
   from the issuer, and the more recent that information the better, but
   the decision is the verifier's in the end.

   This line of thought deserves further consideration, but is not
   reflected in the SPKI structure definition.  It might even be that
   both the issuer and the verifier have stakes in this decision, so
   that any replacement validity logic would have to include inputs from
   both.

6. Tuple Reduction

   The processing of certificates and related objects to yield an
   authorization result is the province of the developer of the
   application or system.  The processing plan presented here is an
   example that may be followed, but its primary purpose is to clarify
   the semantics of an SPKI certificate and the way it and various other
   kinds of certificate might be used to yield an authorization result.

   There are three kinds of entity that might be input to the
   computation that yields an authorization result:

    1.  <name,key> (as a certificate)

    2.  <authorization,name> (as an attribute certificate or ACL entry)

    3.  <authorization,key> (as an authorization certificate or ACL
        entry)

   These entities are processed in three stages.

    1.  Individual certificates are verified by checking their
        signatures and possibly performing other work.  They are then
        mapped to intermediate forms, called "tuples" here.

        The other work for SPKI or SDSI certificates might include
        processing of on-line test results (CRL, re-validation or one-
        time validation).