1. Michael Myers VeriSign, Inc. mmyers@verisign.com
CMC (RFC 2797)
Michael Myers
VeriSign, Inc.

2. Objectives
Industry de-facto standard use of PKCS-10 for certificate requests and PKCS-7 for responses.
Primary objectives:
Simplify online certificate management by building on existing PKCS7 and PKCS10 practice.
Reuse existing security encapsulation mechanism then being standardized as CMS in the IETF.
Define core functions useful for automated certificate management.
Straw poll of WG at San Jose IETF ratified the need for an alternative.

3. Background VeriSign, Cisco started work earlier.
Went through several variations (including a draft called Certificate Request Syntax (CRS)).
Emerged as Certificate Management over CMS (CMC) with Certificate Request Message Format (CRMF) as a by-product.
Brian LaMacchia and Jim Schaad are principal technical architects of final versions.
Now RFC 2797.

4. Top-Level Requirements
Based as much as possible on the existing CMS, PKCS#10 and CRMF specifications.
Support the current industry practice of a PKCS#10 request followed by a PKCS#7 response as a subset of the protocol.
Must easily support the multi-key enrollment protocols required by S/MIME and other groups.
Must supply a way of doing operations in a single-round trip whenever possible.
Enable all key generation to occur on the client.
Support mandatory and optional algorithms.
Support pending responses to certificate requests for cases where external procedures are required to issue a certificate.
Support Registration Authorities.

5. Protocol Overview
Standardizes use of bare PKCS-10 for environments with a need for it.
Defines a means to “wrap a 10 in a 7”.
i.e use of CMS to encapsulate the PKCS 10 object.
May also use CRMF instead of a 10.
Responses based on CMS signedData.
Again, this could be nothing more than a “7”.
Or a responseBody in a CMS encapsulation.

6. Services Issuance (direct and deferred) Revocation
Registration authority intervention
Certificate/CRL retrieval
Replay detection through nonces
Transaction management through transaction IDs.

7. Simple request/response
Simple PKI Request Simple PKI Response
| PKCS #10 | | CMS "certs-only" |
| message |
| |
| Certificate Request | | |
| | | CMS Signed Data, |
| Subject Name | | no signerInfo |
| Subject Public Key Info | | |
| (K_PUB) | | signedData contains one |
| Attributes* | | or more certificates in |
| | | the "certificates" |
| portion of the |
| signed with | | signedData |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
| is empty |
| |
| unsigned |

8. Full Request/Response
| CMS signedData | | CMS signedData |
| object | | object |
| | | |
| PKIData object | | ResponseBody object |
| Sequence of: | | Sequence of: |
| <enrollment attribute>* | | <enrollment attribute>* |
| <certification request>*| | <CMS object>* |
| <CMS objects>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certificate requests | | as part of the response |
| are CRMF or PKCS# | | are included in the |
| objects. Attributes are | | "certificates" portion |
| (OID, ANY defined by | | of the signedData |
| OID) pairs | | Relevant CA certs and |
| | | CRLs can be included as |
| well |
| signed (keypair | | |
| used may be pre-|
| existing or | | signed by the |
| identified in | | CA or an LRA |
| the request) |

9. Control Attributes ----------------- ---------- --------------
Control Attribute OID Syntax
cMCStatusInfo id-cmc CMCStatusInfo
identification id-cmc UTF8String
identityProof id-cmc OCTET STRING
dataReturn id-cmc OCTET STRING
transactionId id-cmc INTEGER
senderNonce id-cmc OCTET STRING
recipientNonce id-cmc OCTET STRING
addExtensions id-cmc AddExtensions
encryptedPOP id-cmc EncryptedPOP
decryptedPOP id-cmc DecryptedPOP
lraPOPWitness id-cmc LraPOPWitness
getCert id-cmc GetCert
getCRL id-cmc GetCRL
revokeRequest id-cmc RevokeRequest
regInfo id-cmc OCTET STRING
responseInfo id-cmc OCTET STRING
QueryPending id-cmc OCTET STRING
idPOPLinkRandom id-cmc OCTET STRING
idPOPLinkWitness id-cmc OCTET STRING
idConfirmCertAcceptance id-cmc CMCCertId

10. A few other technical details
Subscriber privacy achieved through use of CMS enveloped data mechanisms.
Three transport wrapping options
MIME for HTTP and
Binary for out of band floppy disk transfer (either bare or MIME)
Socket-based using the raw BER encoding.
Able to prove identity based on a shared secret.
Able to prove possession of encryption-only keys.
Able to link identity proof to possession proof.