rfc3281.txt

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

   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.

   Part of the reason for the use of the v2Form containing only an
   issuerName is that it means that the AC issuer does not have to know
   which PKC the AC verifier will use for it (the AC issuer).  Using the
   baseCertificateID field to reference the AC issuer would mean that
   the AC verifier would have to trust the PKC that the AC issuer chose
   (for itself) at AC creation time.

4.2.4   Signature

   Contains the algorithm identifier used to validate the AC signature.

   This MUST be one of the signing algorithms defined in [PKIXALGS].
   Conforming implementations MUST honor all MUST/SHOULD/MAY signing
   algorithm statements specified in [PKIXALGS].

4.2.5   Serial Number

   For any conforming AC, the issuer/serialNumber pair MUST form a
   unique combination, even if ACs are very short-lived.

   AC issuers MUST force the serialNumber to be a positive integer, that
   is, the sign bit in the DER encoding of the INTEGER value MUST be
   zero - this can be done by adding a leading (leftmost) '00'H octet if
   necessary.  This removes a potential ambiguity in mapping between a
   string of octets and an integer value.

   Given the uniqueness and timing requirements above, serial numbers
   can be expected to contain long integers.  AC users MUST be able to
   handle serialNumber values longer than 4 octets.  Conformant ACs MUST
   NOT contain serialNumber values longer than 20 octets.




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


   There is no requirement that the serial numbers used by any AC issuer
   follow any particular ordering.  In particular, they need not be
   monotonically increasing with time.  Each AC issuer MUST ensure that
   each AC that it issues contains a unique serial number.

4.2.6   Validity Period

   The attrCertValidityPeriod (a.k.a. validity) field specifies the
   period for which the AC issuer certifies that the binding between the
   holder and the attributes fields will be valid.

   The generalized time type, GeneralizedTime, is a standard ASN.1 type
   for variable precision representation of time.  The GeneralizedTime
   field can optionally include a representation of the time
   differential between the local time zone and Greenwich Mean Time.

   For the purposes of this profile, GeneralizedTime values MUST be
   expressed in Coordinated universal time (UTC) (also known as
   Greenwich Mean Time or Zulu)) and MUST include seconds (i.e., times
   are YYYYMMDDHHMMSSZ), even when the number of seconds is zero.
   GeneralizedTime values MUST NOT include fractional seconds.

   (Note: this is the same as specified in [PKIXPROF], section
   4.1.2.5.2.)

   AC users MUST be able to handle an AC which, at the time of
   processing, has parts of its validity period or all its validity
   period in the past or in the future (a post-dated AC).  This is valid
   for some applications, such as backup.

4.2.7   Attributes

   The attributes field gives information about the AC holder.  When the
   AC is used for authorization, this will often contain a set of
   privileges.

   The attributes field contains a SEQUENCE OF Attribute.  Each
   Attribute MAY contain a SET OF values.  For a given AC, each
   AttributeType OBJECT IDENTIFIER in the sequence MUST be unique.  That
   is, only one instance of each attribute can occur in a single AC, but
   each instance can be multi-valued.

   AC users MUST be able to handle multiple values for all attribute
   types.

   An AC MUST contain at least one attribute.  That is, the SEQUENCE OF
   Attributes MUST NOT be of zero length.




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


   Some standard attribute types are defined in section 4.4.

4.2.8   Issuer Unique Identifier

   This field MUST NOT be used unless it is also used in the AC issuer's
   PKC, in which case it MUST be used.  Note that [PKIXPROF] states that
   this field SHOULD NOT be used by conforming CAs, but that
   applications SHOULD be able to parse PKCs containing the field.

4.2.9   Extensions

   The extensions field generally gives information about the AC as
   opposed to information about the AC holder.

   An AC that has no extensions conforms to the profile; however,
   section 4.3 defines the extensions that MAY be used with this
   profile, and whether or not they may be marked critical.  If any
   other critical extension is used, the AC does not conform to this
   profile.  However, if any other non-critical extension is used, the
   AC does conform to this profile.

   The extensions defined for ACs provide methods for associating
   additional attributes with holders.  This profile also allows
   communities to define private extensions to carry information unique
   to those communities.  Each extension in an AC may be designated as
   critical or non-critical.  An AC using system MUST reject an AC if it
   encounters a critical extension it does not recognize; however, a
   non-critical extension may be ignored if it is not recognized.
   Section 4.3 presents recommended extensions used within Internet ACs
   and standard locations for information.  Communities may elect to use
   additional extensions; however, caution should be exercised in
   adopting any critical extensions in ACs which might prevent use in a
   general context.

4.3 Extensions

