tech-invite   World Map
3GPP     Specs     Glossaries     UICC       T+       IETF     RFCs     Groups     SIP     ABNFs       Search     Home

RFC 4210

 
 
 

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

Part 5 of 5, p. 75 to 95
Prev RFC Part

 


prevText      Top      Up      ToC       Page 75 
Appendix E.  PKI Management Message Profiles (OPTIONAL).

   This appendix contains detailed profiles for those PKIMessages that
   MAY be supported by implementations (in addition to the messages
   which MUST be supported; see Section 6 and Appendix D).

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

   o  root CA key update

   o  information request/response

Top      Up      ToC       Page 76 
   o  cross-certification request/response (1-way)

   o  in-band initialization using external identity certificate

   Later versions of this document may extend the above to include
   profiles for the operations listed below (along with other
   operations, if desired).

   o  revocation request

   o  certificate publication

   o  CRL publication

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

   Identical to Appendix D.1.

E.2.  Algorithm Use Profile

   Identical to Appendix D.2.

E.3.  Self-Signed Certificates

   Profile of how a Certificate structure may be "self-signed".  These
   structures are used for distribution of CA public keys.  This can
   occur in one of three ways (see Section 4.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

   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.

Top      Up      ToC       Page 77 
E.4.  Root CA Key Update

   A root CA updates its key pair.  It then produces a CA key update
   announcement message that can be made available (via some transport
   mechanism) to the relevant end entities.  A confirmation message is
   NOT REQUIRED from the end entities.

   ckuann message:

    Field        Value                        Comment
   --------------------------------------------------------------
    sender       CA name CA name
    body         ckuann(CAKeyUpdAnnContent)
    oldWithNew   present                  see Appendix E.3 above
    newWithOld   present                  see Appendix E.3 above
    newWithNew   present                  see Appendix E.3 above
    extraCerts   optionally present       can be used to "publish"
                                          certificates (e.g.,
                                          certificates signed using
                                          the new private key)

E.5.  PKI Information Request/Response

   The end entity sends a general message to the PKI requesting details
   that will be required for later PKI management operations.  RA/CA
   responds with a general response.  If an RA generates the response,
   then it will simply forward the equivalent message that it previously
   received from the CA, with the possible addition of certificates to
   the extraCerts fields of the PKIMessage.  A confirmation 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

Top      Up      ToC       Page 78 
     -- 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

   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 that this CA will
     -- certify for subject public keys
   EncKeyPairTypes      present, with relevant value
     -- the set of encryption/key agreement algorithm identifiers that
     -- this CA will certify for subject public keys
   PreferredSymmAlg     present (object identifier one
                        of PROT_SYM_ALG) , with relevant
                        value
     -- the symmetric algorithm that 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

Top      Up      ToC       Page 79 
     -- 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.

E.6.  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.

   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

   The use of certificate confirmation and the corresponding server
   confirmation is determined by the generalInfo field in the PKIHeader
   (see Section 5.1.1).  The following profile does not mandate support
   for either confirmation.

   Message Flows:

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

   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

Top      Up      ToC       Page 80 
     -- 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
   recipKID             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
     -- 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
     -- that it requires to be in the cross-certificate
   POPOSigningKey        present
     -- see Section D3: Proof-of-possession profile
   protection            present
     -- bits calculated using MSG_SIG_ALG
   extraCerts            optionally present
     -- MAY contain any additional certificates that requester wishes
     -- to include

Top      Up      ToC       Page 81 
   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
   -- 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:
     --   accepted, 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

Top      Up      ToC       Page 82 
     -- 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

E.7.  In-Band Initialization Using External Identity Certificate

   An (uninitialized) end entity wishes to initialize into the PKI with
   a CA, CA-1.  It uses, for authentication purposes, a pre-existing
   identity certificate issued by another (external) CA, CA-X.  A trust
   relationship must already have been established between CA-1 and CA-X
   so that CA-1 can validate the EE identity certificate signed by CA-X.
   Furthermore, some mechanism must already have been established within
   the Personal Security Environment (PSE) of the EE that would allow it
   to authenticate and verify PKIMessages signed by CA-1 (as one
   example, the PSE may contain a certificate issued for the public key
   of CA-1, signed by another CA that the EE trusts on the basis of
   out-of-band authentication techniques).

   The EE sends an initialization request to start the transaction.
   When CA-1 responds with a message containing the new certificate, the
   end entity replies with a certificate confirmation.  CA-1 replies
   with a PKIConfirm to close the transaction.  All messages are signed
   (the EE messages are signed using the private key that corresponds to
   the public key in its external identity certificate; the CA-1
   messages are signed using the private key that corresponds to the
   public key in a

   certificate that can be chained to a trust anchor in the EE's PSE).

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

   o  the EE and CA-1 do not share a symmetric MACing key (i.e., there
      is no out-of-band shared secret information between these
      entities);

   o  sender name in ir MUST be present (and identical to the subject
      name present in the external identity certificate);

   o  protectionAlg of MSG_SIG_ALG MUST be used in all messages;

   o  external identity cert.  MUST be carried in ir extraCerts field

   o  senderKID and recipKID are not used;

Top      Up      ToC       Page 83 
   o  body is ir or ip;

   o  protection bits are calculated according to the protectionAlg
      field.

Appendix F.  Compilable ASN.1 Definitions

     PKIXCMP {iso(1) identified-organization(3)
           dod(6) internet(1) security(5) mechanisms(5) pkix(7)
           id-mod(0) id-mod-cmp2000(16)}

     DEFINITIONS EXPLICIT TAGS ::=

     BEGIN

     -- EXPORTS ALL --

     IMPORTS

         Certificate, CertificateList, Extensions, AlgorithmIdentifier,
         UTF8String -- if required; otherwise, comment out
                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
                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-2005 {iso(1) identified-organization(3)
                dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                id-mod(0) id-mod-crmf2005(36)}

         -- see also the behavioral clarifications to CRMF codified in
         -- Appendix C of this specification

         CertificationRequest
                FROM PKCS-10 {iso(1) member-body(2)
                              us(840) rsadsi(113549)
                              pkcs(1) pkcs-10(10) modules(1) pkcs-10(1)}

         -- (specified in RFC 2986 with 1993 ASN.1 syntax and IMPLICIT
         -- tags).  Alternatively, implementers may directly include
         -- the [PKCS10] syntax in this module

Top      Up      ToC       Page 84 
         ;

   -- the rest of the module contains locally-defined OIDs and
   -- constructs

      CMPCertificate ::= CHOICE {
         x509v3PKCert        Certificate
      }
   -- This syntax, while bits-on-the-wire compatible with the
   -- standard X.509 definition of "Certificate", allows the
   -- possibility of future certificate types (such as X.509
   -- attribute certificates, WAP WTLS certificates, or other kinds
   -- of certificates) within this certificate management protocol,
   -- should a need ever arise to support such generality.  Those
   -- implementations that do not foresee a need to ever support
   -- other certificate types MAY, if they wish, comment out the
   -- above structure and "un-comment" the following one prior to
   -- compiling this ASN.1 module.  (Note that interoperability
   -- with implementations that don't do this will be unaffected by
   -- this change.)

   -- CMPCertificate ::= Certificate

      PKIMessage ::= SEQUENCE {
         header           PKIHeader,
         body             PKIBody,
         protection   [0] PKIProtection OPTIONAL,
         extraCerts   [1] SEQUENCE SIZE (1..MAX) OF CMPCertificate
                          OPTIONAL
     }

     PKIMessages ::= SEQUENCE SIZE (1..MAX) OF PKIMessage

     PKIHeader ::= SEQUENCE {
         pvno                INTEGER     { cmp1999(1), cmp2000(2) },
         sender              GeneralName,
         -- identifies the sender
         recipient           GeneralName,
         -- 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

Top      Up      ToC       Page 85 
         transactionID   [4] OCTET STRING            OPTIONAL,
         -- identifies the transaction; i.e., this will be the same in
         -- corresponding request, response, certConf, and PKIConf
         -- 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 [RFC3629] (note: each
         -- UTF8String MAY include an [RFC3066] language tag
         -- to indicate the language of the contained text
         -- see [RFC2482] for details)

     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
         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
         pkiconf  [19] PKIConfirmContent,      --Confirmation
         nested   [20] NestedMessageContent,   --Nested Message
         genm     [21] GenMsgContent,          --General Message

Top      Up      ToC       Page 86 
         genp     [22] GenRepContent,          --General Response
         error    [23] ErrorMsgContent,        --Error Message
         certConf [24] CertConfirmContent,     --Certificate confirm
         pollReq  [25] PollReqContent,         --Polling request
         pollRep  [26] PollRepContent          --Polling response
     }

     PKIProtection ::= BIT STRING

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

     id-PasswordBasedMac OBJECT IDENTIFIER ::= {1 2 840 113533 7 66 13}
     PBMParameter ::= SEQUENCE {
         salt                OCTET STRING,
         -- note:  implementations MAY wish to limit acceptable sizes
         -- of this string to values appropriate for their environment
         -- in order to reduce the risk of denial-of-service attacks
         owf                 AlgorithmIdentifier,
         -- AlgId for a One-Way Function (SHA-1 recommended)
         iterationCount      INTEGER,
         -- number of times the OWF is applied
         -- note:  implementations MAY wish to limit acceptable sizes
         -- of this integer to values appropriate for their environment
         -- in order to reduce the risk of denial-of-service attacks
         mac                 AlgorithmIdentifier
         -- the MAC AlgId (e.g., DES-MAC, Triple-DES-MAC [PKCS11],
     }   -- or HMAC [RFC2104, RFC2202])

     id-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 ::= PKIMessages

     PKIStatus ::= INTEGER {
         accepted                (0),
         -- you got exactly what you asked for
         grantedWithMods        (1),
         -- you got something like what you asked for; the
         -- requester is responsible for ascertaining the differences

Top      Up      ToC       Page 87 
         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 (note: proper handling of this status
         -- response MAY use the polling req/rep PKIMessages specified
         -- in Section 5.3.22; alternatively, polling in the underlying
         -- transport layer MAY have some utility in this regard)
         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
         certRevoked         (10),
            -- the certificate has already been revoked
         certConfirmed       (11),
            -- the certificate has already been confirmed

Top      Up      ToC       Page 88 
         wrongIntegrity      (12),
            -- invalid integrity, password based instead of signature or
            -- vice versa
         badRecipientNonce   (13),
            -- invalid recipient nonce, either missing or wrong value
         timeNotAvailable    (14),
            -- the TSA's time source is not available
         unacceptedPolicy    (15),
            -- the requested TSA policy is not supported by the TSA.
         unacceptedExtension (16),
            -- the requested extension is not supported by the TSA.
         addInfoNotAvailable (17),
            -- the additional information requested could not be
            -- understood or is not available
         badSenderNonce      (18),
            -- invalid sender nonce, either missing or wrong size
         badCertTemplate     (19),
            -- invalid cert. template or missing mandatory information
         signerNotTrusted    (20),
            -- signer of the message unknown or not trusted
         transactionIdInUse  (21),
            -- the transaction identifier is already in use
         unsupportedVersion  (22),
            -- the version of the message is not supported
         notAuthorized       (23),
            -- the sender was not authorized to make the preceding
            -- request or perform the preceding action
         systemUnavail       (24),
         -- the request cannot be handled due to system unavailability
         systemFailure       (25),
         -- the request cannot be handled due to system failure
         duplicateCertReq    (26)
         -- certificate cannot be issued because a duplicate
         -- certificate already exists
     }

     PKIStatusInfo ::= SEQUENCE {
         status        PKIStatus,
         statusString  PKIFreeText     OPTIONAL,
         failInfo      PKIFailureInfo  OPTIONAL
     }

     OOBCert ::= CMPCertificate

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

Top      Up      ToC       Page 89 
         -- hashVal is calculated over the DER encoding of the
         -- self-signed certificate with the identifier certID.
     }

     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 CMPCertificate
                          OPTIONAL,
         response         SEQUENCE OF CertResponse
     }

     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)

