Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4210

Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)

Pages: 95
Proposed Standard
Errata
Obsoletes:  2510
Updated by:  671294809481
Part 4 of 5 – Pages 56 to 75
First   Prev   Next

Top   ToC   RFC4210 - Page 56   prevText

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.
Top   ToC   RFC4210 - Page 57

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
Top   ToC   RFC4210 - Page 58
   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.
Top   ToC   RFC4210 - Page 59
   [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.
Top   ToC   RFC4210 - Page 60
   [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.
Top   ToC   RFC4210 - Page 61

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
Top   ToC   RFC4210 - Page 62
   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).
Top   ToC   RFC4210 - Page 63
   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
Top   ToC   RFC4210 - Page 64
   -- 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].
   -- **********
Top   ToC   RFC4210 - Page 65
       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.
Top   ToC   RFC4210 - Page 66
   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
Top   ToC   RFC4210 - Page 67
                 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
Top   ToC   RFC4210 - Page 68
     }
     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).
Top   ToC   RFC4210 - Page 69
   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
Top   ToC   RFC4210 - Page 70
     -- 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
Top   ToC   RFC4210 - Page 71
      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
Top   ToC   RFC4210 - Page 72
   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
Top   ToC   RFC4210 - Page 73
   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
Top   ToC   RFC4210 - Page 74
   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.
Top   ToC   RFC4210 - Page 75

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).


(page 75 continued on part 5)

Next Section