Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2510

Internet X.509 Public Key Infrastructure Certificate Management Protocols

Pages: 72
Obsoleted by:  4210
Part 3 of 3 – Pages 38 to 72
First   Prev   None

ToP   noToC   RFC2510 - Page 38   prevText

4. Mandatory PKI Management functions

The PKI management functions outlined in Section 1 above are described in this section. This section deals with functions that are "mandatory" in the sense that all end entity and CA/RA implementations MUST be able to provide the functionality described (perhaps via one of the transport mechanisms defined in Section 5). This part is effectively the profile of the PKI management functionality that MUST be supported. Note that not all PKI management functions result in the creation of a PKI message.

4.1 Root CA initialization

[See Section 1.2.2 for this document's definition of "root CA".] A newly created root CA must produce a "self-certificate" which is a Certificate structure with the profile defined for the "newWithNew" certificate issued following a root CA key update. In order to make the CA's self certificate useful to end entities that do not acquire the self certificate via "out-of-band" means, the CA must also produce a fingerprint for its public key. End entities that acquire this fingerprint securely via some "out-of-band" means can then verify the CA's self-certificate and hence the other attributes contained therein.
ToP   noToC   RFC2510 - Page 39
   The data structure used to carry the fingerprint is the OOBCertHash.

4.2 Root CA key update

CA keys (as all other keys) have a finite lifetime and will have to be updated on a periodic basis. The certificates NewWithNew, NewWithOld, and OldWithNew (see Section 2.4.1) are issued by the CA to aid existing end entities who hold the current self-signed CA certificate (OldWithOld) to transition securely to the new self- signed CA certificate (NewWithNew), and to aid new end entities who will hold NewWithNew to acquire OldWithOld securely for verification of existing data.

4.3 Subordinate CA initialization

[See Section 1.2.2 for this document's definition of "subordinate CA".] From the perspective of PKI management protocols the initialization of a subordinate CA is the same as the initialization of an end entity. The only difference is that the subordinate CA must also produce an initial revocation list.

4.4 CRL production

Before issuing any certificates a newly established CA (which issues CRLs) must produce "empty" versions of each CRL which is to be periodically produced.

4.5 PKI information request

When a PKI entity (CA, RA, or EE) wishes to acquire information about the current status of a CA it MAY send that CA a request for such information. The CA must respond to the request by providing (at least) all of the information requested by the requester. If some of the information cannot be provided then an error must be conveyed to the requester. If PKIMessages are used to request and supply this PKI information, then the request must be the GenMsg message, the response must be the GenRep message, and the error must be the Error message. These messages are protected using a MAC based on shared secret information (i.e., PasswordBasedMAC) or any other authenticated means (if the end entity has an existing certificate).
ToP   noToC   RFC2510 - Page 40

4.6 Cross certification

The requester CA is the CA that will become the subject of the cross-certificate; the responder CA will become the issuer of the cross-certificate. The requester CA must be "up and running" before initiating the cross-certification operation.

4.6.1 One-way request-response scheme:

The cross-certification scheme is essentially a one way operation; that is, when successful, this operation results in the creation of one new cross-certificate. If the requirement is that cross- certificates be created in "both directions" then each CA in turn must initiate a cross-certification operation (or use another scheme). This scheme is suitable where the two CAs in question can already verify each other's signatures (they have some common points of trust) or where there is an out-of-band verification of the origin of the certification request. Detailed Description: Cross certification is initiated at one CA known as the responder. The CA administrator for the responder identifies the CA it wants to cross certify and the responder CA equipment generates an authorization code. The responder CA administrator passes this authorization code by out-of-band means to the requester CA administrator. The requester CA administrator enters the authorization code at the requester CA in order to initiate the on- line exchange. The authorization code is used for authentication and integrity purposes. This is done by generating a symmetric key based on the authorization code and using the symmetric key for generating Message Authentication Codes (MACs) on all messages exchanged. The requester CA initiates the exchange by generating a random number (requester random number). The requester CA then sends to the responder CA the cross certification request (ccr) message. The fields in this message are protected from modification with a MAC based on the authorization code. Upon receipt of the ccr message, the responder CA checks the protocol version, saves the requester random number, generates its own random number (responder random number) and validates the MAC. It then
ToP   noToC   RFC2510 - Page 41
   generates (and archives, if desired) a new requester certificate that
   contains the requester CA public key and is signed with the responder
   CA signature private key. The responder CA responds with the cross
   certification response (ccp) message. The fields in this message are
   protected from modification with a MAC based on the authorization
   code.

   Upon receipt of the ccp message, the requester CA checks that its own
   system time is close to the responder CA system time, checks the
   received random numbers and validates the MAC.  The requester CA
   responds with the PKIConfirm message. The fields in this message are
   protected from modification with a MAC based on the authorization
   code.  The requester CA writes the requester certificate to the
   Repository.

   Upon receipt of the PKIConfirm message, the responder CA checks the
   random numbers and validates the MAC.

   Notes:

   1. The ccr message must contain a "complete" certification request,
      that is, all fields (including, e.g., a BasicConstraints
      extension) must be specified by the requester CA.
   2. The ccp message SHOULD contain the verification certificate of the
      responder CA - if present, the requester CA must then verify this
      certificate (for example, via the "out-of-band" mechanism).

4.7 End entity initialization

As with CAs, end entities must be initialized. Initialization of end entities requires at least two steps: - acquisition of PKI information - out-of-band verification of one root-CA public key (other possible steps include the retrieval of trust condition information and/or out-of-band verification of other CA public keys).

4.7.1 Acquisition of PKI information

The information REQUIRED is: - the current root-CA public key - (if the certifying CA is not a root-CA) the certification path from the root CA to the certifying CA together with appropriate revocation lists - the algorithms and algorithm parameters which the certifying CA supports for each relevant usage
ToP   noToC   RFC2510 - Page 42
   Additional information could be required (e.g., supported extensions
   or CA policy information) in order to produce a certification request
   which will be successful. However, for simplicity we do not mandate
   that the end entity acquires this information via the PKI messages.
   The end result is simply that some certification requests may fail
   (e.g., if the end entity wants to generate its own encryption key but
   the CA doesn't allow that).

   The required information MAY be acquired as described in Section 4.5.

4.7.2 Out-of-Band Verification of Root-CA Key

An end entity must securely possess the public key of its root CA. One method to achieve this is to provide the end entity with the CA's self-certificate fingerprint via some secure "out-of-band" means. The end entity can then securely use the CA's self-certificate. See Section 4.1 for further details.

4.8 Certificate Request

An initialized end entity MAY request a certificate at any time (as part of an update procedure, or for any other purpose). This request will be made using the certification request (cr) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this cr message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a CertRepMessage.

4.9 Key Update

When a key pair is due to expire the relevant end entity MAY request a key update - that is, it MAY request that the CA issue a new certificate for a new key pair. The request is made using a key update request (kur) message. If the end entity already possesses a signing key pair (with a corresponding verification certificate), then this message will typically be protected by the entity's digital signature. The CA returns the new certificate (if the request is successful) in a key update response (kup) message, which is syntactically identical to a CertRepMessage.

5. Transports

The transport protocols specified below allow end entities, RAs and CAs to pass PKI messages between them. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages are suitably protected (that is, if the OPTIONAL PKIProtection parameter is used as specified for each message).
ToP   noToC   RFC2510 - Page 43

5.1 File based protocol

A file containing a PKI message MUST contain only the DER encoding of one PKI message, i.e., there MUST be no extraneous header or trailer information in the file. Such files can be used to transport PKI messages using, e.g., FTP.

5.2 Direct TCP-Based Management Protocol

The following simple TCP-based protocol is to be used for transport of PKI messages. This protocol is suitable for cases where an end entity (or an RA) initiates a transaction and can poll to pick up the results. If a transaction is initiated by a PKI entity (RA or CA) then an end entity must either supply a listener process or be supplied with a polling reference (see below) in order to allow it to pick up the PKI message from the PKI management component. The protocol basically assumes a listener process on an RA or CA which can accept PKI messages on a well-defined port (port number 829). Typically an initiator binds to this port and submits the initial PKI message for a given transaction ID. The responder replies with a PKI message and/or with a reference number to be used later when polling for the actual PKI message response. If a number of PKI response messages are to be produced for a given request (say if some part of the request is handled more quickly than another) then a new polling reference is also returned. When the final PKI response message has been picked up by the initiator then no new polling reference is supplied. The initiator of a transaction sends a "direct TCP-based PKI message" to the recipient. The recipient responds with a similar message. A "direct TCP-based PKI message" consists of: length (32-bits), flag (8-bits), value (defined below) The length field contains the number of octets of the remainder of the message (i.e., number of octets of "value" plus one). All 32-bit values in this protocol are specified to be in network byte order. Message name flag value pkiMsg '00'H DER-encoded PKI message
ToP   noToC   RFC2510 - Page 44
      -- PKI message
    pollRep        '01'H    polling reference (32 bits),
                            time-to-check-back (32 bits)
      -- poll response where no PKI message response ready; use polling
      -- reference value (and estimated time value) for later polling
    pollReq        '02'H    polling reference (32 bits)
      -- request for a PKI message response to initial message
    negPollRep     '03'H    '00'H
      -- no further polling responses (i.e., transaction complete)
    partialMsgRep  '04'H    next polling reference (32 bits),
                            time-to-check-back (32 bits),
                            DER-encoded PKI message
      -- partial response to initial message plus new polling reference
      -- (and estimated time value) to use to get next part of response
    finalMsgRep    '05'H    DER-encoded PKI message
      -- final (and possibly sole) response to initial message
    errorMsgRep    '06'H    human readable error message
      -- produced when an error is detected (e.g., a polling reference is
      -- received which doesn't exist or is finished with)

   Where a PKIConfirm message is to be transported (always from the
   initiator to the responder) then a pkiMsg message is sent and a
   negPollRep is returned.

   The sequence of messages which can occur is then:

   a) end entity sends pkiMsg and receives one of pollRep, negPollRep,
   partialMsgRep or finalMsgRep in response.  b) end entity sends
   pollReq message and receives one of negPollRep, partialMsgRep,
   finalMsgRep or errorMsgRep in response.

   The "time-to-check-back" parameter is a 32-bit integer, defined to be
   the number of seconds which have elapsed since midnight, January 1,
   1970, coordinated universal time.  It provides an estimate of the
   time that the end entity should send its next pollReq.

5.3 Management Protocol via E-mail

This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via Internet mail. A simple MIME object is specified as follows. Content-Type: application/pkixcmp Content-Transfer-Encoding: base64 <<the ASN.1 DER-encoded PKIX-CMP message, base64-encoded>>
ToP   noToC   RFC2510 - Page 45
   This MIME object can be sent and received using common MIME
   processing engines and provides a simple Internet mail transport for
   PKIX-CMP messages.  Implementations MAY wish to also recognize and
   use the "application/x-pkixcmp" MIME type (specified in earlier
   versions of this document) in order to support backward compatibility
   wherever applicable.

5.4 Management Protocol via HTTP

This subsection specifies a means for conveying ASN.1-encoded messages for the protocol exchanges described in Section 4 via the HyperText Transfer Protocol. A simple MIME object is specified as follows. Content-Type: application/pkixcmp <<the ASN.1 DER-encoded PKIX-CMP message>> This MIME object can be sent and received using common HTTP processing engines over WWW links and provides a simple browser- server transport for PKIX-CMP messages. Implementations MAY wish to also recognize and use the "application/x-pkixcmp" MIME type (specified in earlier versions of this document) in order to support backward compatibility wherever applicable. SECURITY CONSIDERATIONS This entire memo is about security mechanisms. One cryptographic consideration is 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.
ToP   noToC   RFC2510 - Page 46
   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.

References

[COR95] ISO/IEC JTC 1/SC 21, Technical Corrigendum 2 to ISO/IEC 9594-8: 1990 & 1993 (1995:E), July 1995. [CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Certificate Request Message Format", RFC 2511, March 1999. [MvOV97] A. Menezes, P. van Oorschot, S. Vanstone, "Handbook of Applied Cryptography", CRC Press, 1997. [PKCS7] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS10] RSA Laboratories, "The Public-Key Cryptography Standards (PKCS)", RSA Data Security Inc., Redwood City, California, November 1993 Release. [PKCS11] RSA Laboratories, "The Public-Key Cryptography Standards - PKCS #11: Cryptographic token interface standard", RSA Data Security Inc., Redwood City, California, April 28, 1995. [RFC1847] Galvin, J., Murphy, S. Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/ Encrypted", RFC 1847, October 1995. [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. [X509-AM] ISO/IEC JTC1/SC 21, Draft Amendments DAM 4 to ISO/IEC 9594-2, DAM 2 to ISO/IEC 9594-6, DAM 1 to ISO/IEC 9594-7, and DAM 1 to ISO/IEC 9594-8 on Certificate Extensions, 1 December, 1996.
ToP   noToC   RFC2510 - Page 47

Acknowledgements

The authors gratefully acknowledge the contributions of various members of the PKIX Working Group. Many of these contributions significantly clarified and improved the utility of this specification.

Authors' Addresses

Carlisle Adams Entrust Technologies 750 Heron Road, Suite E08, Ottawa, Ontario Canada K1V 1A7 EMail: cadams@entrust.com Stephen Farrell Software and Systems Engineering Ltd. Fitzwilliam Court Leeson Close Dublin 2 IRELAND EMail: stephen.farrell@sse.ie
ToP   noToC   RFC2510 - Page 48
APPENDIX A: Reasons for the presence of RAs

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

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

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

     -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 which argue for the presence of an
   RA are the following.

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

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

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

     -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).
ToP   noToC   RFC2510 - Page 49

Appendix B. PKI Management Message Profiles.

This appendix contains detailed profiles for those PKIMessages which MUST be supported by conforming implementations (see Section 4). Profiles for the PKIMessages used in the following PKI management operations are provided: - root CA key update - information request/response - cross-certification request/response (1-way) - initial registration/certification - basic authenticated scheme - certificate request - key update <<Later versions of this document may extend the above to include profiles for the operations listed below (along with other operations, if desired).>> - revocation request - certificate publication - CRL publication B1. 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., pvno). 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   noToC   RFC2510 - Page 50
   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 Sections B7-B10 require a PKIConfirm
      message to be sent by the initiating entity.  This message 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).

