rfc3281.txt

PKIX的RFC英文文档

   If the crlDistributionPoints extension is present, then exactly one
   distribution point MUST be present.  The crlDistributionPoints
   extension MUST use the DistributionPointName option, which MUST
   contain a fullName, which MUST contain a single name form.  That name
   MUST contain either a distinguished name or a URI.  The URI MUST be
   either an HTTP URL or an LDAP URL [URL].

      name           id-ce-cRLDistributionPoints
      OID            { id-ce 31 }
      syntax         CRLDistPointsSyntax
      criticality    MUST be FALSE

4.3.6   No Revocation Available

   The noRevAvail extension, defined in [X.509-2000], allows an AC
   issuer to indicate that no revocation information will be made
   available for this AC.

   This extension MUST be non-critical.  An AC verifier that does not
   understand this extension might be able to find a revocation list
   from the AC issuer, but the revocation list will never include an
   entry for the AC.

      name           id-ce-noRevAvail
      OID            { id-ce 56 }
      syntax         NULL (i.e. '0500'H is the DER encoding)
      criticality    MUST be FALSE

4.4 Attribute Types

   Some of the attribute types defined below make use of the
   IetfAttrSyntax type, also defined below.  The reasons for using this
   type are:

   1. It allows a separation between the AC issuer and the attribute
      policy authority.  This is useful for situations where a single
      policy authority (e.g. an organization) allocates attribute
      values, but where multiple AC issuers are deployed for performance
      or other reasons.

   2. The syntaxes allowed for values are restricted to OCTET STRING,
      OBJECT IDENTIFIER, and UTF8String, which significantly reduces the
      complexity associated with matching more general syntaxes.  All
      multi-valued attributes using this syntax are restricted so that
      each value MUST use the same choice of value syntax.  For example,
      AC issuers must not use one value with an oid and a second value
      with a string.




Farrell & Housley           Standards Track                    [Page 18]

RFC 3281           An Internet Attribute Certificate          April 2002


               IetfAttrSyntax ::= SEQUENCE {
                    policyAuthority [0] GeneralNames    OPTIONAL,
                    values          SEQUENCE OF CHOICE {
                                  octets    OCTET STRING,
                                  oid       OBJECT IDENTIFIER,
                                  string    UTF8String
                   }
               }

   In the descriptions below, each attribute type is either tagged
   "Multiple Allowed" or "One Attribute value only; multiple values
   within the IetfAttrSyntax".  This refers to the SET OF
   AttributeValues; the AttributeType still only occurs once, as
   specified in section 4.2.7.

4.4.1   Service Authentication Information

   The SvceAuthInfo attribute identifies the AC holder to the
   server/service by a name, and the attribute MAY include optional
   service specific authentication information.  Typically this will
   contain a username/password pair for a "legacy" application.

   This attribute provides information that can be presented by the AC
   verifier to be interpreted and authenticated by a separate
   application within the target system.  Note that this is a different
   use to that intended for the accessIdentity attribute in 4.4.2 below.

   This attribute type will typically be encrypted when the authInfo
   field contains sensitive information, such as a password.

      name      id-aca-authenticationInfo
      OID       { id-aca 1 }
      Syntax    SvceAuthInfo
      values:   Multiple allowed

           SvceAuthInfo ::=    SEQUENCE {
                service   GeneralName,
                ident     GeneralName,
                authInfo  OCTET STRING OPTIONAL
           }

4.4.2   Access Identity

   The accessIdentity attribute identifies the AC holder to the
   server/service.  For this attribute the authInfo field MUST NOT be
   present.





Farrell & Housley           Standards Track                    [Page 19]

RFC 3281           An Internet Attribute Certificate          April 2002


   This attribute is intended to be used to provide information about
   the AC holder, that can be used by the AC verifier (or a larger
   system of which the AC verifier is a component) to authorize the
   actions of the AC holder within the AC verifier's system.  Note that
   this is a different use to that intended for the svceAuthInfo
   attribute described in 4.4.1 above.

      name      id-aca-accessIdentity
      OID       { id-aca 2 }
      syntax    SvceAuthInfo
      values:   Multiple allowed

4.4.3   Charging Identity

   The chargingIdentity attribute identifies the AC holder for charging
   purposes.  In general, the charging identity will be different from
   other identities of the holder.  For example, the holder's company
   may be charged for service.

      name      id-aca-chargingIdentity
      OID       { id-aca 3 }
      syntax    IetfAttrSyntax
      values:   One Attribute value only; multiple values within the
                IetfAttrSyntax

4.4.4   Group

   The group attribute carries information about group memberships of
   the AC holder.

      name      id-aca-group
      OID       { id-aca 4 }
      syntax    IetfAttrSyntax
      values:   One Attribute value only; multiple values within the
                IetfAttrSyntax

4.4.5   Role

   The role attribute, specified in [X.509-2000], carries information
   about role allocations of the AC holder.

   The syntax used for this attribute is:

         RoleSyntax ::= SEQUENCE {
                 roleAuthority   [0] GeneralNames OPTIONAL,
                 roleName        [1] GeneralName
         }




Farrell & Housley           Standards Track                    [Page 20]

