RFC 5272
Certificate Management over CMS (CMC)
Appendix A. ASN.1 Module
EnrollmentMessageSyntax { iso(1) identified-organization(3) dod(4) internet(1) security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc2002(23) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- EXPORTS All -- -- The types and values defined in this module are exported for use -- in the other ASN.1 modules. Other applications may use them for -- their own purposes. IMPORTS -- PKIX Part 1 - Implicit From [PKIXCERT] GeneralName, CRLReason, ReasonFlags FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit(19)} -- PKIX Part 1 - Explicit From [PKIXCERT] AlgorithmIdentifier, Extension, Name, CertificateSerialNumber FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18)} -- Cryptographic Message Syntax FROM [CMS] ContentInfo, Attribute, IssuerAndSerialNumber FROM CryptographicMessageSyntax2004 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2004(24)} -- CRMF FROM [CRMF] CertReqMsg, PKIPublicationInfo, CertTemplate 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)}; -- Global Types UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING -- The content of this type conforms to RFC 2279.
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have the type OCTET STRING
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}
-- The following controls have the type UTF8String
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
-- The following controls have the type INTEGER
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
-- The following controls have the type OCTET STRING
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
-- This is the content type used for a request message in the protocol
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING },
attributes [0] IMPLICIT SET OF Attribute },
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
ResponseBody ::= PKIResponse
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- Used to return status state in a response
id-cmc-statusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartID,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
CMCStatus ::= INTEGER {
success (0),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}
-- Note:
-- The spelling of unsupportedExt is corrected in this version.
-- In RFC 2797, it was unsuportedExt.
CMCFailInfo ::= INTEGER {
badAlg (0),
badMessageCheck (1),
badRequest (2),
badTime (3),
badCertId (4),
unsupportedExt (5),
mustArchiveKeys (6),
badIdentity (7),
popRequired (8),
popFailed (9),
noKeyReuse (10),
internalCAError (11),
tryLater (12),
authDataFail (13)
}
-- Used for RAs to add extensions to certification requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}
CMCCertId ::= IssuerAndSerialNumber
-- The following is used to request V3 extensions be added to a
-- certificate
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extension
-- The following exists to allow Diffie-Hellman Certification Requests
-- Messages to be well-formed
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
-- Unauthenticated attribute to carry removable data.
-- This could be used in an update of "CMC Extensions: Server Side
-- Key Generation and Key Escrow" (February 2005) and in other
-- documents.
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}
-- Replaces CMC Status Info
--
id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF
BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue AttributeValue
}
} OPTIONAL
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
-- Allow for distribution of trust anchors
--
id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}
AuthPublish ::= BodyPartID
-- These two items use BodyPartList
id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}
id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
--
id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE OF OCTET STRING,
pubInfo PKIPublicationInfo
}
id-cmc-modCertTemplate OBJECT IDENTIFIER ::= {id-cmc 31}
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}
-- Inform follow on servers that one or more controls have already been
-- processed
id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}
ControlsProcessed ::= SEQUENCE {
bodyList SEQUENCE SIZE(1..MAX) OF BodyPartReference
}
-- Identity Proof control w/ algorithm agility
id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 34 }
IdentifyProofV2 ::= SEQUENCE {
proofAlgID AlgorithmIdentifier,
macAlgId AlgorithmIdentifier,
witness OCTET STRING
}
id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 33 }
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}
END
Appendix B. Enrollment Message Flows
This section is informational. The purpose of this section is to present, in an abstracted version, the messages that would flow between the client and server for several different common cases.B.1. Request of a Signing Certificate
This section looks at the messages that would flow in the event that an enrollment is occurring for a signing-only key. If the certificate was designed for both signing and encryption, the only difference would be the key usage extension in the certification request. Message #2 from client to server: ContentInfo.contentType = id-signedData ContentInfo.content SignedData.encapContentInfo eContentType = id-ct-PKIData eContent controlSequence {102, id-cmc-identityProof, computed value} {103, id-cmc-senderNonce, 10001} reqSequence certRequest certReqId = 201 certTemplate subject = My Proposed DN publicKey = My Public Key extensions {id-ce-subjectPublicKeyIdentifier, 1000} {id-ce-keyUsage, digitalSignature} SignedData.SignerInfos SignerInfo sid.subjectKeyIdentifier = 1000
Response from server to client:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
B.2. Single Certification Request, But Modified by RA
This section looks at the messages that would flow in the event that
an enrollment has one RA in the middle of the data flow. That RA
will modify the certification request before passing it on to the CA.
Message from client to RA:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-identityProof, computed value}
{103, id-cmc-senderNonce, 10001}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = My Proposed DN
publicKey = My Public Key
extensions
{id-ce-subjectPublicKeyIdentifier, 1000}
{id-ce-keyUsage, digitalSignature}
SignedData.SignerInfos
SignerInfo
sid.subjectKeyIdentifier = 1000
Message from RA to CA:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{ 102, id-cmc-batchRequests, { 1, 2} }
{ 103, id-cmc-addExtensions,
{ {1, 201, {id-ce-certificatePolicies, anyPolicy}}
{1, 201, {id-ce-subjectAltName, {extension data}}
{2, XXX, {id-ce-subjectAltName, {extension data}}}
The Value XXX is not known here; it would
reference into the second client request,
which is not displayed above.
cmsSequence
{ 1, <Message from client to RA #1> }
{ 2, <Message from client to RA #2> }
SignedData.SignerInfos
SignerInfo
sid = RA key.
Response from CA to RA:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-BatchResponse, {999, 998}}
{103, id-cmc-statusInfoV2, {failed, 2, badIdentity}}
cmsSequence
{ bodyPartID = 999
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
{ bodyPartID = 998,
contentInfo
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {failure, badAlg}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
}
SignedData.SignerInfos
Signed by CA
Response from RA to client:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{102, id-cmc-statusInfoV2, {success, 201}}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
B.3. Direct POP for an RSA Certificate
This section looks at the messages that would flow in the event that
an enrollment is done for an encryption only certificate using an
direct POP method. For simplicity, it is assumed that the
certification requester already has a signing-only certificate.
The fact that a second round-trip is required is implicit rather than
explicit. The server determines this based on the fact that no other
POP exists for the certification request.
Message #1 from client to server:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10001}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
Response #1 from server to client:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-statusInfoV2, {failed, 201, popRequired}}
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 10005}
{104, id-cmc-recipientNonce, 10001}
{105, id-cmc-encryptedPOP, {
request {
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
}
cms
contentType = id-envelopedData
content
recipientInfos.riid.issuerSerialNumber = <NULL, 201>
encryptedContentInfo
eContentType = id-data
eContent = <Encrypted value of 'y'>
thePOPAlgID = HMAC-SHA1
witnessAlgID = SHA-1
witness <hashed value of 'y'>}}
{106, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Other certificates (optional)
SignedData.SignerInfos
Signed by CA
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIData
eContent
controlSequence
{102, id-cmc-transactionId, 10132985123483401}
{103, id-cmc-senderNonce, 100101}
{104, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
{105, id-cmc-recipientNonce, 10005}
{107, id-cmc-decryptedPOP, {
bodyPartID 201,
thePOPAlgID HMAC-SHA1,
thePOP <HMAC computed value goes here>}}
reqSequence
certRequest
certReqId = 201
certTemplate
subject = <My DN from my signing cert>
publicKey = My Public Key
extensions
{id-ce-keyUsage, keyEncipherment}
popo
keyEncipherment
subsequentMessage
SignedData.SignerInfos
SignerInfo
Signed by requester's signing cert
Response #2 from server to client:
ContentInfo.contentType = id-signedData
ContentInfo.content
SignedData.encapContentInfo
eContentType = id-ct-PKIResponse
eContent
controlSequence
{101, id-cmc-transactionId, 10132985123483401}
{102, id-cmc-statusInfoV2, {success, 201}}
{103, id-cmc-senderNonce, 10019}
{104, id-cmc-recipientNonce, 100101}
{105, id-cmc-dataReturn, <packet of binary data identifying
where the key in question is.>}
certificates
Newly issued certificate
Other certificates
SignedData.SignerInfos
Signed by CA
Appendix C. Production of Diffie-Hellman Public Key Certification
Requests
Part of a certification request is a signature over the request;
Diffie-Hellman is a key agreement algorithm and cannot be used to
directly produce the required signature object. [DH-POP] provides
two ways to produce the necessary signature value. This document
also defines a signature algorithm that does not provide a POP value,
but can be used to produce the necessary signature value.
C.1. No-Signature Signature Mechanism
Key management (encryption/decryption) private keys cannot always be
used to produce some type of signature value as they can be in a
decrypt-only device. Certification requests require that the
signature field be populated. This section provides a signature
algorithm specifically for that purposes. The following object
identifier and signature value are used to identify this signature
type:
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
The parameters for id-alg-noSignature MUST be present and MUST be encoded as NULL. NoSignatureValue contains the hash of the certification request. It is important to realize that there is no security associated with this signature type. If this signature type is on a certification request and the Certification Authority policy requires proof-of-possession of the private key, the POP mechanism defined in Section 6.7 MUST be used.Authors' Addresses
Jim Schaad Soaring Hawk Consulting PO Box 675 Gold Bar, WA 98251 Phone: (425) 785-1031 EMail: jimsch@nwlink.com Michael Myers TraceRoute Security, Inc. EMail: mmyers@fastq.com
Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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.