RFC 2797        Certificate Management Messages over CMS      April 2000   For the enrollment response the signedData wrapper allows the server   to sign the returning data, if any exists, and to carry the   certificates and CRLs for the enrollment request.  If no data is   being returned beyond the certificates, no signerInfo objects are   placed in the signedData object.3.6.2  Enveloped Data   EnvelopedData is the primary method of providing confidentiality for   sensitive information in this protocol.  The protocol currently uses   EnvelopedData to provide encryption of an entire request (see section   4.5).  The envelopedData object would also be used to wrap private   key material for key archival.   Servers MUST implement envelopedData according to [CMS].  There is an   ambiguity (about encrypting content types other than id-data) in the   PKCS7 specification that has lead to non-interoperability.3.7  Other Message Bodies   The other message body portion of the message allows for arbitrary   data objects to be carried as part of a message.  This is intended to   contain data that is not already wrapped in a CMS contentInfo object.   The data is ignored unless a control attribute references the data by   bodyPartId.     OtherMsg ::= SEQUENCE {         bodyPartID        BodyPartID,         otherMsgType      OBJECT IDENTIFIER,         otherMsgValue     ANY DEFINED BY otherMsgType }   -- bodyPartID contains the unique id of this object   -- otherMsgType contains the OID defining both the usage of this body   part and the syntax of the value associated with this body part   -- otherMsgValue contains the data associated with the message body   part.4.  PKI Messages   This section discusses the details of putting together the different   enrollment request and response messages.Myers, et al.               Standards Track                    [Page 12]RFC 2797        Certificate Management Messages over CMS      April 20004.1  Simple Enrollment Request   The simplest form of an enrollment request is a plain PKCS10 message.   If this form of enrollment request is used for a private key that is   capable of generating a signature, the PKCS10 MUST be signed with   that private key.  If this form of the enrollment request is used for   a D-H key, then the D-H POP mechanism described in [DH-POP] MUST be   used.   Servers MUST support the Simple Enrollment Request message. If the   Simple Enrollment Request message is used, servers MUST return the   Simple Enrollment Response message (see Section 4.3) if the   enrollment request is granted.  If the enrollment request fails, the   Full Enrollment Response MAY be returned or no response MAY be   returned.   Many advanced services specified in this memo are not supported by   the Simple Enrollment Request message.4.2  Full PKI Request   The Full Enrollment Request provides the most functionality and   flexibility.  Clients SHOULD use the Full Enrollment Request message   when enrolling.  Servers MUST support the Full Enrollment Request   message.  An enrollment response (full or simple as appropriate) MUST   be returned to all Full Enrollment Requests.   The Full Enrollment Request message consists of a PKIData object   wrapped in a signedData CMS object. The objects in the PKIData are   ordered as follows:   1. All Control Attributes,   2. All certification requests,   3. All CMS objects,   4. All other messages.   Each element in a Full Enrollment Request is identified by a Body   Part Identifier. If duplicate ids are found, the server MUST return   the error badRequest with a bodyPartID of 0.   The signedData object wrapping the PKIData may be signed either by   the private key material of the signature certification request, or   by a previously certified signature key. If the private key of a   signature certification request is being used, then:   a) the certification request containing the corresponding public key      MUST include a Subject Key Identifier extension request,   b) the subjectKeyIdentifier form of signerInfo MUST be used, andMyers, et al.               Standards Track                    [Page 13]RFC 2797        Certificate Management Messages over CMS      April 2000   c) the value of the subjectKeyIdentifier form of signerInfo MUST be      the Subject Key Identifier specified in the corresponding      certification request.   (The subjectKeyIdentifier form of signerInfo is used here because no   certificates have yet been issued for the signing key.) If the   request key is used for signing, there MUST be only one signerInfo   object in the signedData object.   When creating a message to renew a certificate, the following should   be taken into consideration:   1. The identification and identityProof control statements are not      required.  The same information is provided by the use of an      existing certificate from the CA when signing the enrollment      message.   2. CAs and LRAs may impose additional restrictions on the signing      certificate used.  They may require that the most recently issued      signing certificate for an entity be used.   3. A renewal message may occur either by creating a new set of keys,      or by re-using an existing set of keys.  Some CAs may prevent re-      use of keys by policy.  In this case the CA MUST return NOKEYREUSE      as the failure code.4.3  Simple Enrollment Response   Servers SHOULD use the simple enrollment response message whenever   possible.  Clients MUST be able to process the simple enrollment   response message.  The simple enrollment response message consists of   a signedData object with no signerInfo objects on it.  The   certificates requested are returned in the certificate bag of the   signedData object.   Clients MUST NOT assume the certificates are in any order. Servers   SHOULD include all intermediate certificates needed to form complete   chains to one or more self-signed certificates, not just the newly   issued certificate(s). The server MAY additionally return CRLs in the   CRL bag.  Servers MAY include the self-signed certificates. Clients   MUST NOT implicitly trust included self-signed certificate(s) merely   due to its presence in the certificate bag. In the event clients   receive a new self-signed certificate from the server, clients SHOULD   provide a mechanism to enable the user to explicitly trust the   certificate.Myers, et al.               Standards Track                    [Page 14]RFC 2797        Certificate Management Messages over CMS      April 20004.4  Full PKI Response   Servers MUST return full PKI response messages if a) a full PKI   request message failed or b) additional services other than returning   certificates are required.  Servers MAY return full PKI responses   with failure information for simple PKI requests. Following section   4.3 above, servers returning only certificates and a success status   to the client SHOULD use the simple PKI response message.   Clients MUST be able to process a full PKI response message.   The full enrollment response message consists of a signedData object   encapsulating a responseBody object.  In a responseBody object all   Control Attributes MUST precede all CMS objects.  The certificates   granted in an enrollment response are returned in the certificates   field of the immediately encapsulating signedData object.   Clients MUST NOT assume the certificates are in any order. Servers   SHOULD include all intermediate certificates needed to form complete   chains one ore more self-signed certificates, not just the newly   issued certificate(s). The server MAY additionally return CRLs in the   CRL bag.  Servers MAY include the self-signed certificates. Clients   MUST NOT implicitly trust included self-signed certificate(s) merely   due to its presence in the certificate bag. In the event clients   receive a new self-signed certificate from the server, clients SHOULD   provide a mechanism to enable the user to explicitly trust the   certificate.4.5  Application of Encryption to a PKI Message   There are occasions where a PKI request or response message must be   encrypted in order to prevent any information about the enrollment   from being accessible to unauthorized entities.  This section   describes the means used to encrypt a PKI message.  This section is   not applicable to a simple enrollment message.   Confidentiality is provided by wrapping the PKI message (a signedData   object) in a CMS EnvelopedData object.  The nested content type in   the EnvelopedData is id-signedData.  Note that this is different from   S/MIME where there is a MIME layer placed between the encrypted and   signed data objects.  It is recommended that if an enveloped data   layer is applied to a PKI message, a second signing layer be placed   outside of the enveloped data layer.  The following figure shows how   this nesting would be done:Myers, et al.               Standards Track                    [Page 15]RFC 2797        Certificate Management Messages over CMS      April 2000     Normal              Option 1                  Option 2     ------              --------                  --------     SignedData          EnvelopedData             SignedData      PKIData             SignedData                EnvelopedData                           PKIData                   SignedData                                                      PKIData   Options 1 and 2 provide the benefit of preventing leakage of   sensitive data by encrypting the information.  LRAs can remove the   enveloped data wrapping, and replace or forward without further   processing. Section 6 contains more information about LRA processing.   PKI Messages MAY be encrypted or transmitted in the clear.  Servers   MUST provided support for all three versions.   Alternatively, an authenticated, secure channel could exist between   the parties requiring encryption.  Clients and servers MAY use such   channels instead of the technique described above to provide secure,   private communication of PKI request and response messages.5.  Control Attributes   Control attributes are carried as part of both PKI requests and   responses. Each control attribute is encoded as a unique Object   Identifier followed by that data for the control attribute.  The   encoding of the data is based on the control attribute object   identifier.  Processing systems would first detect the OID and   process the corresponding attribute value prior to processing the   message body.   The following table lists the names, OID and syntactic structure for   each of the control attributes documented in this memo.Myers, et al.               Standards Track                    [Page 16]RFC 2797        Certificate Management Messages over CMS      April 2000   Control Attribute         OID            Syntax   -----------------       ----------     --------------   cMCStatusInfo           id-cmc 1       CMCStatusInfo   identification          id-cmc 2       UTF8String   identityProof           id-cmc 3       OCTET STRING   dataReturn              id-cmc 4       OCTET STRING   transactionId           id-cmc 5       INTEGER   senderNonce             id-cmc 6       OCTET STRING   recipientNonce          id-cmc 7       OCTET STRING   addExtensions           id-cmc 8       AddExtensions   encryptedPOP            id-cmc 9       EncryptedPOP   decryptedPOP            id-cmc 10      DecryptedPOP   lraPOPWitness           id-cmc 11      LraPOPWitness   getCert                 id-cmc 15      GetCert   getCRL                  id-cmc 16      GetCRL   revokeRequest           id-cmc 17      RevokeRequest   regInfo                 id-cmc 18      OCTET STRING   responseInfo            id-cmc 19      OCTET STRING   QueryPending            id-cmc 21      OCTET STRING   idPOPLinkRandom         id-cmc 22      OCTET STRING   idPOPLinkWitness        id-cmc 23      OCTET STRING   idConfirmCertAcceptance id-cmc 24      CMCCertId5.1  CMC Status Info Control Attribute