rfc3281.txt

PKIX的RFC英文文档

   7. If the AC contains an unsupported critical extension, the AC MUST
      be rejected.

   Support for an extension in this context means:

   1. The AC verifier MUST be able to parse the extension value.

   2. Where the extension value SHOULD cause the AC to be rejected, the
      AC verifier MUST reject the AC.




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


   Additional Checks:

   1. The AC MAY be rejected on the basis of further AC verifier
      configuration.  For example, an AC verifier may be configured to
      reject ACs which contain or lack certain attributes.

   2. If the AC verifier provides an interface that allows applications
      to query the contents of the AC, then the AC verifier MAY filter
      the attributes from the AC on the basis of configured information.
      For example, an AC verifier might be configured not to return
      certain attributes to certain servers.

6. Revocation

   In many environments, the validity period of an AC is less than the
   time required to issue and distribute revocation information.
   Therefore, short-lived ACs typically do not require revocation
   support.  However, long-lived ACs and environments where ACs enable
   high value transactions MAY require revocation support.

   Two revocation schemes are defined, and the AC issuer should elect
   the one that is best suited to the environment in which the AC will
   be employed.

   "Never revoke" scheme:

      ACs may be marked so that the relying party understands that no
      revocation status information will be made available.  The
      noRevAvail extension is defined in section 4.3.6, and the
      noRevAvail extension MUST be present in the AC to indicate use of
      this scheme.

      Where no noRevAvail is present, the AC issuer is implicitly
      stating that revocation status checks are supported, and some
      revocation method MUST be provided to allow AC verifiers to
      establish the revocation status of the AC.

   "Pointer in AC" scheme:

      ACs may "point" to sources of revocation status information, using
      either an authorityInfoAccess extension or a crlDistributionPoints
      extension within the AC.

   For AC users, the "never revoke" scheme MUST be supported, and the
   "pointer in AC" scheme SHOULD be supported.  If only the "never
   revoke" scheme is supported, then all ACs that do not contain a
   noRevAvail extension, MUST be rejected.




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


   For AC issuers, the "never revoke" scheme MUST be supported.  If all
   ACs that will ever be issued by that AC issuer, contains a noRevAvail
   extension, the "pointer in AC" scheme need not be supported.  If any
   AC can be issued that does not contain the noRevAvail extension, the
   "pointer in AC" scheme MUST be supported.

   An AC MUST NOT contain both a noRevAvail and a "pointer in AC".

   An AC verifier MAY use any source for AC revocation status
   information.

7. Optional Features

   This section specifies features that MAY be implemented.  Conformance
   to this profile does NOT require support for these features; however,
   if these features are offered, they MUST be offered as described
   below.

7.1 Attribute Encryption

   Where an AC will be carried in clear within an application protocol
   or where an AC contains some sensitive information like a legacy
   application username/password, then encryption of AC attributes MAY
   be needed.

   When a set of attributes are to be encrypted within an AC, the
   Cryptographic Message Syntax, EnvelopedData structure [CMS] is used
   to carry the ciphertext and associated per-recipient keying
   information.

   This type of attribute encryption is targeted.  Before the AC is
   signed, the attributes are encrypted for a set of predetermined
   recipients.

   The AC then contains the ciphertext inside its signed data.  The
   EnvelopedData (id-envelopedData) ContentType is used, and the content
   field will contain the EnvelopedData type.

   The ciphertext is included in the AC as the value of an encAttrs
   attribute.  Only one encAttrs attribute can be present in an AC;
   however, the encAttrs attribute MAY be multi-valued, and each of its
   values will contain an independent EnvelopedData.

   Each value can contain a set of attributes (each possibly a multi-
   valued attribute) encrypted for a set of predetermined recipients.






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


   The cleartext that is encrypted has the type:

      ACClearAttrs ::= SEQUENCE {
           acIssuer  GeneralName,
           acSerial  INTEGER,
           attrs     SEQUENCE OF Attribute
      }

   The DER encoding of the ACClearAttrs structure is used as the
   encryptedContent field of the EnvelopedData.  The DER encoding MUST
   be embedded in an OCTET STRING.

   The acIssuer and acSerial fields are present to prevent ciphertext
   stealing.  When an AC verifier has successfully decrypted an
   encrypted attribute, it MUST then check that the AC issuer and
   serialNumber fields contain the same values.  This prevents a
   malicious AC issuer from copying ciphertext from another AC (without
   knowing its corresponding plaintext).

   The procedure for an AC issuer when encrypting attributes is
   illustrated by the following (any other procedure that gives the same
   result MAY be used):

      1.   Identify the sets of attributes that are to be encrypted for
           each set of recipients.
      2.   For each attribute set which is to be encrypted:
         2.1. Create an EnvelopedData structure for the data for this
              set of recipients.
         2.2. Encode the ContentInfo containing the EnvelopedData as a
              value of the encAttrs attribute.
         2.3. Ensure the cleartext attributes are not present in the
              to-be-signed AC.
      3.   Add the encAttrs (with its multiple values) to the AC.

   Note that there may be more than one attribute of the same type (the
   same OBJECT IDENTIFIER) after decryption.  That is, an AC MAY contain
   the same attribute type both in clear and in encrypted form (and
   indeed several times if the same recipient is associated with more
   than one EnvelopedData).  One approach implementers may choose, would
   be to merge attribute values following decryption in order to re-
   establish the "once only" constraint.

      name      id-aca-encAttrs
      OID       { id-aca 6}
      Syntax    ContentInfo
      values    Multiple Allowed





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


   If an AC contains attributes, apparently encrypted for the AC
   verifier, the decryption process MUST not fail.  If decryption does
   fail, the AC MUST be rejected.

