rfc3281.txt

PKIX的RFC英文文档

                 which authorization checks are to be made
   Proxying      In this specification, Proxying is used to mean
                 the situation where an application server acts as
                 an application client on behalf of a user.
                 Proxying here does not mean granting of authority.
   PKC           Public Key Certificate - uses the type ASN.1
                 Certificate defined in X.509 and profiled in RFC
                 2459.  This (non-standard) acronym is used in order
                 to avoid confusion about the term "X.509
                 certificate".
   Server        the entity which requires that the authorization
                 checks are made






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


3. Requirements

   This AC profile meets the following requirements.

   Time/Validity requirements:

   1. Support for short-lived as well as long-lived ACs.  Typical
      short-lived validity periods might be measured in hours, as
      opposed to months for PKCs.  Short validity periods allow ACs to
      be useful without a revocation mechanism.

   Attribute Types:

   2. Issuers of ACs should be able to define their own attribute types
      for use within closed domains.

   3. Some standard attribute types, which can be contained within ACs,
      should be defined.  Examples include "access identity," "group,"
      "role," "clearance," "audit identity," and "charging identity."

   4. Standard attribute types should be defined in a manner that
      permits an AC verifier to distinguish between uses of the same
      attribute in different domains.  For example, the "Administrators
      group" as defined by Baltimore and the "Administrators group" as
      defined by SPYRUS should be easily distinguished.

   Targeting of ACs:

   5. It should be possible to "target" an AC at one, or a small number
      of, servers.  This means that a trustworthy non-target server will
      reject the AC for authorization decisions.

   Push vs. Pull

   6. ACs should be defined so that they can either be "pushed" by the
      client to the server, or "pulled" by the server from a repository
      or other network service, including an online AC issuer.

4. Attribute Certificate Profile

   ACs may be used in a wide range of applications and environments
   covering a broad spectrum of interoperability goals and a broader
   spectrum of operational and assurance requirements.  The goal of this
   document is to establish a common baseline for generic applications
   requiring broad interoperability and limited special purpose






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


   requirements.  In particular, the emphasis will be on supporting the
   use of attribute certificates for informal Internet electronic mail,
   IPSec, and WWW applications.

   This section presents a profile for ACs that will foster
   interoperability.  This section also defines some private extensions
   for the Internet community.

   While the ISO/IEC/ITU documents use the 1993 (or later) version of
   ASN.1, this document uses the 1988 ASN.1 syntax, as has been done for
   PKCs [PKIXPROF].  The encoded certificates and extensions from either
   ASN.1 version are bit-wise identical.

   Where maximum lengths for fields are specified, these lengths refer
   to the DER encoding and do not include the ASN.1 tag or length
   fields.

   Conforming implementations MUST support the profile specified in this
   section.

4.1 X.509 Attribute Certificate Definition

   X.509 contains the definition of an AC given below.  All types that
   are not defined in this document can be found in [PKIXPROF].

            AttributeCertificate ::= SEQUENCE {
                 acinfo               AttributeCertificateInfo,
                 signatureAlgorithm   AlgorithmIdentifier,
                 signatureValue       BIT STRING
            }

            AttributeCertificateInfo ::= SEQUENCE {
                 version              AttCertVersion -- version is v2,
                 holder               Holder,
                 issuer               AttCertIssuer,
                 signature            AlgorithmIdentifier,
                 serialNumber         CertificateSerialNumber,
                 attrCertValidityPeriod   AttCertValidityPeriod,
                 attributes           SEQUENCE OF Attribute,
                 issuerUniqueID       UniqueIdentifier OPTIONAL,
                 extensions           Extensions OPTIONAL
            }

            AttCertVersion ::= INTEGER { v2(1) }
            Holder ::= SEQUENCE {
                  baseCertificateID   [0] IssuerSerial OPTIONAL,
                           -- the issuer and serial number of
                           -- the holder's Public Key Certificate



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


                  entityName          [1] GeneralNames OPTIONAL,
                           -- the name of the claimant or role
                  objectDigestInfo    [2] ObjectDigestInfo OPTIONAL
                           -- used to directly authenticate the holder,
                           -- for example, an executable
            }

            ObjectDigestInfo ::= SEQUENCE {
                 digestedObjectType  ENUMERATED {
                         publicKey            (0),
                         publicKeyCert        (1),
                         otherObjectTypes     (2) },
                                 -- otherObjectTypes MUST NOT
                                 -- be used in this profile
                 otherObjectTypeID   OBJECT IDENTIFIER OPTIONAL,
                 digestAlgorithm     AlgorithmIdentifier,
                 objectDigest        BIT STRING
            }

            AttCertIssuer ::= CHOICE {
                 v1Form   GeneralNames,  -- MUST NOT be used in this
                                         -- profile
                 v2Form   [0] V2Form     -- v2 only
            }

            V2Form ::= SEQUENCE {
                 issuerName            GeneralNames  OPTIONAL,
                 baseCertificateID     [0] IssuerSerial  OPTIONAL,
                 objectDigestInfo      [1] ObjectDigestInfo  OPTIONAL
                   -- issuerName MUST be present in this profile
                   -- baseCertificateID and objectDigestInfo MUST NOT
                   -- be present in this profile
            }

            IssuerSerial  ::=  SEQUENCE {
                 issuer         GeneralNames,
                 serial         CertificateSerialNumber,
                 issuerUID      UniqueIdentifier OPTIONAL
            }

            AttCertValidityPeriod  ::= SEQUENCE {
                 notBeforeTime  GeneralizedTime,
                 notAfterTime   GeneralizedTime
            }







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


   Although the Attribute syntax is defined in [PKIXPROF], we repeat
   the definition here for convenience.

            Attribute ::= SEQUENCE {
                  type      AttributeType,
                  values    SET OF AttributeValue
                    -- at least one value is required
            }

            AttributeType ::= OBJECT IDENTIFIER

            AttributeValue ::= ANY DEFINED BY AttributeType

   Implementers should note that the DER encoding (see [X.509-
   1988],[X.208-1988]) of the SET OF values requires ordering of the
   encodings of the values.  Though this issue arises with respect to
   distinguished names, and has to be handled by [PKIXPROF]
   implementations, it is much more significant in this context, since
   the inclusion of multiple values is much more common in ACs.