RFC 3281           An Internet Attribute Certificate          April 2002


   The roleAuthority field MAY be used to specify the issuing authority
   for the role specification certificate.  There is no requirement that
   a role specification certificate necessarily exists for the
   roleAuthority.  This differs from [X.500-2000], where the
   roleAuthority field is assumed to name the issuer of a role
   specification certificate.  For example, to distinguish the
   administrator role as defined by "Baltimore" from that defined by
   "SPYRUS", one could put the value "urn:administrator" in the roleName
   field and the value "Baltimore" or "SPYRUS" in the roleAuthority
   field.

   The roleName field MUST be present, and roleName MUST use the
   uniformResourceIdentifier CHOICE of the GeneralName.

      name      id-at-role
      OID       { id-at 72 }
      syntax    RoleSyntax
      values:   Multiple allowed

4.4.6   Clearance

   The clearance attribute, specified in [X.501-1993], carries clearance
   (associated with security labeling) information about the AC holder.

   The policyId field is used to identify the security policy to which
   the clearance relates.  The policyId indicates the semantics of the
   classList and securityCategories fields.

   This specification includes the classList field exactly as it is
   specified in [X.501-1993].  Additional security classification
   values, and their position in the classification hierarchy, may be
   defined by a security policy as a local matter or by bilateral
   agreement.  The basic security classification hierarchy is, in
   ascending order: unmarked, unclassified, restricted, confidential,
   secret, and top-secret.

   An organization can develop its own security policy that defines
   security classification values and their meanings.  However, the BIT
   STRING positions 0 through 5 are reserved for the basic security
   classification hierarchy.

   If present, the SecurityCategory field provides further authorization
   information.  The security policy identified by the policyId field
   indicates the syntaxes that are allowed to be present in the
   securityCategories SET.  An OBJECT IDENTIFIER identifies each of the
   allowed syntaxes.  When one of these syntaxes is present in the
   securityCategories SET, the OBJECT IDENTIFIER associated with that
   syntax is carried in the SecurityCategory.type field.



Farrell & Housley           Standards Track                    [Page 21]

RFC 3281           An Internet Attribute Certificate          April 2002


            Clearance  ::=  SEQUENCE {
                 policyId  [0] OBJECT IDENTIFIER,
                 classList [1] ClassList DEFAULT {unclassified},
                 securityCategories
                           [2] SET OF SecurityCategory OPTIONAL
            }

            ClassList  ::=  BIT STRING {
                 unmarked       (0),
                 unclassified   (1),
                 restricted     (2)
                 confidential   (3),
                 secret         (4),
                 topSecret      (5)
            }

            SecurityCategory ::= SEQUENCE {
                 type      [0]  IMPLICIT OBJECT IDENTIFIER,
                 value     [1]  ANY DEFINED BY type
            }

            -- This is the same as the original syntax which was defined
            -- using the MACRO construct, as follows:
            -- SecurityCategory ::= SEQUENCE {
            --      type      [0]  IMPLICIT SECURITY-CATEGORY,
            --      value     [1]  ANY DEFINED BY type
            -- }
            --
            -- SECURITY-CATEGORY MACRO  ::=
            -- BEGIN
            -- TYPE NOTATION ::= type | empty
            -- VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
            -- END



       name      { id-at-clearance }
       OID       { joint-iso-ccitt(2) ds(5) module(1)
                   selected-attribute-types(5) clearance (55) }
       syntax    Clearance - imported from [X.501-1993]
       values    Multiple allowed

4.5 Profile of AC issuer's PKC

   The AC issuer's PKC MUST conform to [PKIXPROF], and the keyUsage
   extension in the PKC MUST NOT explicitly indicate that the AC
   issuer's public key cannot be used to validate a digital signature.
   In order to avoid confusion regarding serial numbers and revocations,



Farrell & Housley           Standards Track                    [Page 22]

RFC 3281           An Internet Attribute Certificate          April 2002


   an AC issuer MUST NOT also be a PKC Issuer.  That is, an AC issuer
   cannot be a CA as well.  So, the AC issuer's PKC MUST NOT have a
   basicConstraints extension with the cA BOOLEAN set to TRUE.

5. Attribute Certificate Validation

   This section describes a basic set of rules that all valid ACs MUST
   satisfy.  Some additional checks are also described which AC
   verifiers MAY choose to implement.

   To be valid an AC MUST satisfy all of the following:

   1. Where the holder uses a PKC to authenticate to the AC verifier,
      the AC holder's PKC MUST be found, and the entire certification
      path of that PKC MUST be verified in accordance with [PKIXPROF].
      As noted in the security considerations section, if some other
      authentication scheme is used, AC verifiers need to be very
      careful mapping the identities (authenticated identity, holder
      field) involved.

   2. The AC signature must be cryptographically correct, and the AC
      issuer's entire PKC certification path MUST be verified in
      accordance with [PKIXPROF].

   3. The AC issuer's PKC MUST also conform to the profile specified in
      section 4.5 above.

   4. The AC issuer MUST be directly trusted as an AC issuer (by
      configuration or otherwise).

   5. The time for which the AC is being evaluated MUST be within the AC
      validity.  If the evaluation time is equal to either notBeforeTime
      or notAfterTime, then the AC is timely and this check succeeds.
      Note that in some applications, the evaluation time MAY not be the
      same as the current time.

   6. The AC targeting check MUST pass as specified in section 4.3.2.