7.2 Proxying

   When a server acts as a client for another server on behalf of the AC
   holder, the server MAY need to proxy an AC.  Such proxying MAY have
   to be done under the AC issuer's control, so that not every AC is
   proxiable and so that a given proxiable AC can be proxied in a
   targeted fashion.  Support for chains of proxies (with more than one
   intermediate server) MAY also be required.  Note that this does not
   involve a chain of ACs.

   In order to meet this requirement we define another extension,
   ProxyInfo, similar to the targeting extension.

   When this extension is present, the AC verifier must check that the
   entity from which the AC was received was allowed to send it and that
   the AC is allowed to be used by this verifier.

   The proxying information consists of a set of proxy information, each
   of which is a set of targeting information.  If the verifier and the
   sender of the AC are both named in the same proxy set, the AC can
   then be accepted (the exact rule is given below).

   The effect is that the AC holder can send the AC to any valid target
   which can then only proxy to targets which are in one of the same
   proxy sets as itself.

   The following data structure is used to represent the
   targeting/proxying information.

         ProxyInfo ::= SEQUENCE OF Targets

   As in the case of targeting, the targetCert CHOICE MUST NOT be used.

   A proxy check succeeds if either one of the conditions below is met:

   1. The identity of the sender, as established by the underlying
      authentication service, matches the holder field of the AC, and
      the current server "matches" any one of the proxy sets.  Recall
      that "matches" is as defined section 4.3.2.








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


   2. The identity of the sender, as established by the underlying
      authentication service, "matches" one of the proxy sets (call it
      set "A"), and the current server is one of the targetName fields
      in the set "A", or the current server is a member of one of the
      targetGroup fields in set "A".

   When an AC is proxied more than once, a number of targets will be on
   the path from the original client, which is normally, but not always,
   the AC holder.  In such cases, prevention of AC "stealing" requires
   that the AC verifier MUST check that all targets on the path are
   members of the same proxy set.  It is the responsibility of the AC-
   using protocol to ensure that a trustworthy list of targets on the
   path is available to the AC verifier.

      name           id-pe-ac-proxying
      OID            { id-pe 10 }
      syntax         ProxyInfo
      criticality    MUST be TRUE

7.3 Use of ObjectDigestInfo

   In some environments, it may be required that the AC is not linked
   either to an identity (via entityName) or to a PKC (via
   baseCertificateID).  The objectDigestInfo CHOICE in the holder field
   allows support for this requirement.

   If the holder is identified with the objectDigestInfo field, then the
   AC version field MUST contain v2 (the integer 1).

   The idea is to link the AC to an object by placing a hash of that
   object into the holder field of the AC.  For example, this allows
   production of ACs that are linked to public keys rather than names.
   It also allows production of ACs which contain privileges associated
   with an executable object such as a Java class.  However, this
   profile only specifies how to use a hash over a public key or PKC.
   That is, conformant ACs MUST NOT use the otherObjectTypes value for
   the digestedObjectType.

   To link an AC to a public key, the hash must be calculated over the
   representation of that public key which would be present in a PKC,
   specifically, the input for the hash algorithm MUST be the DER
   encoding of a SubjectPublicKeyInfo representation of the key.  Note:
   This includes the AlgorithmIdentifier as well as the BIT STRING.  The
   rules given in [PKIXPROF] for encoding keys MUST be followed.  In
   this case, the digestedObjectType MUST be publicKey and the
   otherObjectTypeID field MUST NOT be present.





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


   Note that if the public key value used as input to the hash function
   has been extracted from a PKC, it is possible that the
   SubjectPublicKeyInfo from that PKC is NOT the value which should be
   hashed.  This can occur if DSA Dss-parms are inherited as described
   in section 7.3.3 of [PKIXPROF].  The correct input for hashing in
   this context will include the value of the parameters inherited from
   the CA's PKC, and thus may differ from the SubjectPublicKeyInfo
   present in the PKC.

   Implementations which support this feature MUST be able to handle the
   representations of public keys for the algorithms specified in
   section 7.3 of [PKIXPROF].  In this case, the digestedObjectType MUST
   be publicKey and the otherObjectTypeID field MUST NOT be present.

   In order to link an AC to a PKC via a digest, the digest MUST be
   calculated over the DER encoding of the entire PKC, including the
   signature value.  In this case the digestedObjec