rfc2693.txt

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

        The other work for PGP certificates may include a web-of-trust
        computation.

        The other work for X.509 certificates depends on the written
        documentation for that particular use of X.509 (typically tied
        to the root key from which the certificate descended) and could



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


        involve checking information in the parent certificate as well
        as additional information in extensions of the certificate in
        question.  That is, some use X.509 certificates just to define
        names.  Others use X.509 to communicate an authorization
        implicitly (e.g., SSL server certificates).  Some might define
        extensions of X.509 to carry explicit authorizations.  All of
        these interpretations are specified in written documentation
        associated with the certificate chain and therefore with the
        root from which the chain descends.

        If on-line tests are involved in the certificate processing,
        then the validity dates of those on-line test results are
        intersected by VIntersect() [defined in 6.3.2, below] with the
        validity dates of the certificate to yield the dates in the
        certificate's tuple(s).

    2.  Uses of names are replaced with simple definitions (keys or
        hashes), based on the name definitions available from reducing
        name 4-tuples.

    3.  Authorization 5-tuples are then reduced to a final authorization
        result.

6.1 5-tuple Defined

   The 5-tuple is an intermediate form, assumed to be held in trusted
   memory so that it doesn't need a digital signature for integrity.  It
   is produced from certificates or other credentials via trusted
   software.  Its contents are the same as the contents of an SPKI
   certificate body, but it might be derived from another form of
   certificate or from an ACL entry.

   The elements of a 5-tuple are:

    1.  Issuer: a public key (or its hash), or the reserved word "Self".
        This identifies the entity speaking this intermediate result.

    2.  Subject: a public key (or its hash), a name used to identify a
        public key, the hash of an object or a threshold function of
        subordinate subjects.  This identifies the entity being spoken
        about in this intermediate result.

    3.  Delegation: a boolean.  If TRUE, then the Subject is permitted
        by the Issuer to further propagate the authorization in this
        intermediate result.

    4.  Authorization: an S-expression.  [Rules for combination of
        Authorizations are given below.]



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


    5.  Validity dates: a not-before date and a not-after date, where
        "date" means date and time.  If the not-before date is missing
        from the source credential then minus infinity is assumed.  If
        the not-after date is missing then plus infinity is assumed.

6.2 4-tuple Defined

   A <name,key> certificate (such as X.509v1 or SDSI 1.0) carries no
   authorization field but does carry a name.  Since it is qualitatively
   different from an authorization certificate, a separate intermediate
   form is defined for it.

   The elements of a Name 4-tuple are:

    1.  Issuer: a public key (or its hash).  This identifies the entity
        defining this name in its private name space.

    2.  Name: a byte string

    3.  Subject: a public key (or its hash), a name, or a threshold
        function of subordinate subjects.  This defines the name.

    4.  Validity dates: a not-before date and a not-after date, where
        "date" means date and time.  If the not-before date is missing
        from the source credential then minus infinity is assumed.  If
        the not-after date is missing then plus infinity is assumed.

6.3 5-tuple Reduction Rules

   The two 5-tuples:

      <I1,S1,D1,A1,V1> + <I2,S2,D2,A2,V2>

   yield

         <I1,S2,D2,AIntersect(A1,A2),VIntersect(V1,V2)>

   provided

       the two intersections succeed,

       S1 = I2

   and

       D1 = TRUE





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


   If S1 is a threshold subject, there is a slight modification to this
   rule, as described below in section 6.3.3.

