7.  Version Negotiation

   This section defines the version negotiation used to support older
   protocols between client and servers.

   If a client knows the protocol version(s) supported by the server
   (e.g., from a previous PKIMessage exchange or via some out-of-band
   means), then it MUST send a PKIMessage with the highest version
   supported by both it and the server.  If a client does not know what
   version(s) the server supports, then it MUST send a PKIMessage using
   the highest version it supports.

   If a server receives a message with a version that it supports, then
   the version of the response message MUST be the same as the received
   version.  If a server receives a message with a version higher or
   lower than it supports, then it MUST send back an ErrorMsg with the
   unsupportedVersion bit set (in the failureInfo field of the
   pKIStatusInfo).  If the received version is higher than the highest
   supported version, then the version in the error message MUST be the
   highest version the server supports; if the received version is lower
   than the lowest supported version then the version in the error
   message MUST be the lowest version the server supports.

   If a client gets back an ErrorMsgContent with the unsupportedVersion
   bit set and a version it supports, then it MAY retry the request with
   that version.

7.1.  Supporting RFC 2510 Implementations

   RFC 2510 did not specify the behaviour of implementations receiving
   versions they did not understand since there was only one version in
   existence.  With the introduction of the present revision of the
   specification, the following versioning behaviour is recommended.

7.1.1.  Clients Talking to RFC 2510 Servers

   If, after sending a cmp2000 message, a client receives an
   ErrorMsgContent with a version of cmp1999, then it MUST abort the
   current transaction.  It MAY subsequently retry the transaction using
   version cmp1999 messages.

   If a client receives a non-error PKIMessage with a version of
   cmp1999, then it MAY decide to continue the transaction (if the
   transaction hasn't finished) using RFC 2510 semantics.  If it does
   not choose to do so and the transaction is not finished, then it MUST
   abort the transaction and send an ErrorMsgContent with a version of
   cmp1999.

7.1.2.  Servers Receiving Version cmp1999 PKIMessages

   If a server receives a version cmp1999 message it MAY revert to RFC
   2510 behaviour and respond with version cmp1999 messages.  If it does
   not choose to do so, then it MUST send back an ErrorMsgContent as
   described above in Section 7.

8.  Security Considerations

8.1.  Proof-Of-Possession with a Decryption Key

   Some cryptographic considerations are worth explicitly spelling out.
   In the protocols specified above, when an end entity is required to
   prove possession of a decryption key, it is effectively challenged to
   decrypt something (its own certificate).  This scheme (and many
   others!) could be vulnerable to an attack if the possessor of the
   decryption key in question could be fooled into decrypting an
   arbitrary challenge and returning the cleartext to an attacker.
   Although in this specification a number of other failures in security
   are required in order for this attack to succeed, it is conceivable
   that some future services (e.g., notary, trusted time) could
   potentially be vulnerable to such attacks.  For this reason, we re-
   iterate the general rule that implementations should be very careful
   about decrypting arbitrary "ciphertext" and revealing recovered
   "plaintext" since such a practice can lead to serious security
   vulnerabilities.

8.2.  Proof-Of-Possession by Exposing the Private Key

   Note also that exposing a private key to the CA/RA as a proof-of-
   possession technique can carry some security risks (depending upon
   whether or not the CA/RA can be trusted to handle such material
   appropriately).  Implementers are advised to:

      Exercise caution in selecting and using this particular POP
      mechanism

      When appropriate, have the user of the application explicitly
      state that they are willing to trust the CA/RA to have a copy of
      their private key before proceeding to reveal the private key.

8.3.  Attack Against Diffie-Hellman Key Exchange

   A small subgroup attack during a Diffie-Hellman key exchange may be
   carried out as follows.  A malicious end entity may deliberately
   choose D-H parameters that enable him/her to derive (a significant
   number of bits of) the D-H private key of the CA during a key
   archival or key recovery operation.  Armed with this knowledge, the

   EE would then be able to retrieve the decryption private key of
   another unsuspecting end entity, EE2, during EE2's legitimate key
   archival or key recovery operation with that CA.  In order to avoid
   the possibility of such an attack, two courses of action are
   available.  (1) The CA may generate a fresh D-H key pair to be used
   as a protocol encryption key pair for each EE with which it

   interacts.  (2) The CA may enter into a key validation protocol (not
   specified in this document) with each requesting end entity to ensure
   that the EE's protocol encryption key pair will not facilitate this
   attack.  Option (1) is clearly simpler (requiring no extra protocol
   exchanges from either party) and is therefore RECOMMENDED.

9.  IANA Considerations

   The PKI General Message types are identified by object identifiers
   (OIDs).  The OIDs for the PKI General Message types defined in this
   document were assigned from an arc delegated by the IANA to the PKIX
   Working Group.

   The cryptographic algorithms referred to in this document are
   identified by object identifiers (OIDs).  The OIDs for cryptographic
   algorithms were assigned from several arcs owned by various
   organizations, including RSA Security, Entrust Technologies, IANA and
   IETF.

   Should additional encryption algorithms be introduced, the advocates
   for such algorithms are expected to assign the necessary OIDs from
   their own arcs.

   No further action by the IANA is necessary for this document or any
   anticipated updates.

Normative References

   [X509]       International Organization for Standardization and
                International Telecommunications Union, "Information
                technology - Open Systems Interconnection - The
                Directory:  Public-key and attribute certificate
                frameworks", ISO Standard 9594-8:2001, ITU-T
                Recommendation X.509, March 2000.

   [MvOV97]     Menezes, A., van Oorschot, P. and S. Vanstone, "Handbook
                of Applied Cryptography", CRC Press ISBN 0-8493-8523-7,
                1996.

   [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
                Keyed-Hashing for Message Authentication", RFC 2104,
                February 1997.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2202]    Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
                HMAC-SHA-1", RFC 2202, September 1997.

   [RFC3629]    Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, November 2003.

   [RFC2482]    Whistler, K. and G. Adams, "Language Tagging in Unicode
                Plain Text", RFC 2482, January 1999.

   [CRMF]       Schaad, J., "Internet X.509 Public Key Infrastructure
                Certificate Request Message Format (CRMF)", RFC 4211,
                September 2005.

   [RFC3066]    Alvestrand, H., "Tags for the Identification of
                Languages", BCP 47, RFC 3066, January 2001.

Informative References

   [CMPtrans]   Kapoor, A., Tschalar, R. and T. Kause, "Internet X.509
                Public Key Infrastructure -- Transport Protocols for
                CMP", Work in Progress.  2004.

   [PKCS7]      RSA Laboratories, "The Public-Key Cryptography Standards
                - Cryptographic Message Syntax Standard.  Version 1.5",
                PKCS 7, November 1993.

   [PKCS10]     Nystrom, M., and B. Kaliski, "The Public-Key
                Cryptography Standards - Certification Request Syntax
                Standard, Version 1.7", RFC 2986, May 2000.

   [PKCS11]     RSA Laboratories, "The Public-Key Cryptography Standards
                - Cryptographic Token Interface Standard.  Version
                2.10", PKCS 11, December 1999.

   [RFC1847]    Galvin, J., Murphy, S., Crocker, S., and N. Freed,
                "Security Multiparts for MIME: Multipart/Signed and
                Multipart/Encrypted", RFC 1847, October 1995.

   [RFC2559]    Boeyen, S., Howes, T. and P. Richard, "Internet X.509
                Public Key Infrastructure Operational Protocols -
                LDAPv2", RFC 2559, April 1999.

   [RFC2585]    Housley, R. and P. Hoffman, "Internet X.509 Public Key
                Infrastructure Operational Protocols: FTP and HTTP", RFC
                2585, May 1999.

   [FIPS-180]   National Institute of Standards and Technology, "Secure
                Hash Standard", FIPS PUB 180-1, May 1994.

   [FIPS-186]   National Institute of Standards and Technology, "Digital
                Signature Standard", FIPS PUB 186, May 1994.

   [ANSI-X9.42] American National Standards Institute, "Public Key
                Cryptography for The Financial Services Industry:
                Agreement of Symmetric Keys Using Discrete Logarithm
                Cryptography", ANSI X9.42, February 2000.

Appendix A.  Reasons for the Presence of RAs

   The reasons that justify the presence of an RA can be split into
   those that are due to technical factors and those which are
   organizational in nature.  Technical reasons include the following.

   o  If hardware tokens are in use, then not all end entities will have
      the equipment needed to initialize these; the RA equipment can
      include the necessary functionality (this may also be a matter of
      policy).

   o  Some end entities may not have the capability to publish
      certificates; again, the RA may be suitably placed for this.

   o  The RA will be able to issue signed revocation requests on behalf
      of end entities associated with it, whereas the end entity may not
      be able to do this (if the key pair is completely lost).

   Some of the organizational reasons that argue for the presence of an
   RA are the following.

   o  It may be more cost effective to concentrate functionality in the
      RA equipment than to supply functionality to all end entities
      (especially if special token initialization equipment is to be
      used).

   o  Establishing RAs within an organization can reduce the number of
      CAs required, which is sometimes desirable.

   o  RAs may be better placed to identify people with their
      "electronic" names, especially if the CA is physically remote from
      the end entity.

   o  For many applications, there will already be in place some
      administrative structure so that candidates for the role of RA are
      easy to find (which may not be true of the CA).

Appendix B.  The Use of Revocation Passphrase

   A revocation request must incorporate suitable security mechanisms,
   including proper authentication, in order to reduce the probability
   of successful denial-of-service attacks.  A digital signature on the
   request -- MANDATORY to support within this specification if
   revocation requests are supported -- can provide the authentication
   required, but there are circumstances under which an alternative
   mechanism may be desirable (e.g., when the private key is no longer
   accessible and the entity wishes to request a revocation prior to
   re-certification of another key pair).  In order to accommodate such

   circumstances, a PasswordBasedMAC on the request is also MANDATORY to
   support within this specification (subject to local security policy
   for a given environment) if revocation requests are supported and if
   shared secret information can be established between the requester
   and the responder prior to the need for revocation.

   A mechanism that has seen use in some environments is "revocation
   passphrase", in which a value of sufficient entropy (i.e., a
   relatively long passphrase rather than a short password) is shared
   between (only) the entity and the CA/RA at some point prior to
   revocation; this value is later used to authenticate the revocation
   request.

   In this specification, the following technique to establish shared
   secret information (i.e., a revocation passphrase) is OPTIONAL to
   support.  Its precise use in CMP messages is as follows.

   o  The OID and value specified in Section 5.3.19.9 MAY be sent in a
      GenMsg message at any time, or MAY be sent in the generalInfo
      field of the PKIHeader of any PKIMessage at any time.  (In
      particular, the EncryptedValue may be sent in the header of the
      certConf message that confirms acceptance of certificates
      requested in an initialization request or certificate request
      message.)  This conveys a revocation passphrase chosen by the
      entity (i.e., the decrypted bytes of the encValue field) to the
      relevant CA/RA; furthermore, the transfer is accomplished with
      appropriate confidentiality characteristics (because the
      passphrase is encrypted under the CA/RA's protocolEncryptionKey).

   o  If a CA/RA receives the revocation passphrase (OID and value
      specified in Section 5.3.19.9) in a GenMsg, it MUST construct and
      send a GenRep message that includes the OID (with absent value)
      specified in Section 5.3.19.9. If the CA/RA receives the
      revocation passphrase in the generalInfo field of a PKIHeader of
      any PKIMessage, it MUST include the OID (with absent value) in the
      generalInfo field of the PKIHeader of the corresponding response
      PKIMessage.  If the CA/RA is unable to return the appropriate
      response message for any reason, it MUST send an error message
      with a status of "rejection" and, optionally, a failInfo reason
      set.

   o  The valueHint field of EncryptedValue MAY contain a key identifier
      (chosen by the entity, along with the passphrase itself) to assist
      in later retrieval of the correct passphrase (e.g., when the
      revocation request is constructed by the entity and received by
      the CA/RA).

   o  The revocation request message is protected by a PasswordBasedMAC,
      with the revocation passphrase as the key.  If appropriate, the
      senderKID field in the PKIHeader MAY contain the value previously
      transmitted in valueHint.

   Using the technique specified above, the revocation passphrase may be
   initially established and updated at any time without requiring extra
   messages or out-of-band exchanges.  For example, the revocation
   request message itself (protected and authenticated through a MAC
   that uses the revocation passphrase as a key) may contain, in the
   PKIHeader, a new revocation passphrase to be used for authenticating
   future revocation requests for any of the entity's other
   certificates.  In some environments this may be preferable to
   mechanisms that reveal the passphrase in the revocation request
   message, since this can allow a denial-of-service attack in which the
   revealed passphrase is used by an unauthorized third party to
   authenticate revocation requests on the entity's other certificates.
   However, because the passphrase is not revealed in the request
   message, there is no requirement that the passphrase must always be
   updated when a revocation request is made (that is, the same
   passphrase MAY be used by an entity to authenticate revocation
   requests for different certificates at different times).

   Furthermore, the above technique can provide strong cryptographic
   protection over the entire revocation request message even when a
   digital signature is not used.  Techniques that do authentication of
   the revocation request by simply revealing the revocation passphrase
   typically do not provide cryptographic protection over the fields of
   the request message (so that a request for revocation of one
   certificate may be modified by an unauthorized third party to a
   request for revocation of another certificate for that entity).

Appendix C.  Request Message Behavioral Clarifications

   In the case of updates to [CRMF], which cause interpretation or
   interoperability issues, [CRMF] SHALL be the normative document.

   The following definitions are from [CRMF].  They are included here in
   order to codify behavioral clarifications to that request message;
   otherwise, all syntax and semantics are identical to [CRMF].

   CertRequest ::= SEQUENCE {
       certReqId     INTEGER,
       certTemplate  CertTemplate,
       controls      Controls OPTIONAL }

   -- If certTemplate is an empty SEQUENCE (i.e., all fields
   -- omitted), then controls MAY contain the

   -- id-regCtrl-altCertTemplate control, specifying a template
   -- for a certificate other than an X.509v3 public-key
   -- certificate.  Conversely, if certTemplate is not empty
   -- (i.e., at least one field is present), then controls MUST
   -- NOT contain id-regCtrl- altCertTemplate.  The new control is
   -- defined as follows:

   id-regCtrl-altCertTemplate OBJECT IDENTIFIER ::= {id-regCtrl 7}
   AltCertTemplate ::= AttributeTypeAndValue

   POPOSigningKey ::= SEQUENCE {
       poposkInput           [0] POPOSigningKeyInput OPTIONAL,
       algorithmIdentifier   AlgorithmIdentifier,
       signature             BIT STRING }

   -- **********
   -- * For the purposes of this specification, the ASN.1 comment
   -- * given in [CRMF] pertains not only to certTemplate, but
   -- * also to the altCertTemplate control.  That is,
   -- **********
   -- * The signature (using "algorithmIdentifier") is on the
   -- * DER-encoded value of poposkInput (i.e., the "value" OCTETs
   -- * of the POPOSigningKeyInput DER).  NOTE: If CertReqMsg
   -- * certReq certTemplate (or the altCertTemplate control)
   -- * contains the subject and publicKey values, then poposkInput
   -- * MUST be omitted and the signature MUST be computed on the
   -- * DER-encoded value of CertReqMsg certReq (or the DER-
   -- * encoded value of AltCertTemplate).  If
   -- * certTemplate/altCertTemplate does not contain both the
   -- * subject and public key values (i.e., if it contains only
   -- * one of these, or neither), then poposkInput MUST be present
   -- * and MUST be signed.
   -- **********

   POPOPrivKey ::= CHOICE {
       thisMessage       [0] BIT STRING,

   -- **********
   -- * the type of "thisMessage" is given as BIT STRING in
   -- * [CRMF]; it should be "EncryptedValue" (in accordance
   -- * with Section 5.2.2, "Encrypted Values", of this specification).
   -- * Therefore, this document makes the behavioral clarification
   -- * of specifying that the contents of "thisMessage" MUST be encoded
   -- * as an EncryptedValue and then wrapped in a BIT STRING.  This
   -- * allows the necessary conveyance and protection of the
   -- * private key while maintaining bits-on-the-wire compatibility
   -- * with [CRMF].
   -- **********

       subsequentMessage [1] SubsequentMessage,
       dhMAC             [2] BIT STRING }

Appendix D.  PKI Management Message Profiles (REQUIRED).

   This appendix contains detailed profiles for those PKIMessages that
   MUST be supported by conforming implementations (see Section 6).

   Profiles for the PKIMessages used in the following PKI management
   operations are provided:

   o  initial registration/certification

   o  basic authenticated scheme

   o  certificate request

   o  key update

D.1.  General Rules for Interpretation of These Profiles.

   1.  Where OPTIONAL or DEFAULT fields are not mentioned in individual
       profiles, they SHOULD be absent from the relevant message (i.e.,
       a receiver can validly reject a message containing such fields as
       being syntactically incorrect).  Mandatory fields are not
       mentioned if they have an obvious value (e.g., in this version of
       the specification, pvno is always 2).

   2.  Where structures occur in more than one message, they are
       separately profiled as appropriate.

   3.  The algorithmIdentifiers from PKIMessage structures are profiled
       separately.

   4.  A "special" X.500 DN is called the "NULL-DN"; this means a DN
       containing a zero-length SEQUENCE OF RelativeDistinguishedNames
       (its DER encoding is then '3000'H).

   5.  Where a GeneralName is required for a field, but no suitable
       value is available (e.g., an end entity produces a request before
       knowing its name), then the GeneralName is to be an X.500 NULL-DN
       (i.e., the Name field of the CHOICE is to contain a NULL-DN).
       This special value can be called a "NULL-GeneralName".

   6.  Where a profile omits to specify the value for a GeneralName,
       then the NULL-GeneralName value is to be present in the relevant
       PKIMessage field.  This occurs with the sender field of the
       PKIHeader for some messages.

   7.  Where any ambiguity arises due to naming of fields, the profile
       names these using a "dot" notation (e.g., "certTemplate.subject"
       means the subject field within a field called certTemplate).

   8.  Where a "SEQUENCE OF types" is part of a message, a zero-based
       array notation is used to describe fields within the SEQUENCE OF
       (e.g., crm[0].certReq.certTemplate.subject refers to a subfield
       of the first CertReqMsg contained in a request message).

   9.  All PKI message exchanges in Appendix D.4 to D.6 require a
       certConf message to be sent by the initiating entity and a
       PKIConfirm to be sent by the responding entity.  The PKIConfirm
       is not included in some of the profiles given since its body is
       NULL and its header contents are clear from the context.  Any
       authenticated means can be used for the protectionAlg (e.g.,
       password-based MAC, if shared secret information is known, or
       signature).

D.2.  Algorithm Use Profile

   The following table contains definitions of algorithm uses within PKI
   management protocols.  The columns in the table are:

   Name: an identifier used for message profiles

   Use: description of where and for what the algorithm is used

   Mandatory: an AlgorithmIdentifier which MUST be supported by
      conforming implementations

   Others: alternatives to the mandatory AlgorithmIdentifier

    Name         Use                      Mandatory        Others

    MSG_SIG_ALG  Protection of PKI        DSA/SHA-1        RSA/MD5,
                 messages using signature                  ECDSA, ...
    MSG_MAC_ALG  protection of PKI        PasswordBasedMac HMAC,
                 messages using MACing                     X9.9...
    SYM_PENC_ALG symmetric encryption of  3-DES (3-key-    AES,RC5,
                 an end entity's private  EDE, CBC mode)   CAST-128...
                 key where symmetric
                 key is distributed
                 out-of-band
    PROT_ENC_ALG asymmetric algorithm     D-H              RSA,
                 used for encryption of                    ECDH, ...
                 (symmetric keys for
                 encryption of) private
                 keys transported in

                 PKIMessages
    PROT_SYM_ALG symmetric encryption     3-DES (3-key-    AES,RC5,
                 algorithm used for       EDE, CBC mode)   CAST-128...
                 encryption of private
                 key bits (a key of this
                 type is encrypted using
                 PROT_ENC_ALG)

   Mandatory AlgorithmIdentifiers and Specifications:

   DSA/SHA-1:
     AlgId: {1 2 840 10040 4 3};

   Digital Signature Standard [FIPS-186]

     Public Modulus size: 1024 bits.

   PasswordBasedMac:

     AlgId: {1 2 840 113533 7 66 13}, with SHA-1 {1 3 14 3 2 26} as the
            owf parameter and HMAC-SHA1 {1 3 6 1 5 5 8 1 2} as the mac
            parameter;

     (this specification), along with

   Secure Hash Standard [FIPS-180] and [RFC2104]

     HMAC key size:  160 bits (i.e., "K" = "H" in Section 5.1.3.1,
                               "Shared secret information")

   3-DES:

     AlgId: {1 2 840 113549 3 7};
     (used in RSA's BSAFE and in S/MIME).

   D-H:

     AlgId:  {1 2 840 10046 2 1};

   [ANSI-X9.42]

     Public Modulus Size:  1024 bits.
     DomainParameters ::= SEQUENCE {
        p       INTEGER, -- odd prime, p=jq +1
        g       INTEGER, -- generator, g^q = 1 mod p
        q       INTEGER, -- prime factor of p-1
        j       INTEGER OPTIONAL, -- cofactor, j>=2
        validationParms  ValidationParms OPTIONAL

     }
     ValidationParms ::= SEQUENCE {
        seed          BIT STRING, -- seed for prime generation
        pGenCounter   INTEGER     -- parameter verification
     }

D.3.  Proof-of-Possession Profile

   POP fields for use (in signature field of pop field of
   ProofOfPossession structure) when proving possession of a private
   signing key that corresponds to a public verification key for which a
   certificate has been requested.

    Field               Value         Comment

    algorithmIdentifier MSG_SIG_ALG   only signature protection is
                                      allowed for this proof

    signature           present       bits calculated using MSG_SIG_ALG

   Proof-of-possession of a private decryption key that corresponds to a
   public encryption key for which a certificate has been requested does
   not use this profile; the CertHash field of the certConf message is
   used instead.

   Not every CA/RA will do Proof-of-Possession (of signing key,
   decryption key, or key agreement key) in the PKIX-CMP in-band
   certification request protocol (how POP is done MAY ultimately be a
   policy issue that is made explicit for any given CA in its publicized
   Policy OID and Certification Practice Statement).  However, this
   specification MANDATES that CA/RA entities MUST do POP (by some
   means) as part of the certification process.  All end entities MUST
   be prepared to provide POP (i.e., these components of the PKIX-CMP
   protocol MUST be supported).

D.4.  Initial Registration/Certification (Basic Authenticated Scheme)

   An (uninitialized) end entity requests a (first) certificate from a
   CA.  When the CA responds with a message containing a certificate,
   the end entity replies with a certificate confirmation.  The CA sends
   a PKIConfirm back, closing the transaction.  All messages are
   authenticated.

   This scheme allows the end entity to request certification of a
   locally-generated public key (typically a signature key).  The end
   entity MAY also choose to request the centralized generation and
   certification of another key pair (typically an encryption key pair).

   Certification may only be requested for one locally generated public
   key (for more, use separate PKIMessages).

   The end entity MUST support proof-of-possession of the private key
   associated with the locally-generated public key.

   Preconditions:

   1.  The end entity can authenticate the CA's signature based on out-
       of-band means

   2.  The end entity and the CA share a symmetric MACing key

   Message flow:

    Step# End entity                           PKI
      1   format ir
      2                      ->   ir      ->
      3                                        handle ir
      4                                        format ip
      5                      <-   ip      <-
      6   handle ip
      7   format certConf
      8                      ->   certConf ->
      9                                        handle certConf
     10                                        format PKIConf
     11                      <-   PKIConf  <-
     12   handle PKIConf

   For this profile, we mandate that the end entity MUST include all
   (i.e., one or two) CertReqMsg in a single PKIMessage, and that the
   PKI (CA) MUST produce a single response PKIMessage that contains the
   complete response (i.e., including the OPTIONAL second key pair, if
   it was requested and if centralized key generation is supported).
   For simplicity, we also mandate that this message MUST be the final
   one (i.e., no use of "waiting" status value).

   The end entity has an out-of-band interaction with the CA/RA.  This
   transaction established the shared secret, the referenceNumber and
   OPTIONALLY the distinguished name used for both sender and subject
   name in the certificate template.  It is RECOMMENDED that the shared
   secret be at least 12 characters long.

   Initialization Request -- ir

   Field                Value

   recipient            CA name

     -- the name of the CA who is being asked to produce a certificate
   protectionAlg        MSG_MAC_ALG
     -- only MAC protection is allowed for this request, based
     -- on initial authentication key
   senderKID            referenceNum
     -- the reference number which the CA has previously issued
     -- to the end entity (together with the MACing key)
   transactionID        present
     -- implementation-specific value, meaningful to end
     -- entity.
     -- [If already in use at the CA, then a rejection message MUST
     -- be produced by the CA]

   senderNonce          present
     -- 128 (pseudo-)random bits
   freeText             any valid value
   body                 ir (CertReqMessages)
                        only one or two CertReqMsg
                        are allowed
     -- if more certificates are required, requests MUST be
     -- packaged in separate PKIMessages

   CertReqMsg           one or two present
     -- see below for details, note: crm[0] means the first
     -- (which MUST be present), crm[1] means the second (which
     -- is OPTIONAL, and used to ask for a centrally-generated key)

   crm[0].certReq.      fixed value of zero
      certReqId
     -- this is the index of the template within the message
   crm[0].certReq       present
      certTemplate
     -- MUST include subject public key value, otherwise unconstrained
   crm[0].pop...        optionally present if public key
      POPOSigningKey    from crm[0].certReq.certTemplate is
                        a signing key
     -- proof-of-possession MAY be required in this exchange
     -- (see Appendix D.3 for details)
   crm[0].certReq.      optionally present
      controls.archiveOptions
     -- the end entity MAY request that the locally-generated
     -- private key be archived

   crm[0].certReq.      optionally present
      controls.publicationInfo
     -- the end entity MAY ask for publication of resulting cert.

   crm[1].certReq       fixed value of one

      certReqId
     -- the index of the template within the message
   crm[1].certReq       present
      certTemplate
      -- MUST NOT include actual public key bits, otherwise
      -- unconstrained (e.g., the names need not be the same as in
      -- crm[0]).  Note that subjectPublicKeyInfo MAY be present
      -- and contain an AlgorithmIdentifier followed by a
      -- zero-length BIT STRING for the subjectPublicKey if it is
      -- desired to inform the CA/RA of algorithm and parameter
      -- preferences regarding the to-be-generated key pair.

   crm[1].certReq.      present [object identifier MUST be PROT_ENC_ALG]

      controls.protocolEncrKey
     -- if centralized key generation is supported by this CA,
     -- this short-term asymmetric encryption key (generated by
     -- the end entity) will be used by the CA to encrypt (a
     -- symmetric key used to encrypt) a private key generated by
     -- the CA on behalf of the end entity

   crm[1].certReq.      optionally present
      controls.archiveOptions
   crm[1].certReq.      optionally present
      controls.publicationInfo
   protection           present
     -- bits calculated using MSG_MAC_ALG

   Initialization Response -- ip

   Field                Value

   sender               CA name
     -- the name of the CA who produced the message
   messageTime          present
     -- time at which CA produced message
   protectionAlg        MS_MAC_ALG
     -- only MAC protection is allowed for this response
   senderKID             referenceNum
     -- the reference number that the CA has previously issued to the
     -- end entity (together with the MACing key)
   transactionID        present
     -- value from corresponding ir message
   senderNonce          present
     -- 128 (pseudo-)random bits
   recipNonce           present
     -- value from senderNonce in corresponding ir message
   freeText             any valid value

   body                 ip (CertRepMessage)
                        contains exactly one response
                        for each request

     -- The PKI (CA) responds to either one or two requests as
     -- appropriate.  crc[0] denotes the first (always present);
     -- crc[1] denotes the second (only present if the ir message
     -- contained two requests and if the CA supports centralized
     -- key generation).
   crc[0].              fixed value of zero
      certReqId
     -- MUST contain the response to the first request in the
     -- corresponding ir message

   crc[0].status.       present, positive values allowed:
      status               "accepted", "grantedWithMods"
                        negative values allowed:
                           "rejection"
   crc[0].status.       present if and only if
      failInfo          crc[0].status.status is "rejection"
   crc[0].              present if and only if
      certifiedKeyPair  crc[0].status.status is
                           "accepted" or "grantedWithMods"
   certificate          present unless end entity's public
                        key is an encryption key and POP
                        is done in this in-band exchange
   encryptedCert        present if and only if end entity's
                        public key is an encryption key and
                        POP done in this in-band exchange
   publicationInfo      optionally present

     -- indicates where certificate has been published (present
     -- at discretion of CA)

   crc[1].              fixed value of one
      certReqId
     -- MUST contain the response to the second request in the
     -- corresponding ir message
   crc[1].status.       present, positive values allowed:
      status               "accepted", "grantedWithMods"
                        negative values allowed:
                           "rejection"
   crc[1].status.       present if and only if
      failInfo          crc[0].status.status is "rejection"
   crc[1].              present if and only if
      certifiedKeyPair  crc[0].status.status is "accepted"
                        or "grantedWithMods"
   certificate          present

   privateKey           present
     -- see Appendix C, Request Message Behavioral Clarifications
   publicationInfo      optionally present
     -- indicates where certificate has been published (present
     -- at discretion of CA)

   protection           present
     -- bits calculated using MSG_MAC_ALG
   extraCerts           optionally present
     -- the CA MAY provide additional certificates to the end
     -- entity

   Certificate confirm; certConf

   Field                Value

   sender               present
     -- same as in ir
   recipient            CA name
     -- the name of the CA who was asked to produce a certificate
   transactionID        present
     -- value from corresponding ir and ip messages
   senderNonce          present
     -- 128 (pseudo-) random bits
   recipNonce           present
     -- value from senderNonce in corresponding ip message
   protectionAlg        MSG_MAC_ALG
     -- only MAC protection is allowed for this message.  The
     -- MAC is based on the initial authentication key shared
     -- between the EE and the CA.

   senderKID            referenceNum
     -- the reference number which the CA has previously issued
     -- to the end entity (together with the MACing key)

   body                 certConf
     -- see Section 5.3.18, "PKI Confirmation Content", for the
     -- contents of the certConf fields.
     -- Note: two CertStatus structures are required if both an
     -- encryption and a signing certificate were sent.

   protection           present
     -- bits calculated using MSG_MAC_ALG

   Confirmation; PKIConf

   Field                Value

   sender               present
     -- same as in ip
   recipient            present
     -- sender name from certConf
   transactionID        present
     -- value from certConf message
   senderNonce          present
     -- 128 (pseudo-) random bits
   recipNonce           present
     -- value from senderNonce from certConf message
   protectionAlg        MSG_MAC_ALG
     -- only MAC protection is allowed for this message.
   senderKID            referenceNum
   body                 PKIConf
   protection           present
     -- bits calculated using MSG_MAC_ALG

D.5.  Certificate Request

   An (initialized) end entity requests a certificate from a CA (for any
   reason).  When the CA responds with a message containing a
   certificate, the end entity replies with a certificate confirmation.
   The CA replies with a PKIConfirm, to close the transaction.  All
   messages are authenticated.

   The profile for this exchange is identical to that given in Appendix
   D.4, with the following exceptions:

   o  sender name SHOULD be present

   o  protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
      also be supported) in request, response, certConfirm, and
      PKIConfirm messages;

   o  senderKID and recipKID are only present if required for message
      verification;

   o  body is cr or cp;

   o  body may contain one or two CertReqMsg structures, but either
      CertReqMsg may be used to request certification of a locally-
      generated public key or a centrally-generated public key (i.e.,
      the position-dependence requirement of Appendix D.4 is removed);

   o  protection bits are calculated according to the protectionAlg
      field.

D.6.  Key Update Request

   An (initialized) end entity requests a certificate from a CA (to
   update the key pair and/or corresponding certificate that it already
   possesses).  When the CA responds with a message containing a
   certificate, the end entity replies with a certificate confirmation.
   The CA replies with a PKIConfirm, to close the transaction.  All
   messages are authenticated.

   The profile for this exchange is identical to that given in Appendix
   D.4, with the following exceptions:

   1.  sender name SHOULD be present

   2.  protectionAlg of MSG_SIG_ALG MUST be supported (MSG_MAC_ALG MAY
       also be supported) in request, response, certConfirm, and
       PKIConfirm messages;

   3.  senderKID and recipKID are only present if required for message
       verification;

   4.  body is kur or kup;

   5.  body may contain one or two CertReqMsg structures, but either
       CertReqMsg may be used to request certification of a locally-
       generated public key or a centrally-generated public key (i.e.,
       the position-dependence requirement of Appendix D.4 is removed);

   6.  protection bits are calculated according to the protectionAlg
       field;

   7.  regCtrl OldCertId SHOULD be used (unless it is clear to both
       sender and receiver -- by means not specified in this document --
       that it is not needed).