rfc2510.txt

PKIX的RFC英文文档

   means.)

   When protection is applied the following structure is used:

     PKIProtection ::= BIT STRING

   The input to the calculation of PKIProtection is the DER encoding of
   the following data structure:

     ProtectedPart ::= SEQUENCE {
         header    PKIHeader,
         body      PKIBody
     }

   There MAY be cases in which the PKIProtection BIT STRING is
   deliberately not used to protect a message (i.e., this OPTIONAL field
   is omitted) because other protection, external to PKIX, will instead
   be applied. Such a choice is explicitly allowed in this
   specification.  Examples of such external protection include PKCS #7
   [PKCS7] and Security Multiparts [RFC1847] encapsulation of the
   PKIMessage (or simply the PKIBody (omitting the CHOICE tag), if the
   relevant PKIHeader information is securely carried in the external
   mechanism); specification of external protection using PKCS #7 will
   be provided in a separate document.  It is noted, however, that many
   such external mechanisms require that the end entity already
   possesses a public-key certificate, and/or a unique Distinguished
   Name, and/or other such infrastructure-related information. Thus,
   they may not be appropriate for initial registration, key-recovery,
   or any other process with "boot-strapping" characteristics.  For
   those cases it may be necessary that the PKIProtection parameter be
   used.  In the future, if/when external mechanisms are modified to
   accommodate boot-strapping scenarios, the use of PKIProtection may
   become rare or non-existent.

   Depending on the circumstances the PKIProtection bits may contain a
   Message Authentication Code (MAC) or signature. Only the following
   cases can occur:




Adams & Farrell             Standards Track                    [Page 23]

RFC 2510          PKI Certificate Management Protocols        March 1999


   - shared secret information

   In this case the sender and recipient share secret information
   (established via out-of-band means or from a previous PKI management
   operation).  PKIProtection will contain a MAC value and the
   protectionAlg will be the following:

     PasswordBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 13}
     PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 recommended)
         iterationCount      INTEGER,
         -- number of times the OWF is applied
         mac                 AlgorithmIdentifier
         -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
     }   -- or HMAC [RFC2104, RFC2202])

   In the above protectionAlg the salt value is appended to the shared
   secret input. The OWF is then applied iterationCount times, where the
   salted secret is the input to the first iteration and, for each
   successive iteration, the input is set to be the output of the
   previous iteration. The output of the final iteration (called
   "BASEKEY" for ease of reference, with a size of "H") is what is used
   to form the symmetric key. If the MAC algorithm requires a K-bit key
   and K <= H, then the most significant K bits of BASEKEY are used. If
   K > H, then all of BASEKEY is used for the most significant H bits of
   the key, OWF("1" || BASEKEY) is used for the next most significant H
   bits of the key, OWF("2" || BASEKEY) is used for the next most
   significant H bits of the key, and so on, until all K bits have been
   derived. [Here "N" is the ASCII byte encoding the number N and "||"
   represents concatenation.]

   - DH key pairs

   Where the sender and receiver possess Diffie-Hellman certificates
   with compatible DH parameters, then in order to protect the message
   the end entity must generate a symmetric key based on its private DH
   key value and the DH public key of the recipient of the PKI message.
   PKIProtection will contain a MAC value keyed with this derived
   symmetric key and the protectionAlg will be the following:










Adams & Farrell             Standards Track                    [Page 24]

RFC 2510          PKI Certificate Management Protocols        March 1999


     DHBasedMac ::= OBJECT IDENTIFIER --{1 2 840 113533 7 66 30}

     DHBMParameter ::= SEQUENCE {
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 recommended)
         mac                 AlgorithmIdentifier
         -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
     }   -- or HMAC [RFC2104, RFC2202])

   In the above protectionAlg OWF is applied to the result of the
   Diffie-Hellman computation. The OWF output (called "BASEKEY" for ease
   of reference, with a size of "H") is what is used to form the
   symmetric key. If the MAC algorithm requires a K-bit key and K <= H,
   then the most significant K bits of BASEKEY are used. If K > H, then
   all of BASEKEY is used for the most significant H bits of the key,
   OWF("1" || BASEKEY) is used for the next most significant H bits of
   the key, OWF("2" || BASEKEY) is used for the next most significant H
   bits of the key, and so on, until all K bits have been derived. [Here
   "N" is the ASCII byte encoding the number N and "||" represents
   concatenation.]

   - signature

   Where the sender possesses a signature key pair it may simply sign
   the PKI message. PKIProtection will contain the signature value and
   the protectionAlg will be an AlgorithmIdentifier for a digital
   signature (e.g., md5WithRSAEncryption or dsaWithSha-1).

   - multiple protection

   In cases where an end entity sends a protected PKI message to an RA,
   the RA MAY forward that message to a CA, attaching its own protection
   (which MAY be a MAC or a signature, depending on the information and
   certificates shared between the RA and the CA). This is accomplished
   by nesting the entire message sent by the end entity within a new PKI
   message. The structure used is as follows.

     NestedMessageContent ::= PKIMessage