B2. 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
 MSG_MAC_ALG    protection of PKI          PasswordBasedMac HMAC,
                messages using MACing                       X9.9...
 SYM_PENC_ALG   symmetric encryption of    3-DES (3-key-    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
                (symmetric keys for
                encryption of) private
                keys transported in
                PKIMessages
 PROT_SYM_ALG   symmetric encryption       3-DES (3-key-    RC5,
                algorithm used for         EDE, CBC mode)   CAST-128...
                encryption of private
                key bits (a key of this
ToP   noToC   RFC2510 - Page 51
                type is encrypted using
                PROT_ENC_ALG)

Mandatory AlgorithmIdentifiers and Specifications:

DSA/SHA-1:
  AlgId:  {1 2 840 10040 4 3};
  NIST, FIPS PUB 186: Digital Signature Standard, 1994;
  Public Modulus size:  1024 bits.

PasswordBasedMac:
  {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
  NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995;
  H. Krawczyk, M. Bellare, R. Canetti, "HMAC:  Keyed-Hashing for Message
    Authentication", Internet Request for Comments 2104, February 1997.

3-DES:
  {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.
  DHParameter ::= SEQUENCE {
    prime INTEGER, -- p
    base  INTEGER  -- g
  }

B3. "Self-signed" certificates

   Profile of how a Certificate structure may be "self-signed". These
   structures are used for distribution of "root" CA public keys. This
   can occur in one of three ways (see Section 2.4 above for a
   description of the use of these structures):

 Type          Function

 newWithNew    a true "self-signed" certificate; the contained public
               key MUST be usable to verify the signature (though this
               provides only integrity and no authentication whatsoever)
 oldWithNew    previous root CA public key signed with new private key
 newWithOld    new root CA public key signed with previous private key
ToP   noToC   RFC2510 - Page 52
   <<Such certificates (including relevant extensions) must contain
   "sensible" values for all fields.  For example, when present
   subjectAltName MUST be identical to issuerAltName, and when present
   keyIdentifiers must contain appropriate values, et cetera.>>

B4. 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 which 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 which corresponds
   to a public encryption key for which a certificate has been requested
   does not use this profile; instead the method given in protectionAlg
   for PKIConfirm in Section B8 is used.>>

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

B5. Root CA Key Update

   A root CA updates its key pair. It then produces a CA key update
   announcement message which can be made available (via one of the
   transport mechanisms) to the relevant end entities.  A PKIConfirm
   message is NOT REQUIRED from the end entities.

   ckuann message:

    Field        Value                        Comment

    sender       CA name                      responding CA name
    body         ckuann(CAKeyUpdAnnContent)
    oldWithNew   present                      see Section B3 above
ToP   noToC   RFC2510 - Page 53
    newWithOld   present                      see Section B3 above
    newWithNew   present                      see Section B3 above
    extraCerts   optionally present           can be used to "publish"
                                              certificates (e.g.,
                                              certificates signed using
                                              the new private key)

B6. PKI Information request/response

   The end entity sends general message to the PKI requesting details
   which will be required for later PKI management operations.  RA/CA
   responds with general response. If an RA generates the response then
   it will simply forward the equivalent message which it previously
   received from the CA, with the possible addition of the certificates
   to the extraCerts fields of the PKIMessage.  A PKIConfirm message is
   NOT REQUIRED from the end entity.

Message Flows:

Step#   End entity                                    PKI

  1     format genm
  2                      ->      genm      ->
  3                                                   handle genm
  4                                                   produce genp
  5                      <-      genp      <-
  6     handle genp


genm:

Field               Value

recipient           CA name
  -- the name of the CA as contained in issuerAltName extensions or
  -- issuer fields within certificates
protectionAlg       MSG_MAC_ALG or MSG_SIG_ALG
  -- any authenticated protection alg.
SenderKID           present if required
  -- must be present if required for verification of message protection
freeText            any valid value
body                genr (GenReqContent)
GenMsgContent       empty SEQUENCE
  -- all relevant information requested
protection          present
  -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
ToP   noToC   RFC2510 - Page 54
genp:

Field                Value

sender               CA name
  -- name of the CA which produced the message
protectionAlg        MSG_MAC_ALG or MSG_SIG_ALG
  -- any authenticated protection alg.
senderKID            present if required
  -- must be present if required for verification of message protection
body                 genp (GenRepContent)
CAProtEncCert        present (object identifier one
                     of PROT_ENC_ALG), with relevant
                     value
  -- to be used if end entity needs to encrypt information for the CA
  -- (e.g., private key for recovery purposes)
SignKeyPairTypes     present, with relevant value
  -- the set of signature algorithm identifiers which this CA will
  -- certify for subject public keys
EncKeyPairTypes      present, with relevant value
  -- the set of encryption/key agreement algorithm identifiers which
  -- this CA will certify for subject public keys
PreferredSymmAlg     present (object identifier one
                     of PROT_SYM_ALG) , with relevant
                     value
  -- the symmetric algorithm which this CA expects to be used in later
  -- PKI messages (for encryption)
CAKeyUpdateInfo      optionally present, with
                     relevant value
  -- the CA MAY provide information about a relevant root CA key pair
  -- using this field (note that this does not imply that the responding
  -- CA is the root CA in question)
CurrentCRL           optionally present, with relevant value
  -- the CA MAY provide a copy of a complete CRL (i.e., fullest possible
  -- one)
protection           present
  -- bits calculated using MSG_MAC_ALG or MSG_SIG_ALG
extraCerts           optionally present
  -- can be used to send some certificates to the end entity. An RA MAY
  -- add its certificate here.

B7. Cross certification request/response (1-way)

   Creation of a single cross-certificate (i.e., not two at once). The
   requesting CA MAY choose who is responsible for publication of the
   cross-certificate created by the responding CA through use of the
   PKIPublicationInfo control.
ToP   noToC   RFC2510 - Page 55
   Preconditions:

   1. Responding CA can verify the origin of the request (possibly
      requiring out-of-band means) before processing the request.
   2. Requesting CA can authenticate the authenticity of the origin of
      the response (possibly requiring out-of-band means) before
      processing the response

Message Flows:

Step#   Requesting CA                                  Responding CA
  1     format ccr
  2                        ->       ccr       ->
  3                                                     handle ccr
  4                                                     produce ccp
  5                        <-       ccp       <-
  6     handle ccp
  7     format conf
  8                        ->       conf      ->
  9                                                     handle conf


ccr:
Field                 Value

sender                Requesting CA name
  -- the name of the CA who produced the message
recipient             Responding CA name
  -- the name of the CA who is being asked to produce a certificate
messageTime           time of production of message
  -- current time at requesting CA
protectionAlg         MSG_SIG_ALG
  -- only signature protection is allowed for this request
senderKID             present if required
  -- must be present if required for verification of message protection
transactionID         present
  -- implementation-specific value, meaningful to requesting CA.
  -- [If already in use at responding CA then a rejection message
  -- MUST be produced by responding CA]
senderNonce           present
  -- 128 (pseudo-)random bits
freeText              any valid value
body                  ccr (CertReqMessages)
                      only one CertReqMsg
                      allowed
  -- if multiple cross certificates are required they MUST be packaged
  -- in separate PKIMessages
certTemplate          present
ToP   noToC   RFC2510 - Page 56
  -- details follow
version               v1 or v3
  -- <<v3 STRONGLY RECOMMENDED>>
signingAlg            present
  -- the requesting CA must know in advance with which algorithm it
  -- wishes the certificate to be signed
subject               present
  -- may be NULL-DN only if subjectAltNames extension value proposed
validity              present
  -- MUST be completely specified (i.e., both fields present)
issuer                present
  -- may be NULL-DN only if issuerAltNames extension value proposed
publicKey             present
  -- the key to be certified (which must be for a signing algorithm)
extensions            optionally present
  -- a requesting CA must propose values for all extensions which it
  -- requires to be in the cross-certificate

POPOSigningKey        present
  -- see "Proof of possession profile" (Section B4)

protection            present
  -- bits calculated using MSG_SIG_ALG
extraCerts            optionally present
  -- MAY contain any additional certificates that requester wishes
  -- to include


ccp:
Field                 Value

sender                Responding CA name
  -- the name of the CA who produced the message
recipient             Requesting CA name
  -- the name of the CA who asked for production of a certificate
messageTime           time of production of message
  -- current time at responding CA
protectionAlg         MSG_SIG_ALG
  -- only signature protection is allowed for this message
senderKID             present if required
  -- must be present if required for verification of message
  -- protection
recipKID              present if required
transactionID         present
  -- value from corresponding ccr message
senderNonce           present
  -- 128 (pseudo-)random bits
recipNonce            present
ToP   noToC   RFC2510 - Page 57
  -- senderNonce from corresponding ccr message
freeText              any valid value
body                  ccp (CertRepMessage)
                      only one CertResponse allowed
  -- if multiple cross certificates are required they MUST be packaged
  -- in separate PKIMessages
response              present
status                present
PKIStatusInfo.status  present
  -- if PKIStatusInfo.status is one of:
  --   granted, or
  --   grantedWithMods,
  -- then certifiedKeyPair MUST be present and failInfo MUST be absent
failInfo              present depending on
                      PKIStatusInfo.status
  -- if PKIStatusInfo.status is:
  --   rejection
  -- then certifiedKeyPair MUST be absent and failInfo MUST be present
  -- and contain appropriate bit settings


certifiedKeyPair      present depending on
                      PKIStatusInfo.status
certificate           present depending on
                      certifiedKeyPair
  -- content of actual certificate must be examined by requesting CA
  -- before publication

protection            present
  -- bits calculated using MSG_SIG_ALG
extraCerts            optionally present
  -- MAY contain any additional certificates that responder wishes
  -- to include

B8. 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 confirmation. 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).
ToP   noToC   RFC2510 - Page 58
   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 conf
     8                         ->      conf     ->
     9                                                    handle conf

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

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
ToP   noToC   RFC2510 - Page 59
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 Section
  -- B4 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])