6.3.1 AIntersect

   An authorization is a list of strings or sub-lists, of meaning to and
   probably defined by the application that will use this authorization
   for access control.  Two authorizations intersect by matching,
   element for element.  If one list is longer than the other but match
   at all elements where both lists have elements, then the longer list
   is the result of the intersection.  This means that additional
   elements of a list must restrict the permission granted.

   Although actual authorization string definitions are application
   dependent, AIntersect provides rules for automatic intersection of
   these strings so that application developers can know the semantics
   of the strings they use.  Special semantics would require special
   reduction software.

   For example, there might be an ftpd that allows public key access
   control, using authorization certificates.  Under that service,

       (ftp (host ftp.clark.net))

   might imply that the keyholder would be allowed ftp access to all
   directories on ftp.clark.net, with all kinds of access (read, write,
   delete, ...).  This is more general (allows more access) than

       (ftp (host ftp.clark.net) (dir /pub/cme))

   which would allow all kinds of access but only in the directory
   specified.  The intersection of the two would be the second.

   Since the AIntersect rules imply position dependency, one could also
   define the previous authorization string as:

       (ftp ftp.clark.net /pub/cme)

   to keep the form compact.

   To allow for wild cards, there are a small number of special S-
   expressions defined, using "*" as the expression name.

   (*)
             stands for the set of all S-expressions and byte-strings.
             In other words, it will match anything.  When intersected
             with anything, the result is that other thing.  [The
             AIntersect rule about lists of different length treats a



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


             list as if it had enough (*) entries implicitly appended to
             it to match the length of another list with which it was
             being intersected.]

   (* set <tag-expr>*)
             stands for the set of elements listed in the *-form.

   (* prefix <byte-string>)
             stands for the set of all byte strings that start with the
             one given in the *-form.

   (* range <ordering> <lower-limit>? <upper-limit>?)
             stands for the set of all byte strings lexically (or
             numerically) between the two limits.  The ordering
             parameter (alpha, numeric, time, binary, date) specifies
             the kind of strings allowed.

   AIntersect() is normal set intersection, when *-forms are defined as
   they are above and a normal list is taken to mean all lists that
   start with those elements.  The following examples should give a more
   concrete explanation for those who prefer an explanation without
   reference to set operations.

   AIntersect( (tag (ftp ftp.clark.net cme (* set read write))),
               (tag (*)) )

   evaluates to (tag (ftp ftp.clark.net cme (* set read write)))

   AIntersect( (tag (* set read write (foo bla) delete)),
               (tag (* set write read) ) )

   evaluates to (tag (* set read write))

   AIntersect( (tag (* set read write (foo bla) delete)),
               (tag read ) )

   evaluates to (tag read)

   AIntersect( (tag (* prefix http://www.clark.net/pub/)),
               (tag (* prefix http://www.clark.net/pub/cme/html/)) )

   evaluates to (tag (* prefix http://www.clark.net/pub/cme/html/))

   AIntersect( (tag (* range numeric ge #30# le #39# )), (tag #26#) )

   fails to intersect.





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


6.3.2 VIntersect

   Date range intersection is straight-forward.

       V = VIntersect( X, Y )

   is defined as

       Vmin = max( Xmin, Ymin )

       Vmax = min( Xmax, Ymax )

   and if Vmin > Vmax, then the intersection failed.

   These rules assume that daytimes are expressed in a monotonic form,
   as they are in SPKI.

   The full SPKI VIntersect() also deals with online tests.  In the most
   straight-forward implementation, each online test to which a
   certificate is subject is evaluated.  Each such test carries with it
   a validity interval, in terms of dates.  That validity interval is
   intersected with any present in the certificate, to yield a new,
   current validity interval.

   It is possible for an implementation of VIntersect() to gather up
   online tests that are present in each certificate and include the
   union of all those tests in the accumulating tuples.  In this case,
   the evaluation of those online tests is deferred until the end of the
   process.  This might be appropriate if the tuple reduction is being
   performed not for answering an immediate authorization question but
   rather for generation of a summary certificate (Certificate Result
   Certificate) that one might hope would be useful for a long time.

6.3.3 Threshold Subjects

   A threshold subject is specified by two numbers, K and N [0<K<=N],
   and N subordinate subjects.  A threshold subject is reduced to a
   single subject by selecting K of the N subjects and reducing each of
   those K to the same subject, through a sequence of certificates.  The
   (N-K) unselected subordinate subjects are set to (null).

   The intermediate form for a threshold subject is a copy of the tuple
   in which the threshold subject appears, but with only one of the
   subordinate subjects.  Those subordinate tuples are reduced
   individually until the list of subordinate tuples has (N-K) (null)
   entries and K entries with the same subject.  At that point, those K
   tuples are validity-, authorization- and delegation- intersected to
   yield the single tuple that will replace the list of tuples.



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


6.3.4 Certificate Path Discovery

   All reduction operations are in the order provided by the prover.
   That simplifies the job of the verifier, but leaves the job of
   finding the correct list of reductions to the prover.

   The general algorithm for finding the right certificate paths from a
   large set of unordered certificates has been solved[ELIEN], but might
   be used only rarely.  Each keyholder who is granted some authority
   should receive a sequence of c