3.2 Common Data Structures

   Before specifying the specific types that may be placed in a PKIBody
   we define some data structures that are used in more than one case.








Adams & Farrell             Standards Track                    [Page 25]

RFC 2510          PKI Certificate Management Protocols        March 1999


3.2.1 Requested Certificate Contents

   Various PKI management messages require that the originator of the
   message indicate some of the fields that are required to be present
   in a certificate. The CertTemplate structure allows an end entity or
   RA to specify as much as it wishes about the certificate it requires.
   CertTemplate is identical to a Certificate but with all fields
   optional.

   Note that even if the originator completely specifies the contents of
   a certificate it requires, a CA is free to modify fields within the
   certificate actually issued.  If the modified certificate is
   unacceptable to the requester, the Confirmation message may be
   withheld, or an Error Message may be sent (with a PKIStatus of
   "rejection").

   See [CRMF] for CertTemplate syntax.

3.2.2 Encrypted Values

   Where encrypted values (restricted, in this specification, to be
   either private keys or certificates) are sent in PKI messages the
   EncryptedValue data structure is used.

   See [CRMF] for EncryptedValue syntax.

   Use of this data structure requires that the creator and intended
   recipient respectively be able to encrypt and decrypt. Typically,
   this will mean that the sender and recipient have, or are able to
   generate, a shared secret key.

   If the recipient of the PKIMessage already possesses a private key
   usable for decryption, then the encSymmKey field MAY contain a
   session key encrypted using the recipient's public key.

3.2.3 Status codes and Failure Information for PKI messages

   All response messages will include some status information. The
   following values are defined.

     PKIStatus ::= INTEGER {
         granted                (0),
         -- you got exactly what you asked for
         grantedWithMods        (1),
         -- you got something like what you asked for; the
         -- requester is responsible for ascertaining the differences
         rejection              (2),
         -- you don't get it, more information elsewhere in the message



Adams & Farrell             Standards Track                    [Page 26]

RFC 2510          PKI Certificate Management Protocols        March 1999


         waiting                (3),
         -- the request body part has not yet been processed,
         -- expect to hear more later
         revocationWarning      (4),
         -- this message contains a warning that a revocation is
         -- imminent
         revocationNotification (5),
         -- notification that a revocation has occurred
         keyUpdateWarning       (6)
         -- update already done for the oldCertId specified in
         -- the key update request message
     }

   Responders may use the following syntax to provide more information
   about failure cases.

     PKIFailureInfo ::= BIT STRING {
     -- since we can fail in more than one way!
     -- More codes may be added in the future if/when required.
         badAlg           (0),
         -- unrecognized or unsupported Algorithm Identifier
         badMessageCheck  (1),
         -- integrity check failed (e.g., signature did not verify)
         badRequest       (2),
         -- transaction not permitted or supported
         badTime          (3),
         -- messageTime was not sufficiently close to the system time,
         -- as defined by local policy
         badCertId        (4),
         -- no certificate could be found matching the provided criteria
         badDataFormat    (5),
         -- the data submitted has the wrong format
         wrongAuthority   (6),
         -- the authority indicated in the request is different from the
         -- one creating the response token
         incorrectData    (7),
         -- the requester's data is incorrect (used for notary services)
         missingTimeStamp (8),
         -- when the timestamp is missing but should be there (by policy)
         badPOP           (9)
         -- the proof-of-possession failed
     }
     PKIStatusInfo ::= SEQUENCE {
         status        PKIStatus,
         statusString  PKIFreeText     OPTIONAL,
         failInfo      PKIFailureInfo  OPTIONAL
     }




Adams & Farrell             Standards Track                    [Page 27]

RFC 2510          PKI Certificate Management Protocols        March 1999


3.2.4 Certificate Identification

   In order to identify particular certificates the CertId data
   structure is used.

   See [CRMF] for CertId syntax.

3.2.5 "Out-of-band" root CA public key

   Each root CA must be able to publish its current public key via some
   "out-of-band" means. While such mechanisms are beyond the scope of
   this document, we define data structures which can support such
   mechanisms.

   There are generally two methods available: either the CA directly
   publishes its self-signed certificate; or this information is
   available via the Directory (or equivalent) and the CA publishes a
   hash of this value to allow verification of its integrity before use.

     OOBCert ::= Certificate

   The fields within this certificate are restricted as follows:

   - The certificate MUST be self-signed  (i.e., the signature must be
     verifiable using the SubjectPublicKeyInfo field);
   - The subject and issuer fields MUST be identical;
   - If the subject field is NULL then both subjectAltNames and
     issuerAltNames extensions MUST be present and have exactly the same
     value;
   - The values of all other extensions must be suitable for a self-
     signed certificate (e.g., key identifiers for subject and issuer
     must be the same).

     OOBCertHash ::= SEQUENCE {
         hashAlg     [0] AlgorithmIdentifier     OPTIONAL,
         certId      [1] CertId                  OPTIONAL,
         hashVal         BIT STRING