crm[0].certReq.      present [object identifier MUST be PROT_ENC_ALG]
   controls.protocolEncKey
  -- 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
ToP   noToC   RFC2510 - Page 60
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
recipKID             referenceNum
  -- the reference number which 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                 ir (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               "granted", "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
                        "granted" 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)
ToP   noToC   RFC2510 - Page 61
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               "granted", "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 "granted"
                     or "grantedWithMods"
certificate          present
privateKey           present
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

conf:
Field                Value

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
  -- value from recipNonce in corresponding ip message
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 if only a signing key
  -- pair has been sent in ir for certification, or if POP is not
  -- done in this in-band exchange.  Otherwise, the MAC is based on
  -- a key derived from the symmetric key used to decrypt the
  -- returned encryptedCert.
senderKID            referenceNum
  -- the reference number which the CA has previously issued to the
  -- end entity (together with the MACing key)
body                 conf (PKIConfirmContent)
  -- this is an ASN.1 NULL
protection           present
  -- bits calculated using MSG_MAC_ALG
ToP   noToC   RFC2510 - Page 62
B9. 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 confirmation. All messages
   are authenticated.

   The profile for this exchange is identical to that given in Section
   B8 with the following exceptions:

     - protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request,
       response, and confirm messages (the determination in the confirm
       message being dependent upon POP considerations for key-
       encipherment and key- agreement certificate requests);
     - senderKID and recipKID are only present if required for message
       verification;
     - body is cr or cp;
       - protocolEncKey is not present;
     - protection bits are calculated according to the protectionAlg
       field.