4.2 Profile of Standard Fields

   GeneralName offers great flexibility.  To achieve interoperability,
   in spite of this flexibility, this profile imposes constraints on the
   use of GeneralName.

   Conforming implementations MUST be able to support the dNSName,
   directoryName, uniformResourceIdentifier, and iPAddress options.
   This is compatible with the GeneralName requirements in [PKIXPROF]
   (mainly in section 4.2.1.7).

   Conforming implementations MUST NOT use the x400Address,
   ediPartyName, or registeredID options.

   Conforming implementations MAY use the otherName option to convey
   name forms defined in Internet Standards.  For example, Kerberos
   [KRB] format names can be encoded into the otherName, using a
   Kerberos 5 principal name OID and a SEQUENCE of the Realm and the
   PrincipalName.

4.2.1   Version

   The version field MUST have the value of v2.  That is, the version
   field is present in the DER encoding.







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


   Note: This version (v2) is not backwards compatible with the previous
   attribute certificate definition (v1) from the 1997 X.509 standard
   [X.509-1997], but is compatible with the v2 definition from X.509
   (2000) [X.509-2000].

4.2.2   Holder

   The Holder field is a SEQUENCE allowing three different (optional)
   syntaxes: baseCertificateID, entityName and objectDigestInfo.  Where
   only one option is present, the meaning of the Holder field is clear.
   However, where more than one option is used, there is a potential for
   confusion as to which option is "normative", which is a "hint" etc.
   Since the correct position is not clear from [X.509-2000], this
   specification RECOMMENDS that only one of the options be used in any
   given AC.

   For any environment where the AC is passed in an authenticated
   message or session and where the authentication is based on the use
   of an X.509 PKC, the holder field SHOULD use the baseCertificateID.

   With the baseCertificateID option, the holder's PKC serialNumber and
   issuer MUST be identical to the AC holder field.  The PKC issuer MUST
   have a non-empty distinguished name which is to be present as the
   single value of the holder.baseCertificateID.issuer construct in the
   directoryName field.  The AC holder.baseCertificateID.issuerUID field
   MUST only be used if the holder's PKC contains an issuerUniqueID
   field.  If both the AC holder.baseCertificateID.issuerUID and the PKC
   issuerUniqueID fields are present, the same value MUST be present in
   both fields.  Thus, the baseCertificateID is only usable with PKC
   profiles (like [PKIXPROF]) which mandate that the PKC issuer field
   contain a non-empty distinguished name value.

   Note: An empty distinguished name is a distinguished name where the
   SEQUENCE OF relative distinguished names is of zero length.  In a DER
   encoding, this has the value '3000'H.

   If the holder field uses the entityName option and the underlying
   authentication is based on a PKC, the entityName MUST be the same as
   the PKC subject field or one of the values of the PKC subjectAltName
   field extension (if present).  Note that [PKIXPROF] mandates that the
   subjectAltName extension be present if the PKC subject is an empty
   distinguished name.  See the security considerations section which
   mentions some name collision problems that may arise when using the
   entityName option.

   In any other case where the holder field uses the entityName option,
   only one name SHOULD be present.




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


   Implementations conforming to this profile are not required to
   support the use of the objectDigest field.  However, section 7.3
   specifies how this optional feature MAY be used.

   Any protocol conforming to this profile SHOULD specify which AC
   holder option is to be used and how this fits with the supported
   authentication schemes defined in that protocol.

4.2.3   Issuer

   ACs conforming to this profile MUST use the v2Form choice, which MUST
   contain one and only one GeneralName in the issuerName, which MUST
   contain a non-empty distinguished name in the directoryName field.
   This means that all AC issuers MUST have non-empty distinguished
   names.  ACs conforming to this profile MUST omit the
   baseCertificateID and objectDigestInfo fields.