Top      Up      ToC       Page 90 
         status              PKIStatusInfo,
         certifiedKeyPair    CertifiedKeyPair    OPTIONAL,
         rspInfo             OCTET STRING        OPTIONAL
         -- analogous to the id-regInfo-utf8Pairs string defined
         -- for regInfo in CertReqMsg [CRMF]
     }

     CertifiedKeyPair ::= SEQUENCE {
         certOrEncCert       CertOrEncCert,
         privateKey      [0] EncryptedValue      OPTIONAL,
         -- see [CRMF] for comment on encoding
         publicationInfo [1] PKIPublicationInfo  OPTIONAL
     }

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

     KeyRecRepContent ::= SEQUENCE {
         status                  PKIStatusInfo,
         newSigCert          [0] CMPCertificate OPTIONAL,
         caCerts             [1] SEQUENCE SIZE (1..MAX) OF
                                             CMPCertificate 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)
         crlEntryDetails     Extensions       OPTIONAL
         -- requested crlEntryExtensions
     }

     RevRepContent ::= SEQUENCE {
         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

Top      Up      ToC       Page 91 
         -- the resulting CRLs (there may be more than one)
     }

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

     CertAnnContent ::= CMPCertificate

     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

     CertConfirmContent ::= SEQUENCE OF CertStatus

     CertStatus ::= SEQUENCE {
        certHash    OCTET STRING,
        -- the hash of the certificate, using the same hash algorithm
        -- as is used to create and verify the certificate signature
        certReqId   INTEGER,
        -- to match this confirmation with the corresponding req/rep
        statusInfo  PKIStatusInfo OPTIONAL
     }

     PKIConfirmContent ::= NULL

     InfoTypeAndValue ::= SEQUENCE {
         infoType               OBJECT IDENTIFIER,
         infoValue              ANY DEFINED BY infoType  OPTIONAL
     }
     -- Example InfoTypeAndValue contents include, but are not limited
     -- to, the following (un-comment in this ASN.1 module and use as
     -- appropriate for a given environment):
     --
     --   id-it-caProtEncCert    OBJECT IDENTIFIER ::= {id-it 1}
     --      CAProtEncCertValue      ::= CMPCertificate
     --   id-it-signKeyPairTypes OBJECT IDENTIFIER ::= {id-it 2}
     --      SignKeyPairTypesValue   ::= SEQUENCE OF AlgorithmIdentifier
     --   id-it-encKeyPairTypes  OBJECT IDENTIFIER ::= {id-it 3}