B10. Key Update Request

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

   The profile for this exchange is identical to that given in Section
   B8 with the following exceptions:

     - protectionAlg may be MSG_MAC_ALG or MSG_SIG_ALG in request,
       response, and confirm messages (the determination in the confirm
       message being dependent upon POP considerations for key-
       encipherment and key- agreement certificate requests);
     - senderKID and recipKID are only present if required for message
       verification;
     - body is kur or kup;
     - protection bits are calculated according to the protectionAlg
       field.
ToP   noToC   RFC2510 - Page 63

Appendix C: "Compilable" ASN.1 Module using 1988 Syntax

PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS Certificate, CertificateList, Extensions, AlgorithmIdentifier FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)}} GeneralName, KeyIdentifier, ReasonFlags FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)} CertTemplate, PKIPublicationInfo, EncryptedValue, CertId, CertReqMessages FROM PKIXCRMF {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-crmf(5)}} -- CertificationRequest -- FROM PKCS10 {no standard ASN.1 module defined; -- implementers need to create their own module to import -- from, or directly include the PKCS10 syntax in this module} -- Locally defined OIDs -- PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL } PKIHeader ::= SEQUENCE { pvno INTEGER { ietf-version2 (1) }, sender GeneralName, -- identifies the sender recipient GeneralName,
ToP   noToC   RFC2510 - Page 64
      -- identifies the intended recipient
      messageTime     [0] GeneralizedTime         OPTIONAL,
      -- time of production of this message (used when sender
      -- believes that the transport will be "suitable"; i.e.,
      -- that the time will still be meaningful upon receipt)
      protectionAlg   [1] AlgorithmIdentifier     OPTIONAL,
      -- algorithm used for calculation of protection bits
      senderKID       [2] KeyIdentifier           OPTIONAL,
      recipKID        [3] KeyIdentifier           OPTIONAL,
      -- to identify specific keys used for protection
      transactionID   [4] OCTET STRING            OPTIONAL,
      -- identifies the transaction; i.e., this will be the same in
      -- corresponding request, response and confirmation messages
      senderNonce     [5] OCTET STRING            OPTIONAL,
      recipNonce      [6] OCTET STRING            OPTIONAL,
      -- nonces used to provide replay protection, senderNonce
      -- is inserted by the creator of this message; recipNonce
      -- is a nonce previously inserted in a related message by
      -- the intended recipient of this message
      freeText        [7] PKIFreeText             OPTIONAL,
      -- this may be used to indicate context-specific instructions
      -- (this field is intended for human consumption)
      generalInfo     [8] SEQUENCE SIZE (1..MAX) OF
                             InfoTypeAndValue     OPTIONAL
      -- this may be used to convey context-specific information
      -- (this field not primarily intended for human consumption)
  }

  PKIFreeText ::= SEQUENCE SIZE (1..MAX) OF UTF8String
      -- text encoded as UTF-8 String (note:  each UTF8String SHOULD
      -- include an RFC 1766 language tag to indicate the language
      -- of the contained text)


  PKIBody ::= CHOICE {       -- message-specific body elements
      ir      [0]  CertReqMessages,        --Initialization Request
      ip      [1]  CertRepMessage,         --Initialization Response
      cr      [2]  CertReqMessages,        --Certification Request
      cp      [3]  CertRepMessage,         --Certification Response
      p10cr   [4]  CertificationRequest,   --imported from [PKCS10]
      popdecc [5]  POPODecKeyChallContent, --pop Challenge
      popdecr [6]  POPODecKeyRespContent,  --pop Response
      kur     [7]  CertReqMessages,        --Key Update Request
      kup     [8]  CertRepMessage,         --Key Update Response
      krr     [9]  CertReqMessages,        --Key Recovery Request
      krp     [10] KeyRecRepContent,       --Key Recovery Response
      rr      [11] RevReqContent,          --Revocation Request
      rp      [12] RevRepContent,          --Revocation Response
ToP   noToC   RFC2510 - Page 65
      ccr     [13] CertReqMessages,        --Cross-Cert. Request
      ccp     [14] CertRepMessage,         --Cross-Cert. Response
      ckuann  [15] CAKeyUpdAnnContent,     --CA Key Update Ann.
      cann    [16] CertAnnContent,         --Certificate Ann.
      rann    [17] RevAnnContent,          --Revocation Ann.
      crlann  [18] CRLAnnContent,          --CRL Announcement
      conf    [19] PKIConfirmContent,      --Confirmation
      nested  [20] NestedMessageContent,   --Nested Message
      genm    [21] GenMsgContent,          --General Message
      genp    [22] GenRepContent,          --General Response
      error   [23] ErrorMsgContent         --Error Message
  }

  PKIProtection ::= BIT STRING

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

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

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


  NestedMessageContent ::= PKIMessage

  PKIStatus ::= INTEGER {
      granted                (0),
      -- you got exactly what you asked for
      grantedWithMods        (1),
ToP   noToC   RFC2510 - Page 66
      -- 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
      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
      -- CertReqMsg
  }

  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 (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
ToP   noToC   RFC2510 - Page 67
  }

  OOBCert ::= Certificate

  OOBCertHash ::= SEQUENCE {
      hashAlg     [0] AlgorithmIdentifier     OPTIONAL,
      certId      [1] CertId                  OPTIONAL,
      hashVal         BIT STRING
      -- hashVal is calculated over DER encoding of the
      -- subjectPublicKey field of the corresponding cert.
  }

  POPODecKeyChallContent ::= SEQUENCE OF Challenge
  -- One Challenge per encryption key certification request (in the
  -- same order as these requests appear in CertReqMessages).

  Challenge ::= SEQUENCE {
      owf                 AlgorithmIdentifier  OPTIONAL,
      -- MUST be present in the first Challenge; MAY be omitted in any
      -- subsequent Challenge in POPODecKeyChallContent (if omitted,
      -- then the owf used in the immediately preceding Challenge is
      -- to be used).
      witness             OCTET STRING,
      -- the result of applying the one-way function (owf) to a
      -- randomly-generated INTEGER, A.  [Note that a different
      -- INTEGER MUST be used for each Challenge.]
      challenge           OCTET STRING
      -- the encryption (under the public key for which the cert.
      -- request is being made) of Rand, where Rand is specified as
      --   Rand ::= SEQUENCE {
      --      int      INTEGER,
      --       - the randomly-generated INTEGER A (above)
      --      sender   GeneralName
      --       - the sender's name (as included in PKIHeader)
      --   }
  }

  POPODecKeyRespContent ::= SEQUENCE OF INTEGER
  -- One INTEGER per encryption key certification request (in the
  -- same order as these requests appear in CertReqMessages).  The
  -- retrieved INTEGER A (above) is returned to the sender of the
  -- corresponding Challenge.


  CertRepMessage ::= SEQUENCE {
      caPubs       [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL,
      response         SEQUENCE OF CertResponse
  }
ToP   noToC   RFC2510 - Page 68
  CertResponse ::= SEQUENCE {
      certReqId           INTEGER,
      -- to match this response with corresponding request (a value
      -- of -1 is to be used if certReqId is not specified in the
      -- corresponding request)
      status              PKIStatusInfo,
      certifiedKeyPair    CertifiedKeyPair    OPTIONAL,
      rspInfo             OCTET STRING        OPTIONAL
      -- analogous to the id-regInfo-asciiPairs OCTET STRING defined
      -- for regInfo in CertReqMsg [CRMF]
  }

  CertifiedKeyPair ::= SEQUENCE {
      certOrEncCert       CertOrEncCert,
      privateKey      [0] EncryptedValue      OPTIONAL,
      publicationInfo [1] PKIPublicationInfo  OPTIONAL
  }

  CertOrEncCert ::= CHOICE {
      certificate     [0] Certificate,
      encryptedCert   [1] EncryptedValue
  }

  KeyRecRepContent ::= SEQUENCE {
      status                  PKIStatusInfo,
      newSigCert          [0] Certificate                   OPTIONAL,
      caCerts             [1] SEQUENCE SIZE (1..MAX) OF
                                          Certificate       OPTIONAL,
      keyPairHist         [2] SEQUENCE SIZE (1..MAX) OF
                                          CertifiedKeyPair  OPTIONAL
  }

  RevReqContent ::= SEQUENCE OF RevDetails

  RevDetails ::= SEQUENCE {
      certDetails         CertTemplate,
      -- allows requester to specify as much as they can about
      -- the cert. for which revocation is requested
      -- (e.g., for cases in which serialNumber is not available)
      revocationReason    ReasonFlags      OPTIONAL,
      -- the reason that revocation is requested
      badSinceDate        GeneralizedTime  OPTIONAL,
      -- indicates best knowledge of sender
      crlEntryDetails     Extensions       OPTIONAL
      -- requested crlEntryExtensions
  }

  RevRepContent ::= SEQUENCE {
ToP   noToC   RFC2510 - Page 69
      status       SEQUENCE SIZE (1..MAX) OF PKIStatusInfo,
      -- in same order as was sent in RevReqContent
      revCerts [0] SEQUENCE SIZE (1..MAX) OF CertId OPTIONAL,
      -- IDs for which revocation was requested (same order as status)
      crls     [1] SEQUENCE SIZE (1..MAX) OF CertificateList  OPTIONAL
      -- the resulting CRLs (there may be more than one)
  }


  CAKeyUpdAnnContent ::= SEQUENCE {
      oldWithNew          Certificate, -- old pub signed with new priv
      newWithOld          Certificate, -- new pub signed with old priv
      newWithNew          Certificate  -- new pub signed with new priv
  }

  CertAnnContent ::= Certificate

  RevAnnContent ::= SEQUENCE {
      status              PKIStatus,
      certId              CertId,
      willBeRevokedAt     GeneralizedTime,
      badSinceDate        GeneralizedTime,
      crlDetails          Extensions  OPTIONAL
      -- extra CRL details(e.g., crl number, reason, location, etc.)
}

  CRLAnnContent ::= SEQUENCE OF CertificateList

  PKIConfirmContent ::= NULL

  InfoTypeAndValue ::= SEQUENCE {
      infoType               OBJECT IDENTIFIER,
      infoValue              ANY DEFINED BY infoType  OPTIONAL
  }
  -- Example InfoTypeAndValue contents include, but are not limited to:
  --  { CAProtEncCert    = {id-it 1}, Certificate                     }
  --  { SignKeyPairTypes = {id-it 2}, SEQUENCE OF AlgorithmIdentifier }
  --  { EncKeyPairTypes  = {id-it 3}, SEQUENCE OF AlgorithmIdentifier }
  --  { PreferredSymmAlg = {id-it 4}, AlgorithmIdentifier             }
  --  { CAKeyUpdateInfo  = {id-it 5}, CAKeyUpdAnnContent              }
  --  { CurrentCRL       = {id-it 6}, CertificateList                 }
  -- where {id-it} = {id-pkix 4} = {1 3 6 1 5 5 7 4}
  -- This construct MAY also be used to define new PKIX Certificate
  -- Management Protocol request and response messages, or general-
  -- purpose (e.g., announcement) messages for future needs or for
  -- specific environments.

  GenMsgContent ::= SEQUENCE OF InfoTypeAndValue
ToP   noToC   RFC2510 - Page 70
  -- May be sent by EE, RA, or CA (depending on message content).
  -- The OPTIONAL infoValue parameter of InfoTypeAndValue will typically
  -- be omitted for some of the examples given above.  The receiver is
  -- free to ignore any contained OBJ. IDs that it does not recognize.
  -- If sent from EE to CA, the empty set indicates that the CA may send
  -- any/all information that it wishes.

  GenRepContent ::= SEQUENCE OF InfoTypeAndValue
  -- The receiver is free to ignore any contained OBJ. IDs that it does
  -- not recognize.

  ErrorMsgContent ::= SEQUENCE {
      pKIStatusInfo          PKIStatusInfo,
      errorCode              INTEGER           OPTIONAL,
      -- implementation-specific error codes
      errorDetails           PKIFreeText       OPTIONAL
      -- implementation-specific error details
  }



-- The following definition is provided for compatibility reasons with
-- 1988 and 1993 ASN.1 compilers which allow the use of UNIVERSAL class
-- tags (not a part of formal ASN.1); 1997 and subsequent compilers
-- SHOULD comment out this line.

UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING

END
ToP   noToC   RFC2510 - Page 71

Appendix D: Registration of MIME Type for Section 5

To: ietf-types@iana.org Subject: Registration of MIME media type application/pkixcmp MIME media type name: application MIME subtype name: pkixcmp Required parameters: - Optional parameters: - Encoding considerations: Content may contain arbitrary octet values (the ASN.1 DER encoding of a PKI message, as defined in the IETF PKIX Working Group specifications). base64 encoding is required for MIME e-mail; no encoding is necessary for HTTP. Security considerations: This MIME type may be used to transport Public-Key Infrastructure (PKI) messages between PKI entities. These messages are defined by the IETF PKIX Working Group and are used to establish and maintain an Internet X.509 PKI. There is no requirement for specific security mechanisms to be applied at this level if the PKI messages themselves are protected as defined in the PKIX specifications. Interoperability considerations: - Published specification: this document Applications which use this media type: Applications using certificate management, operational, or ancillary protocols (as defined by the IETF PKIX Working Group) to send PKI messages via E-Mail or HTTP. Additional information: Magic number (s): - File extension (s): ".PKI" Macintosh File Type Code (s): - Person and email address to contact for further information: Carlisle Adams, cadams@entrust.com Intended usage: COMMON Author/Change controller: Carlisle Adams
ToP   noToC   RFC2510 - Page 72
Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.