4.3.1   Audit Identity

   In some circumstances, it is required (e.g. by data protection/data
   privacy legislation) that audit trails not contain records which
   directly identify individuals.  This circumstance may make the use of
   the AC holder field unsuitable for use in audit trails.

   To allow for such cases, an AC MAY contain an audit identity
   extension.  Ideally it SHOULD be infeasible to derive the AC holder's
   identity from the audit identity value without the cooperation of the
   AC issuer.




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


   The value of the audit identity, along with the AC issuer/serial,
   SHOULD then be used for audit/logging purposes.  If the value of the
   audit identity is suitably chosen, a server/service administrator can
   use audit trails to track the behavior of an AC holder without being
   able to identify the AC holder.

   The server/service administrator in combination with the AC issuer
   MUST be able to identify the AC holder in cases where misbehavior is
   detected.  This means that the AC issuer MUST be able to determine
   the actual identity of the AC holder from the audit identity.

   Of course, auditing could be based on the AC issuer/serial pair;
   however, this method does not allow tracking of the same AC holder
   with multiple ACs.  Thus, an audit identity is only useful if it
   lasts for longer than the typical AC lifetime.  Auditing could also
   be based on the AC holder's PKC issuer/serial; however, this will
   often allow the server/service administrator to identify the AC
   holder.

   As the AC verifier might otherwise use the AC holder or some other
   identifying value for audit purposes, this extension MUST be critical
   when used.

   Protocols that use ACs will often expose the identity of the AC
   holder in the bits on-the-wire.  In such cases, an opaque audit
   identity does not make use of the AC anonymous; it simply ensures
   that the ensuing audit trails do not contain identifying information.

   The value of an audit identity MUST be longer than zero octets.  The
   value of an audit identity MUST NOT be longer than 20 octets.

      name           id-pe-ac-auditIdentity
      OID            { id-pe 4 }
      syntax         OCTET STRING
      criticality    MUST be TRUE

4.3.2   AC Targeting

   To target an AC, the target information extension, imported from
   [X.509-2000], MAY be used to specify a number of servers/services.
   The intent is that the AC SHOULD only be usable at the specified
   servers/services.  An (honest) AC verifier who is not amongst the
   named servers/services MUST reject the AC.

   If this extension is not present, the AC is not targeted and may be
   accepted by any server.





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


   In this profile, the targeting information simply consists of a list
   of named targets or groups.

   The following syntax is used to represent the targeting information:

            Targets ::= SEQUENCE OF Target

            Target  ::= CHOICE {
              targetName          [0] GeneralName,
              targetGroup         [1] GeneralName,
              targetCert          [2] TargetCert
            }

            TargetCert  ::= SEQUENCE {
              targetCertificate    IssuerSerial,
              targetName           GeneralName OPTIONAL,
              certDigestInfo       ObjectDigestInfo OPTIONAL
            }

   The targetCert CHOICE within the Target structure is only present to
   allow future compatibility with [X.509-2000] and MUST NOT be used.

   The targets check passes if the current server (recipient) is one of
   the targetName fields in the Targets SEQUENCE, or if the current
   server is a member of one of the targetGroup fields in the Targets
   SEQUENCE.  In this case, the current server is said to "match" the
   targeting extension.

   How the membership of a target within a targetGroup is determined is
   not defined here.  It is assumed that any given target "knows" the
   names of the targetGroups to which it belongs or can otherwise
   determine its membership.  For example, the targetGroup specifies a
   DNS domain, and the AC verifier knows the DNS domain to which it
   belongs.  For another example, the targetGroup specifies "PRINTERS,"
   and the AC verifier knows whether or not it is a printer or print
   server.

   Note: [X.509-2000] defines the extension syntax as a "SEQUENCE OF
   Targets".  Conforming AC issuer implementations MUST only produce one
   "Targets" element.  Confirming AC users MUST be able to accept a
   "SEQUENCE OF Targets".  If more than one Targets element is found in
   an AC, the extension MUST be treated as if all Target elements had
   been found within one Targets element.

      name           id-ce-targetInformation
      OID            { id-ce 55 }
      syntax         SEQUENCE OF Targets
      criticality    MUST be TRUE



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


4.3.3   Authority Key Identifier

   The authorityKeyIdentifier extension, as profiled in [PKIXPROF], MAY
   be used to assist the AC verifier in checking the signature of the
   AC.  The [PKIXPROF] description should be read as if "CA" meant "AC
   issuer."  As with PKCs, this extension SHOULD be included in ACs.

   Note: An AC, where the issuer field used the baseCertificateID
   CHOICE, would not need an authorityKeyIdentifier extension, as it is
   explicitly linked to the key in the referred certificate.  However,
   as this profile states (in section 4.2.3), ACs MUST use the v2Form
   with issuerName CHOICE, this duplication does not arise.

      name           id-ce-authorityKeyIdentifier
      OID            { id-ce 35 }
      syntax         AuthorityKeyIdentifier
      criticality    MUST be FALSE

4.3.4   Authority Information Access

   The authorityInformationAccess extension, as defined in [PKIXPROF],
   MAY be used to assist the AC verifier in checking the revocation
   status of the AC.  Support for the id-ad-caIssuers accessMethod is
   NOT REQUIRED by this profile since AC chains are not expected.

   The following accessMethod is used to indicate that revocation status
   checking is provided for this AC, using the OCSP protocol defined in
   [OCSP]:

      id-ad-ocsp OBJECT IDENTIFIER ::= { id-ad 1 }

   The accessLocation MUST contain a URI, and the URI MUST contain an
   HTTP URL [URL] that specifies the location of an OCSP responder.  The
   AC issuer MUST, of course, maintain an OCSP responder at this