tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2510

 
 
 

Internet X.509 Public Key Infrastructure Certificate Management Protocols

Part 3 of 3, p. 38 to 72
Prev RFC Part

 


prevText      Top       Page 38 
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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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.