Top      Up      ToC       Page 92 
     --      EncKeyPairTypesValue    ::= SEQUENCE OF AlgorithmIdentifier
     --   id-it-preferredSymmAlg OBJECT IDENTIFIER ::= {id-it 4}
     --      PreferredSymmAlgValue   ::= AlgorithmIdentifier
     --   id-it-caKeyUpdateInfo  OBJECT IDENTIFIER ::= {id-it 5}
     --      CAKeyUpdateInfoValue    ::= CAKeyUpdAnnContent
     --   id-it-currentCRL       OBJECT IDENTIFIER ::= {id-it 6}
     --      CurrentCRLValue         ::= CertificateList
     --   id-it-unsupportedOIDs  OBJECT IDENTIFIER ::= {id-it 7}
     --      UnsupportedOIDsValue    ::= SEQUENCE OF OBJECT IDENTIFIER
     --   id-it-keyPairParamReq  OBJECT IDENTIFIER ::= {id-it 10}
     --      KeyPairParamReqValue    ::= OBJECT IDENTIFIER
     --   id-it-keyPairParamRep  OBJECT IDENTIFIER ::= {id-it 11}
     --      KeyPairParamRepValue    ::= AlgorithmIdentifer
     --   id-it-revPassphrase    OBJECT IDENTIFIER ::= {id-it 12}
     --      RevPassphraseValue      ::= EncryptedValue
     --   id-it-implicitConfirm  OBJECT IDENTIFIER ::= {id-it 13}
     --      ImplicitConfirmValue    ::= NULL
     --   id-it-confirmWaitTime  OBJECT IDENTIFIER ::= {id-it 14}
     --      ConfirmWaitTimeValue    ::= GeneralizedTime
     --   id-it-origPKIMessage   OBJECT IDENTIFIER ::= {id-it 15}
     --      OrigPKIMessageValue     ::= PKIMessages
     --   id-it-suppLangTags     OBJECT IDENTIFIER ::= {id-it 16}
     --      SuppLangTagsValue       ::= SEQUENCE OF UTF8String
     --
     -- where
     --
     --   id-pkix OBJECT IDENTIFIER ::= {
     --      iso(1) identified-organization(3)
     --      dod(6) internet(1) security(5) mechanisms(5) pkix(7)}
     -- and
     --   id-it   OBJECT IDENTIFIER ::= {id-pkix 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

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

Top      Up      ToC       Page 93 
     GenRepContent ::= SEQUENCE OF InfoTypeAndValue
     -- Receiver MAY ignore any contained OIDs that it does not
     -- recognize.

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

     PollReqContent ::= SEQUENCE OF SEQUENCE {
         certReqId              INTEGER
     }

     PollRepContent ::= SEQUENCE OF SEQUENCE {
         certReqId              INTEGER,
         checkAfter             INTEGER,  -- time in seconds
         reason                 PKIFreeText OPTIONAL
     }

     END -- of CMP module

Appendix G.  Acknowledgements

   The authors gratefully acknowledge the contributions of various
   members of the IETF PKIX Working Group and the ICSA CA-talk mailing
   list (a list solely devoted to discussing CMP interoperability
   efforts).  Many of these contributions significantly clarified and
   improved the utility of this specification.  Tomi Kause thanks Vesa
   Suontama and Toni Tammisalo for review and comments.

Top      Up      ToC       Page 94 
Authors' Addresses

   Carlisle Adams
   University of Ottawa
   800 King Edward Avenue
   P.O.Box 450, Station A
   Ottawa, Ontario  K1N 6N5
   CA

   Phone: (613) 562-5800 ext. 2345
   Fax:   (613) 562-5664
   EMail: cadams@site.uottawa.ca


   Stephen Farrell
   Trinity College Dublin
   Distributed Systems Group
   Computer Science Department
   Dublin
   IE

   Phone: +353-1-608-2945
   EMail: stephen.farrell@cs.tcd.ie


   Tomi Kause
   SSH Communications Security Corp
   Valimotie 17
   Helsinki  00380
   FI

   Phone: +358 20 500 7415
   EMail: toka@ssh.com


   Tero Mononen
   SafeNet, Inc.
   Fredrikinkatu 47
   Helsinki  00100
   FI

   Phone: +358 20 500 7814
   EMail: tmononen@safenet-inc.com

Top      Up      ToC       Page 95 
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.