rfc2693.txt

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

   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).

        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