RFC 5272
Certificate Management over CMS (CMC)
Certificate Management over CMS (CMC) 💖
Okay bestie, this is RFC 5272 🎀 It's a Standards Track document from the Network Working Group, published June 2008. The two authors are J. Schaad at Soaring Hawk Consulting and M. Myers at TraceRoute Security, Inc. It obsoletes RFC 2797, which means this one replaces it. It doesn't update anything else. 🦋
Status of This Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. 💅
Abstract
okay so the abstract is basically the pitch 🧚 This document defines the base syntax for CMC, a Certificate Management protocol that uses the Cryptographic Message Syntax (CMS). It's solving two urgent problems in the Internet Public Key Infrastructure (PKI) community:
- The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and
- The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
ngl, CMC also needs the transport document and the requirements usage document alongside this one to be fully defined 📚
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Protocol Requirements . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Terminology . . . . . . . . . . . . . . . . . 5
1.3. Changes since RFC 2797 . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Protocol Requests/Responses . . . . . . . . . . . . . . . 9
3. PKI Requests . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Simple PKI Request . . . . . . . . . . . . . . . . . . . . 10
3.2. Full PKI Request . . . . . . . . . . . . . . . . . . . . . 12
3.2.1. PKIData Content Type . . . . . . . . . . . . . . . . . 13
3.2.1.1. Control Syntax . . . . . . . . . . . . . . . . . . 14
3.2.1.2. Certification Request Formats . . . . . . . . . . 15
3.2.1.2.1. PKCS #10 Certification Syntax . . . . . . . . 16
3.2.1.2.2. CRMF Certification Syntax . . . . . . . . . . 17
3.2.1.2.3. Other Certification Request . . . . . . . . . 18
3.2.1.3. Content Info Objects . . . . . . . . . . . . . . . 19
3.2.1.3.1. Authenticated Data . . . . . . . . . . . . . . 19
3.2.1.3.2. Data . . . . . . . . . . . . . . . . . . . . . 20
3.2.1.3.3. Enveloped Data . . . . . . . . . . . . . . . . 20
3.2.1.3.4. Signed Data . . . . . . . . . . . . . . . . . 20
3.2.1.4. Other Message Bodies . . . . . . . . . . . . . . . 21
3.2.2. Body Part Identification . . . . . . . . . . . . . . . 21
3.2.3. CMC Unsigned Data Attribute . . . . . . . . . . . . . 22
4. PKI Responses . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1. Simple PKI Response . . . . . . . . . . . . . . . . . . . 23
4.2. Full PKI Response . . . . . . . . . . . . . . . . . . . . 24
4.2.1. PKIResponse Content Type . . . . . . . . . . . . . . . 24
5. Application of Encryption to a PKI Request/Response . . . . . 25
6. Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1. CMC Status Info Controls . . . . . . . . . . . . . . . . . 28
6.1.1. Extended CMC Status Info Control . . . . . . . . . . . 28
6.1.2. CMC Status Info Control . . . . . . . . . . . . . . . 30
6.1.3. CMCStatus Values . . . . . . . . . . . . . . . . . . . 31
6.1.4. CMCFailInfo . . . . . . . . . . . . . . . . . . . . . 32
6.2. Identification and Identity Proof Controls . . . . . . . . 33
6.2.1. Identity Proof Version 2 Control . . . . . . . . . . . 33
6.2.2. Identity Proof Control . . . . . . . . . . . . . . . . 35
6.2.3. Identification Control . . . . . . . . . . . . . . . . 35
6.2.4. Hardware Shared-Secret Token Generation . . . . . . . 36
6.3. Linking Identity and POP Information . . . . . . . . . . . 36
6.3.1. Cryptographic Linkage . . . . . . . . . . . . . . . . 37
6.3.1.1. POP Link Witness Version 2 Controls . . . . . . . 37
6.3.1.2. POP Link Witness Control . . . . . . . . . . . . . 38
6.3.1.3. POP Link Random Control . . . . . . . . . . . . . 38
6.3.2. Shared-Secret/Subject DN Linking . . . . . . . . . . . 39
6.3.3. Renewal and Rekey Messages . . . . . . . . . . . . . . 39
6.4. Data Return Control . . . . . . . . . . . . . . . . . . . 40
6.5. RA Certificate Modification Controls . . . . . . . . . . . 40
6.5.1. Modify Certification Request Control . . . . . . . . . 41
6.5.2. Add Extensions Control . . . . . . . . . . . . . . . . 42
6.6. Transaction Identifier Control and Sender and
Recipient Nonce Controls . . . . . . . . . . . . . . . . . 44
6.7. Encrypted and Decrypted POP Controls . . . . . . . . . . . 45
6.8. RA POP Witness Control . . . . . . . . . . . . . . . . . . 48
6.9. Get Certificate Control . . . . . . . . . . . . . . . . . 49
6.10. Get CRL Control . . . . . . . . . . . . . . . . . . . . . 49
6.11. Revocation Request Control . . . . . . . . . . . . . . . . 50
6.12. Registration and Response Information Controls . . . . . . 52
6.13. Query Pending Control . . . . . . . . . . . . . . . . . . 53
6.14. Confirm Certificate Acceptance Control . . . . . . . . . . 53
6.15. Publish Trust Anchors Control . . . . . . . . . . . . . . 54
6.16. Authenticated Data Control . . . . . . . . . . . . . . . . 55
6.17. Batch Request and Response Controls . . . . . . . . . . . 56
6.18. Publication Information Control . . . . . . . . . . . . . 57
6.19. Control Processed Control . . . . . . . . . . . . . . . . 58
7. Registration Authorities . . . . . . . . . . . . . . . . . . . 59
7.1. Encryption Removal . . . . . . . . . . . . . . . . . . . . 60
7.2. Signature Layer Removal . . . . . . . . . . . . . . . . . 61
8. Security Considerations . . . . . . . . . . . . . . . . . . . 61
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 63
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63
11.1. Normative References . . . . . . . . . . . . . . . . . . . 63
11.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 65
Appendix B. Enrollment Message Flows . . . . . . . . . . . . . . 74
B.1. Request of a Signing Certificate . . . . . . . . . . . . . 74
B.2. Single Certification Request, But Modified by RA . . . . . 75
B.3. Direct POP for an RSA Certificate . . . . . . . . . . . . 78
Appendix C. Production of Diffie-Hellman Public Key
Certification Requests . . . . . . . . . . . . . . . 81
C.1. No-Signature Signature Mechanism . . . . . . . . . . . . . 811. Introduction ✨
This is the core of the whole thing, so let's go 💅 The document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). It tackles two immediate needs in the Internet PKI community:
- The need for an interface to public key certification products and services based on CMS and PKCS #10, and
- The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design.
A small number of additional services are defined to supplement the core certification request service. 🌸
1.1. Protocol Requirements
Here's the wishlist 🧚 The protocol must be based as much as possible on the existing CMS, PKCS #10 [PKCS10] and CRMF (Certificate Request Message Format) [CRMF] specifications.
The protocol must support the current industry practice of a PKCS #10 certification request followed by a PKCS#7 "certs-only" response as a subset of the protocol.
The protocol must easily support the multi-key enrollment protocols required by S/MIME and other groups.
The protocol must supply a way of doing all enrollment operations in a single round-trip. When this is not possible the number of round-trips is to be minimized.
The protocol must be designed such that all key generation can occur on the client.
Support must exist for the mandatory algorithms used by S/MIME. Support should exist for all other algorithms cited by the S/MIME core documents. 🔥
The protocol must contain Proof-of-Possession (POP) methods. Optional provisions for multiple-round-trip POP will be made if necessary.
The protocol must support deferred and pending responses to enrollment requests for cases where external procedures are required to issue a certificate. ⏳
The protocol must support arbitrary chains of Registration Authorities (RAs) as intermediaries between certification requesters and Certification Authorities (CAs). 👑
1.2. Requirements Terminology
Here's the key-word situation 🙈 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.3. Changes since RFC 2797
Okay, this is the glow-up section 💖 They did a major overhaul on the layout, and it happened in two steps. First, they removed some sections and moved them into two other documents. Info on how to transport the messages now lives in [CMC-TRANS]. Info on which controls and sections of this document must be implemented, along with which algorithms are required, now lives in [CMC-COMPL].
A bunch of new controls were added in this version, bestie:
- Extended CMC Status Info Section 6.1.1
- Publish Trust Anchors Section 6.15
- Authenticate Data Section 6.16
- Batch Request and Response Processing Section 6.17
- Publication Information Section 6.18
- Modify Certification Request Section 6.5.1
- Control Processed Section 6.19
- Identity Proof Section 6.2.2
- Identity POP Link Witness V2 Section 6.3.1.1
That's the whole first chunk, we're just getting started! 🌈
2. Protocol Overview ✨
okay so bestie, a PKI enrollment transaction in this spec is usually just one round-trip of messages 💖 The simplest version goes like this: a PKI enrollment request (we call it a PKI Request) goes from the client to the server, and then a PKI enrollment response (a PKI Response) comes back to the client. 🦋 It only gets more complicated in cases like delayed certificate issuance, where you need more than one round-trip.
This spec defines two PKI Request types and two PKI Response types 🎀
PKI Requests are built with either the PKCS #10 or CRMF structure. The two PKI Requests are:
- Simple PKI Request: just the bare PKCS #10 (when no other services are needed) 🌸
- Full PKI Request: one or more PKCS #10, CRMF or Other Request Messages structures wrapped in a CMS encapsulation as part of a PKIData 🧚
PKI Responses are based on SignedData or AuthenticatedData [CMS]. The two PKI Responses are:
- Simple PKI Response: a "certs-only" SignedData (when no other services are needed) 💅
- Full PKI Response: a PKIResponse content type wrapped in a SignedData 👑
No special services are provided for renewal (a new certificate with the same key) or rekey (a new certificate with a new key) of client certificates. 🙈 Instead, renewal and rekey requests look the same as any certification request, except the identity proof comes from existing certificates from a trusted CA. (This is usually the same CA, but it could be a different CA in the same organization where naming is shared.)
No special services are provided to tell a rekey request apart from a new certification request (usually for a new purpose). A control to unpublish a certificate would normally be included in a rekey request and left out of a new certification request 🍓 CAs or other publishing agents are also expected to have policies for removing certificates from publication, either based on new certificates being added or on the expiration or revocation of a certificate.
There's a provision for RAs to join the protocol too 🫶 An RA takes PKI Requests, wraps them in a second layer of PKI Request with extra requirements or statements from the RA, and then passes this new expanded PKI Request on to the CA.
This spec makes no assumptions about the underlying transport mechanism. Using CMS does not mean email transport. Several possible transport methods are defined in [CMC-TRANS] 📬
The optional services available through this spec are: transaction management, replay detection (through nonces), deferred certificate issuance, certificate revocation requests, and certificate/certificate revocation list (CRL) retrieval. ✨
2.1. Terminology
There are a bunch of terms, abbreviations, and acronyms used in this document 📚 They're defined here, in no particular order, so everyone uses them the same way:
End-Entity (EE) refers to the entity that owns a key pair and for whom a certificate is issued. 🌈
Registration Authority (RA) or Local RA (LRA) refers to an entity that acts as an intermediary between the EE and the CA. Multiple RAs can exist between the end-entity and the Certification Authority. RAs may perform extra services like key generation or key archival. This document uses the term RA for both RA and LRA. 🦋
Certification Authority (CA) refers to the entity that issues certificates. 👑
Client refers to an entity that creates a PKI Request. In this document, both RAs and EEs can be clients. 💖
Server refers to the entities that process PKI Requests and create PKI Responses. In this document, both CAs and RAs can be servers. 🔥
PKCS #10 refers to the Public Key Cryptography Standard #10 [PKCS10], which defines a certification request syntax. 🎀
CRMF refers to the Certificate Request Message Format RFC [CRMF]. CMC uses the certification request syntax defined in this document as part of the protocol. 🌸
CMS refers to the Cryptographic Message Syntax RFC [CMS]. This document provides for basic cryptographic services, including encryption and signing, with and without key management. 🧚
PKI Request/Response refers to the requests/responses described in this document. PKI Requests include certification requests, revocation requests, etc. PKI Responses include certs-only messages, failure messages, etc. 💅
Proof-of-Identity refers to the client proving they are who they say they are to the server. 🫶
Enrollment or certification request refers to the process of a client requesting a certificate. A certification request is a subset of the PKI Requests. 🍓
Proof-of-Possession (POP) refers to a value that can be used to prove that the private key corresponding to a public key is in the possession of, and can be used by, an end-entity. 🔐 The different types of POP are:
- Signature provides the required POP by a signature operation over some data. ✍️
- Direct provides the required POP operation by an encrypted challenge/response mechanism. 🌙
- Indirect provides the required POP operation by returning the issued certificate in an encrypted state. (This method is not used by CMC.) 🙈
- Publish provides the required POP operation by providing the private key to the certificate issuer. (This method is not currently used by CMC. It would be used by Key Generation or Key Escrow extensions.) 😭
- Attested provides the required POP operation by allowing a trusted entity to assert that the POP has been proven by one of the above methods. 👑
Object IDentifier (OID) is a primitive type in Abstract Syntax Notation One (ASN.1). 🌈
2.2. Protocol Requests/Responses
Figure 1 shows the Simple PKI Requests and Responses 🦋 The contents of the Simple PKI Request and Response are detailed in Sections 3.1 and 4.1.
Simple PKI Request Simple PKI Response
------------------------- --------------------------
+----------+ +------------------+
| PKCS #10 | | CMS ContentInfo |
+----------+--------------+ +------------------+------+
| Certification Request | | CMS Signed Data, |
| | | no SignerInfo |
| Subject Name | |
| Subject Public Key Info | | SignedData contains one |
| (K_PUB) | | or more certificates in |
| Attributes | | the certificates field |
| | | Relevant CA certs and |
+-----------+-------------+ | CRLs can be included |
| signed with | | as well. |
| matching | | |
| K_PRIV | | encapsulatedContentInfo |
+-------------+ | is absent. |
+--------------+----------+
| unsigned |
+----------+
Figure 1: Simple PKI Requests and ResponsesFigure 2 shows the Full PKI Requests and Responses 💜 The contents of the Full PKI Request and Response are detailed in Sections 3.2 and 4.2.
Full PKI Request Full PKI Response
----------------------- ------------------------
+----------------+ +----------------+
| CMS ContentInfo| | CMS ContentInfo|
| CMS SignedData | | CMS SignedData |
| or Auth Data | | or Auth Data |
| object | | object |
+----------------+--------+ +----------------+--------+
| | | |
| PKIData | | PKIResponseBody |
| | | |
| Sequence of: | | Sequence of: |
| <enrollment control>* | | <enrollment control>* |
| <certification request>*| | <CMS object>* |
| <CMS object>* | | <other message>* |
| <other message>* | | |
| | | where * == zero or more |
| where * == zero or more | | |
| | | All certificates issued |
| Certification requests | | as part of the response |
| are CRMF, PKCS #10, or | | are included in the |
| Other. | | "certificates" field |
| | | of the SignedData. |
+-------+-----------------+ | Relevant CA certs and |
| signed (keypair | | CRLs can be included as |
| used may be pre-| | well. |
| existing or | | |
| identified in | +---------+---------------+
| the request) | | signed by the |
+-----------------+ | CA or an LRA |
+---------------+
Figure 2: Full PKI Requests and Responses3. PKI Requests 🎀
Two types of PKI Requests exist 💖 This section gives the details for both types.
3.1. Simple PKI Request ✨
okay bestie, the Simple PKI Request is built on the PKCS #10 syntax CertificationRequest [PKCS10] 🎀
When a server processes a Simple PKI Request, the PKI Response it sends back is:
- a Simple PKI Response on success 🦋
- a Full PKI Response on failure 💀. The server MAY choose not to return a PKI Response in this case.
The Simple PKI Request MUST NOT be used if a proof-of-identity needs to be included. so if you need proof-of-identity, you gotta go a different route 🙈
The Simple PKI Request cannot be used if the private key is not capable of producing some type of signature. That is, Diffie-Hellman (DH) keys can use the signature algorithms in [DH-POP] for production of the signature 🔑
The Simple PKI Request cannot be used for any of the advanced services specified in this document. no cap, the fancy stuff is a Full PKI Request situation 💅
The client MAY incorporate one or more X.509v3 extensions in any certification request based on PKCS #10 as an ExtensionReq attribute. The ExtensionReq attribute is defined as:
ExtensionReq ::= SEQUENCE SIZE (1..MAX) OF Extensionwhere Extension is imported from [PKIXCERT] and ExtensionReq is identified by:
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}Here's the important bit! 🌸 Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process other X.509v3 extensions transmitted using this protocol, nor are they required to be able to process private extensions. Servers are not required to put all client-requested extensions into a certificate. Servers are permitted to modify client-requested extensions. Servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, changing key usage from keyAgreement to digitalSignature.) If a certification request is denied due to the inability to handle a requested extension and a PKI Response is returned, the server MUST return a PKI Response with a CMCFailInfo value with the value unsupportedExt. 😭
3.2. Full PKI Request
The Full PKI Request provides the most functionality and flexibility. main character energy 👑
The Full PKI Request is encapsulated in either a SignedData or an AuthenticatedData with an encapsulated content type of id-cct-PKIData (Section 3.2.1).
When a server processes a Full PKI Request, a PKI Response MUST be returned. The PKI Response returned is:
- a Simple PKI Response if the enrollment was successful and only certificates are returned. (A CMCStatusInfoV2 control with success is implied.)
- a Full PKI Response if the enrollment was successful and information is returned in addition to certificates, if the enrollment is pending, or if the enrollment failed.
If SignedData is used, the signature can be generated using either the private key material of an embedded signature certification request (that is, included in the TaggedRequest tcr or crm fields) or a previously certified signature key. If the private key of a signature certification request is used, then:
- a. The certification request containing the corresponding public key MUST include a Subject Key Identifier extension.
- b. The subjectKeyIdentifier form of the signerIdentifier in SignerInfo MUST be used.
- 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 in the SignedData.
If AuthenticatedData is used, then:
- a. The Password Recipient Info option of RecipientInfo MUST be used.
- b. A randomly generated key is used to compute the Message Authentication Code (MAC) value on the encapsulated content.
- c. The input for the key derivation algorithm is a concatenation of the identifier (encoded as UTF8) and the shared-secret.
When creating a PKI Request to renew or rekey a certificate:
- a. The Identification and Identity Proof controls are absent. The same information is provided by the use of an existing certificate from a CA when signing the PKI Request. In this case, the CA that issued the original certificate and the CA the request is made to will usually be the same, but could have a common operator. 🫶
- b. CAs and RAs can impose additional restrictions on the signing certificate used. They may require that the most recently issued signing certificate for a client be used.
- c. Some CAs may prevent renewal operations (that is, reuse of the same keys). In this case the CA MUST return a PKI Response with
noKeyReuseas the CMCFailInfo failure code. 🚫
3.2.1. PKIData Content Type
The PKIData content type is used for the Full PKI Request. A PKIData content type is identified by:
id-cct-PKIData ::= {id-pkix id-cct(12) 2 }The ASN.1 structure corresponding to the PKIData content type is:
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
}The fields in PKIData have the following meaning:
controlSequenceis a sequence of controls. The controls defined in this document are found in Section 6. Controls can be defined by other parties. Details on the TaggedAttribute structure can be found in Section 3.2.1.1.reqSequenceis a sequence of certification requests. The certification requests can be a CertificationRequest (PKCS #10), a CertReqMsg (CRMF), or an externally defined PKI request. Full details are found in Section 3.2.1.2. If an externally defined certification request is present, but the server does not understand the certification request (or will not process it), a CMCStatus ofnoSupportMUST be returned for the certification request item and no other certification requests are processed. 🥺cmsSequenceis a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.otherMsgSequenceis a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This allows for controls to use large amounts of data without the data being embedded in the control. See Section 3.2.1.4 for more details.
All certification requests encoded into a single PKIData SHOULD be for the same identity. RAs that batch process (see Section 6.17) are expected to place the PKI Requests received into the cmsSequence of a PKIData. 🍓
Processing of the PKIData by a recipient is as follows:
- All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing at this time, to ignore the control, or to place the control on a to-do list for later processing. Controls can be processed in any order; the order in the sequence is not significant.
- Items in the reqSequence are not referenced by a control. These items, which are certification requests, also need to be processed. As with controls, the appropriate processing can be either immediate processing or addition to a to-do list for later processing.
- Finally, the to-do list is processed. In many cases, the to-do list will be ordered by grouping specific tasks together.
No processing is required for cmsSequence or otherMsgSequence members of PKIData if they are present and are not referenced by a control. In this case, the cmsSequence and otherMsgSequence members are ignored. 🧚
3.2.1.1. Control Syntax
The actions to be performed for a PKI Request/Response are based on the included controls. Each control consists of an object identifier and a value based on the object identifier.
The syntax of a control is:
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartID,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANYThe fields in TaggedAttribute have the following meaning:
bodyPartIDis a unique integer that identifies this control.attrTypeis the OID that identifies the control.attrValuesis the data values used in processing the control. The structure of the data is dependent on the specific control.
Heads up, this one's serious! 🚨 The final server MUST fail the processing of an entire PKIData if any included control is not recognized, that control is not already marked as processed by a Control Processed control (see Section 6.19) and no other error is generated. The PKI Response MUST include a CMCFailInfo value with the value badRequest and the bodyList MUST contain the bodyPartID of the invalid or unrecognized control(s). A server is the final server if and only if it is not passing the PKI Request on to another server. A server is not considered to be the final server if the server would have passed the PKI Request on, but instead it returned a processing error.
The controls defined by this document are found in Section 6.
3.2.1.2. Certification Request Formats
Certification Requests are based on PKCS #10, CRMF, or Other Request formats. Section 3.2.1.2.1 specifies the requirements for clients and servers dealing with PKCS #10. Section 3.2.1.2.2 specifies the requirements for clients and servers dealing with CRMF. Section 3.2.1.2.3 specifies the requirements for clients and servers dealing with Other Request.
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg,
orm [2] SEQUENCE {
bodyPartID BodyPartID,
requestMessageType OBJECT IDENTIFIER,
requestMessageValue ANY DEFINED BY requestMessageType
}
}The fields in TaggedRequest have the following meaning:
tcris a certification request that uses the PKCS #10 syntax. Details on PKCS #10 are found in Section 3.2.1.2.1.crmis a certification request that uses the CRMF syntax. Details on CRMF are found in Section 3.2.1.2.2.ormis an externally defined certification request. One example is an attribute certification request. The fields of this structure are:bodyPartIDis the identifier number for this certification request. Details on body part identifiers are found in Section 3.2.2.requestMessageTypeidentifies the other request type. These values are defined outside of this document.requestMessageValueis the data associated with the other request type.
3.2.1.2.1. PKCS #10 Certification Syntax 💅
okay so if you're making a certification request based on PKCS #10, it uses this ASN.1 structure 🧚
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}here's what the fields mean 🎀
bodyPartIDis the identifier number for this certification request. The deets on body part identifiers are in Section 3.2.2.certificationRequestholds the PKCS-#10-based certification request. Its fields are described in [PKCS10].
now for the important bit 👑 when you're producing a PKCS #10 request, clients MUST produce the request with a subject name and public key. some PKI products run off a central repository that hands out subject names once a request comes in, so to make that work, the subject field in a CertificationRequest MAY be NULL, but it MUST be present 🫶 CAs that get a CertificationRequest with a NULL subject field MAY reject those requests. if they reject it and a PKI Response gets sent back, the CA MUST return a PKI Response with the CMCFailInfo value of badRequest 💀
3.2.1.2.2. CRMF Certification Syntax 🦋
a CRMF message uses this ASN.1 structure (it's defined in [CRMF], and I've copied it here so you don't have to go hunting) ✨
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
popo ProofOfPossession OPTIONAL,
-- content depends upon key type
regInfo SEQUENCE SIZE(1..MAX) OF AttributeTypeAndValue OPTIONAL }
CertRequest ::= SEQUENCE {
certReqId INTEGER, -- ID for matching request and reply
certTemplate CertTemplate, --Selected fields of cert to be issued
controls Controls OPTIONAL } -- Attributes affecting issuance
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
serialNumber [1] INTEGER OPTIONAL,
signingAlg [2] AlgorithmIdentifier OPTIONAL,
issuer [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
subject [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL,
subjectUID [8] UniqueIdentifier OPTIONAL,
extensions [9] Extensions OPTIONAL }the fields in CertReqMsg are explained in [CRMF] 📚
this document adds some extra rules for building and processing CRMF certification requests 🔥 bestie, read these carefully:
- When a Full PKI Request includes a CRMF certification request, both the subject and publicKey fields in the CertTemplate MUST be defined. The subject field can be encoded as NULL, but MUST be present.
- When both CRMF and CMC controls exist with equivalent functionality, the CMC control SHOULD be used. The CMC control MUST override the CRMF control.
- The regInfo field MUST NOT be used on a CRMF certification request. Equivalent functionality is provided in the CMC regInfo control (Section 6.12).
- The indirect method of proving POP is not supported in this protocol. One of the other methods (including the direct method described in this document) MUST be used. The value of encrCert in SubsequentMessage MUST NOT be used.
- Since the subject and publicKeyValues are always present, the POPOSigningKeyInput MUST NOT be used when computing the value for POPSigningKey.
a server doesn't have to use every value the client suggested in the CRMF certification request, and that's totally fine 🌸 servers MUST be able to process all extensions that are defined but not prohibited in [PKIXCERT]. they don't have to be able to process other X.509v3 extensions sent over this protocol, and they don't have to handle private extensions either 🙈 servers are allowed to modify client-requested extensions, but servers MUST NOT alter an extension so as to invalidate the original intent of a client-requested extension. (For example, change key usage from keyAgreement to digitalSignature.) if a certification request gets denied because the server can't handle a requested extension, the server MUST respond with a Full PKI Response with a CMCFailInfo value of unsupportedExt 😭
3.2.1.2.3. Other Certification Request 🌈
this document lets other certification request formats be defined and used too ✨ one example is a format for Attribute Certificates. these other formats are defined by giving them an OID for identification, plus the structure that holds the data being passed along 🧚
3.2.1.3. Content Info Objects 🎀
the cmsSequence field of the PKIData and PKIResponse messages holds zero or more tagged content info objects. the syntax for this structure is:
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartID,
contentInfo ContentInfo
}here's what the fields mean 💖
bodyPartIDis a unique integer that identifies this content info object.contentInfois a ContentInfo object (defined in [CMS]).
the four content types used in cmsSequence are AuthenticatedData, Data, EnvelopedData, and SignedData. all of them are defined in [CMS] 🍓
3.2.1.3.1. Authenticated Data 🔐
the AuthenticatedData content type gives you a way to validate data sent between two parties using a pre-shared secret 🤫 unlike SignedData, it doesn't say which party actually generated the information.
AuthenticatedData gives you origin authentication in situations where a shared secret exists but PKI-based trust hasn't been set up yet. PKI-based trust might not exist because a trust anchor was never installed on the client, or because there's no certificate for a signing key 🫠
this document uses the AuthenticatedData content type for:
- The id-cmc-authData control (Section 6.16), and
- The top-level wrapper in environments where an encryption-only key is being certified.
this content type can include both PKIData and PKIResponse as the encapsulated content types. those embedded content types can carry extra controls that need processing 🧩
3.2.1.3.2. Data 📦
the Data content type is for general transport of unstructured data 💜
this document uses the Data content type for:
- Holding the encrypted random value y for POP proof in the encrypted POP control (see Section 6.7).
3.2.1.3.3. Enveloped Data 🔒
the EnvelopedData content type is for shrouding data, aka hiding it 🙈 it's the main confidentiality method for sensitive information in this protocol. EnvelopedData can encrypt an entire PKI Request (see Section 5), and it can also wrap private key material for key archival 🗝️ if decryption of an EnvelopedData fails, a Full PKI Response gets returned with a CMCFailInfo value of badMessageCheck and a bodyPartID of 0.
3.2.1.3.4. Signed Data ✍️
the SignedData content type handles authentication and integrity ✨
this document uses the SignedData content type for:
- The outer wrapper for a PKI Request.
- The outer wrapper for a PKI Response.
when processing a PKI Request/Response, the signature(s) MUST be verified. if the signature doesn't verify and the PKI Request/Response contains anything other than a CMC Status Info control, a Full PKI Response containing a CMC Status Info control MUST be returned using a CMCFailInfo with a value of badMessageCheck and a bodyPartID of 0 😭🚨
for the PKI Response, SignedData lets the server sign the returned data (if there is any) and carry the certificates and CRLs that match the PKI Request. if no data is being returned beyond the certificates and CRLs, the EncapsulatedInfo and SignerInfo fields aren't populated 🦋
3.2.1.4. Other Message Bodies 🎁
the otherMsgSequence field of the PKI Request/Response lets you carry arbitrary data objects as part of a PKI Request/Response 🌷 it's meant for data objects that aren't already wrapped in a cmsSequence field (Section 3.2.1.3). the data object is ignored unless a control references it by bodyPartID.
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }here's what the fields mean 🧚
bodyPartIDis the unique id that identifies this data object.otherMsgTypeis the OID that defines the type of message body.otherMsgValueis the data.
3.2.2. Body Part Identification 🪪
every element of a PKIData or PKIResponse has an associated body part identifier 💅 it's a 4-octet integer, and the ASN.1 for it looks like this:
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)body part identifiers get encoded in the certReqIds field for CertReqMsg objects (inside a TaggedRequest), or in the bodyPartID field of the other objects. the body part identifier MUST be unique within a single PKIData or PKIResponse. body part identifiers can be duplicated across different layers (for example, a PKIData embedded within another) 🪆
the bodyPartID value of 0 is reserved for referencing the current PKIData object 🫶
some controls, like the Add Extensions control (Section 6.5.2), use the body part identifier in the pkiDataReference field to point at a PKI Request in the current PKIData. some controls, like the Extended CMC Status Info control (Section 6.1.1), also use body part identifiers to point at elements in the previous PKI Request/Response. this makes it super clear which control or PKI Request an error applies to 🔍
a BodyPartList holds a list of body parts in a PKI Request/Response (like the Batch Request control in Section 6.17). the ASN.1 type BodyPartList is defined as:
BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartIDa BodyPartPath holds a path of body part identifiers that moves through nesting (like the Modify Certification Request control in Section 6.5.1). the ASN.1 type BodyPartPath is defined as:
BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID3.2.3. CMC Unsigned Data Attribute ✨
Okay bestie, sometimes you need to stuff data into a PKI Request that is supposed to get yanked out by an RA during processing 🎀. The classic example is an encrypted private key that a Key Archive Agent removes before the request goes on to the CA 🔐. The annoying side effect is that every RA wrapping this stuff has to move the data so it's not covered by that RA's signature. (A client PKI Request wrapped by an RA can't have a signed control pulled out by the Key Archive Agent without breaking the RA's signature 💀.) The CMC Unsigned Data attribute fixes this problem 🦋.
The CMC Unsigned Data attribute holds information that a client did not sign directly. When an RA finds this attribute in the unsigned or unauthenticated attribute field of a request it's aggregating, it pulls the attribute out of the request before the request goes into a cmsSequence. Then it drops the attribute into the unsigned or unauthenticated attributes of the RA's own signed or authenticated data wrapper 🌸.
The CMC Unsigned Data attribute is identified by:
id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}The CMC Unsigned Data attribute has this ASN.1 definition:
CMCUnsignedData ::= SEQUENCE {
bodyPartPath BodyPartPath,
identifier OBJECT IDENTIFIER,
content ANY DEFINED BY identifier
}Here's what the fields in CMCUnsignedData mean 🧚:
bodyPartPathis the path pointing to the control associated with this data. When an RA moves the control in an unsigned or unauthenticated attribute up one level as part of wrapping the data in a new SignedData or AuthenticatedData, the body part identifier of the embedded item in the PKIData gets prepended to the bodyPartPath sequence.identifieris the OID that defines the associated data.contentis the data.
There MUST be at most one CMC Unsigned Data attribute in the UnsignedAttribute sequence of a SignerInfo or in the UnauthenticatedAttribute sequence of an AuthenticatedData. UnsignedAttribute is a set of values, and the attribute can have any number of values greater than zero in that set 👑. If the CMC Unsigned Data attribute shows up in one SignerInfo or AuthenticatedData, it MUST appear with the same value(s) in all SignerInfo and AuthenticatedData items 🫶.
4. PKI Responses 💌
There are two types of PKI Responses, and this section gives you the details on both 💖.
4.1. Simple PKI Response
Clients MUST be able to process the Simple PKI Response 🧁. The Simple PKI Response is a SignedData with no EncapsulatedContentInfo and no SignerInfo. The certificates requested in the PKI Response come back in the certificate field of the SignedData 📜.
Clients MUST NOT assume the certificates are in any order 🙈. Servers SHOULD include all intermediate certificates needed to build complete certification paths to one or more trust anchors, not just the newly issued certificate(s) 🌈. The server MAY additionally return CRLs in the CRL bag. Servers MAY include self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) just because they're sitting in the certificate bag 🚫. If clients get a new self-signed certificate from the server, clients SHOULD provide a mechanism so the user can use that certificate as a trust anchor ✨. (The Publish Trust Anchors control (Section 6.15) should be used if the server intends for the client to accept one or more certificates as trust anchors. This requires the use of the Full PKI Response message 🎀.)
4.2. Full PKI Response
Clients MUST be able to process a Full PKI Response 🔥.
The Full PKI Response is a SignedData or AuthenticatedData encapsulating a PKIResponse content type. The certificates issued in a PKI Response come back in the certificates field of the immediately encapsulating SignedData 💅.
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 trust anchors, not just the newly issued certificate(s) 🌷. The server MAY additionally return CRLs in the CRL bag. Servers MAY include self-signed certificates. Clients MUST NOT implicitly trust included self-signed certificate(s) merely because they're in the certificate bag 🛑. If clients receive a new self-signed certificate from the server, clients MAY provide a mechanism that lets the user explicitly use the certificate as a trust anchor 🦋. (The Publish Trust Anchors control (Section 6.15) exists to allow distribution of trust anchor certificates. If a trusted anchor publishes a new trusted anchor, this is one case where automated trust of the new trust anchor could be allowed 🌟.)
4.2.1. PKIResponse Content Type
The PKIResponse content type is used for the Full PKI Response. It's identified by:
id-cct-PKIResponse ::= {id-pkix id-cct(12) 3 }The ASN.1 structure for the PKIResponse content type looks like this:
PKIResponse ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
ReponseBody ::= PKIResponseNote: In [RFC2797], this ASN.1 type was named ResponseBody. It was renamed to PKIResponse for clarity, and the old name was kept as a synonym 🧠.
Here's what the fields in PKIResponse mean 🍓:
controlSequenceis a sequence of controls. The controls defined in this document are in Section 6. Other parties can define controls too. Details on the TaggedAttribute structure are in Section 3.2.1.1.cmsSequenceis a sequence of [CMS] message objects. See Section 3.2.1.3 for more details.otherMsgSequenceis a sequence of arbitrary data objects. Data objects placed here are referred to by one or more controls. This lets controls use large amounts of data without the data being embedded in the control 🧺. See Section 3.2.1.4 for more details.
Here's how a recipient processes a PKIResponse 💁:
- All controls should be examined and processed in an appropriate manner. The appropriate processing is to complete processing right now, to ignore the control, or to put the control on a to-do list for later processing.
- Extra processing of non-element items includes saving the certificates and CRLs present in wrapping layers. This kind of processing depends on the consumer of the element and should not be relied on by generators 🫧.
No processing is required for cmsSequence or otherMsgSequence members of the PKIResponse if the items are present but aren't referenced by a control. In that case, the cmsSequence and otherMsgSequence members are to be ignored 😌.
5. Application of Encryption to a PKI Request/Response 🔒
Sometimes a PKI Request or Response has to be encrypted so that the information in it can't be read by unauthorized entities 🕵️♀️. This section describes how to encrypt Full PKI Requests and Responses (Simple PKI Requests can't be encrypted 🙅♀️). Data portions of PKI Requests and Responses that are placed in the cmsSequence field can be encrypted separately 💜.
Confidentiality comes from wrapping the PKI Request/Response (a SignedData) in an EnvelopedData. The nested content type inside the EnvelopedData is id-SignedData. Note that this is different from S/MIME, where a MIME layer sits between the encrypted and signed data 🙃. It is recommended that if an EnvelopedData layer is applied to a PKI Request/Response, a second signature layer be placed outside of the EnvelopedData layer. Here's the figure showing how this nesting works 🖼️:
Normal Option 1 Option 2
------ -------- --------
SignedData EnvelopedData SignedData
PKIData SignedData EnvelopedData
PKIData SignedData
PKIDataNote: PKIResponse can be substituted for PKIData in the above figure.
Options 1 and 2 stop sensitive data from leaking by encrypting the full PKI Request/Response 🤫. An RA that receives a PKI Request it can't decrypt MAY reject the PKI Request, unless it can process the PKI Request without knowing the contents (for example, if all it does is combine multiple PKI Requests and forward them to a server) 🧩.
After the RA removes the envelope and finishes processing, it can then apply a new EnvelopedData layer to protect PKI Requests on their way to the next processing agent. Section 7 has more info about RA processing 📬.
Full PKI Requests/Responses can be encrypted or sent in the clear. Servers MUST provide support for all three options 🎉.
Alternatively, an authenticated, secure channel can exist between the parties that need confidentiality. Clients and servers MAY use such channels instead of the technique described above to provide secure, private communication of Simple and Full PKI Requests/Responses 🌙.
6. Controls ✨
Okay bestie, controls ride along inside both Full PKI Requests and Responses 💌 Each control is a unique OID followed by the data for that control (see syntax in Section 3.2.1.1. The encoding of the data depends on which control it is. Processing systems first spot the OID (TaggedAttribute attrType) and process the matching control value (TaggedAttribute attrValues) before they touch the message body. Order matters here, sis 🫶
All the OIDs live under this arc:
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 }Here's the table of names, OIDs, and syntactic structures for every control described in this document 📋
Identifier Description OID ASN.1 Structure Section
--------------------------------------------------------------------
id-cmc-statusInfo id-cmc 1 CMCStatusInfo 6.1.2
id-cmc-identification id-cmc 2 UTF8String 6.2.3
id-cmc-identityProof id-cmc 3 OCTET STRING 6.2.2
id-cmc-dataReturn id-cmc 4 OCTET STRING 6.4
id-cmc-transactionId id-cmc 5 INTEGER 6.6
id-cmc-senderNonce id-cmc 6 OCTET STRING 6.6
id-cmc-recipientNonce id-cmc 7 OCTET STRING 6.6
id-cmc-addExtensions id-cmc 8 AddExtensions 6.5.2
id-cmc-encryptedPOP id-cmc 9 EncryptedPOP 6.7
id-cmc-decryptedPOP id-cmc 10 DecryptedPOP 6.7
id-cmc-lraPOPWitness id-cmc 11 LraPOPWitness 6.8
id-cmc-getCert id-cmc 15 GetCert 6.9
id-cmc-getCRL id-cmc 16 GetCRL 6.10
id-cmc-revokeRequest id-cmc 17 RevokeRequest 6.11
id-cmc-regInfo id-cmc 18 OCTET STRING 6.12
id-cmc-responseInfo id-cmc 19 OCTET STRING 6.12
id-cmc-queryPending id-cmc 21 OCTET STRING 6.13
id-cmc-popLinkRandom id-cmc 22 OCTET STRING 6.3.1
id-cmc-popLinkWitness id-cmc 23 OCTET STRING 6.3.1
id-cmc-popLinkWitnessV2 id-cmc 33 OCTET STRING 6.3.1.1
id-cmc-confirmCertAcceptance id-cmc 24 CMCCertId 6.14
id-cmc-statusInfoV2 id-cmc 25 CMCStatusInfoV2 6.1.1
id-cmc-trustedAnchors id-cmc 26 PublishTrustAnchors 6.15
id-cmc-authData id-cmc 27 AuthPublish 6.16
id-cmc-batchRequests id-cmc 28 BodyPartList 6.17
id-cmc-batchResponses id-cmc 29 BodyPartList 6.17
id-cmc-publishCert id-cmc 30 CMCPublicationInfo 6.18
id-cmc-modCertTemplate id-cmc 31 ModCertTemplate 6.5.1
id-cmc-controlProcessed id-cmc 32 ControlsProcessed 6.19
id-cmc-identityProofV2 id-cmc 34 IdentityProofV2 6.2.1Table 1: CMC Control Attributes
6.1. CMC Status Info Controls
These controls tell you how a client/server request/response is doing, status-wise 🚦 There are two of them in this section. The Extended CMC Status Info control is the preferred one, and the CMC Status Info control is only hanging around for backwards compatibility with RFC 2797 🥹
Servers MAY emit multiple CMC status info controls that refer to a single body part. Clients MUST be able to deal with multiple CMC status info controls in a PKI Response. Servers MUST use the Extended CMC Status Info control, but MAY additionally use the CMC Status Info control. Clients MUST be able to process the Extended CMC Status Info control.
6.1.1. Extended CMC Status Info Control
The Extended CMC Status Info control is identified by this OID:
id-cmc-statusInfoV2 ::= { id-cmc 25 }It has the following ASN.1 definition, and yes it's giving main character energy 👑
CMCStatusInfoV2 ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference,
statusString UTF8String OPTIONAL,
otherInfo OtherStatusInfo OPTIONAL
}
OtherStatusInfo ::= CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo,
extendedFailInfo ExtendedFailInfo
}
PendInfo ::= SEQUENCE {
pendToken OCTET STRING,
pendTime GeneralizedTime
}
ExtendedFailInfo ::= SEQUENCE {
failInfoOID OBJECT IDENTIFIER,
failInfoValue ANY DEFINED BY failInfoOID
}
BodyPartReference ::= CHOICE {
bodyPartID BodyPartID,
bodyPartPath BodyPartPath
}Here's what each field in CMCStatusInfoV2 means 🧠
cMCStatuscontains the returned status value. The details are in Section 6.1.3.bodyListidentifies the controls or other elements the status value applies to. If an error is returned for a Simple PKI Request, this field is the bodyPartID choice of BodyPartReference with the single integer of value 1.statusStringcontains additional description information. This string is human readable.otherInfocontains additional information that expands on the CMC status code returned in the cMCStatus field.
And here's what the fields in OtherStatusInfo mean 🔍
failInfois described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus contains the value failed.pendInfocontains information about when and how the client should request the result of this request. It is present when the cMCStatus is either pending or partial. pendInfo uses the structure PendInfo, which has these fields:pendTokenis the token used in the Query Pending control (Section 6.13).pendTimecontains the suggested time the server wants to be queried about the status of the certification request.
extendedFailInfoincludes application-dependent detailed error information. This choice is present only if cMCStatus contains the value failed. Caution should be used when defining new values, as they may not be correctly recognized by all clients and servers. The CMCFailInfo value of internalCAError may be assumed if the extended error is not recognized. This field uses the type ExtendedFailInfo, which has these fields:failInfoOIDcontains an OID that is associated with a set of extended error values.failInfoValuecontains an extended error code from the defined set of extended error codes.
If the cMCStatus field is success, the Extended CMC Status Info control MAY be omitted unless it is the only item in the response.
6.1.2. CMC Status Info Control
The CMC Status Info control is identified by this OID:
id-cmc-statusInfo ::= { id-cmc 1 }Its ASN.1 definition is:
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList BodyPartList,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}Here's what the fields in CMCStatusInfo mean 🎀
cMCStatuscontains the returned status value. The details are in Section 6.1.3.bodyListcontains the list of controls or other elements the status value applies to. If an error is being returned for a Simple PKI Request, this field contains a single integer of value 1.statusStringcontains additional description information. This string is human readable.otherInfoprovides additional information that expands on the CMC status code returned in the cMCStatus field.failInfois described in Section 6.1.4. It provides an error code that details what failure occurred. This choice is present only if cMCStatus is failed.pendInfouses the PendInfo ASN.1 structure in Section 6.1.1. It contains information about when and how the client should request results of this request. The pendInfo field MUST be populated for a cMCStatus value of pending or partial. Further details can be found in Section 6.1.1 (Extended CMC Status Info Control) and Section 6.13 (Query Pending Control ).
If the cMCStatus field is success, the CMC Status Info control MAY be omitted unless it is the only item in the response. If no status exists for a Simple or Full PKI Request, then the value of success is assumed 🌈
6.1.3. CMCStatus Values ✨
okay so CMCStatus is a field that lives inside the Extended CMC Status Info and CMC Status Info controls 💅 it's basically a little code that tells you whether a specific operation worked or didn't. the ASN.1 structure looks like this:
CMCStatus ::= INTEGER {
success (0),
-- reserved (1),
failed (2),
pending (3),
noSupport (4),
confirmRequired (5),
popRequired (6),
partial (7)
}here's what each value means 🫶
successmeans the request was granted or the action was completed. yay 🎀failedmeans the request was not granted or the action was not completed. More information is included elsewhere in the response, so go look there 🙈pendingmeans the PKI Request hasn't been processed yet. The requester is responsible for polling back on this Full PKI request.pendingmay only be returned for certification request operations.noSupportmeans the requested operation is not supported 💀confirmRequiredmeans a Confirm Certificate Acceptance control (Section 6.14) must be returned before the certificate can be used.popRequiredmeans a direct POP operation is required (Section 6.3.1.3) 🔥partialmeans a partial PKI Response is returned. The requester is responsible for polling back for the unfulfilled portions of the Full PKI Request 🧚
6.1.4. CMCFailInfo 🦋
CMCFailInfo is another field in the Extended CMC Status Info and CMC Status Info controls, and it's the one that gives you the why behind a failure 👑 it conveys more detailed information relevant to interpreting a failure condition. The ASN.1 structure is:
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)
}and the meanings, bestie 🌸
badAlgmeans an algorithm is unrecognized or unsupported.badMessageCheckmeans the integrity check failed.badRequestmeans the transaction was not permitted or supported.badTimemeans the message time field wasn't close enough to the system time ⏰badCertIdmeans no certificate could be identified that matches the provided criteria.unsupportedExtmeans a requested X.509 extension isn't supported by the recipient CA.mustArchiveKeysmeans private key material must be supplied 🔐badIdentitymeans the identification control failed to verify.popRequiredmeans the server requires a POP proof before it issues the certificate.popFailedmeans POP processing failed 😭noKeyReusemeans server policy doesn't allow key reuse.internalCAErrormeans the CA ran into an unknown internal failure.tryLatermeans the server isn't accepting requests right now, so the client should try again at a later time ⏳authDataFailmeans a failure happened while processing authenticated data.
If you need more failure reasons than that, they SHOULD use the ExtendedFailureInfo item in the Extended CMC Status Info control. For closed environments, they can be defined using this type instead. Those codes MUST be in the range from 1000 to 1999 🧚
6.2. Identification and Identity Proof Controls 🎀
Some CAs and RAs want a proof-of-identity included in a certification request. There are lots of ways to do this, with different levels of security and reliability. Most of us already know the bank version, where they ask for your mother's maiden name 🙈 the reasoning behind requiring a proof-of-identity is covered in Appendix C of [CRMF].
CMC gives you a way to prove the client's identity using a shared secret between the client and the server. If clients support the Full PKI Request, clients MUST implement this method of identity proof (Section 6.2.2). Servers MUST provide this method, but they MAY also support bilateral methods of similar strength ✨
This document also includes an Identification control (Section 6.2.3). It's a simple way for a client to say who they are to the server 💖 Generally, a shared-secret AND an identifier of that shared-secret are passed from the server to the client. The identifier goes in the Identification control, and the shared-secret is used to compute the Identity Proof control.
6.2.1. Identity Proof Version 2 Control 🦋
The Identity Proof Version 2 control is identified by this OID:
id-cmc-identityProofV2 ::= { id-cmc 34 }and it has this ASN.1 definition:
IdentifyProofV2 ::= SEQUENCE {
hashAlgID AlgorithmIdentifier,
macAlgID AlgorithmIdentifier,
witness OCTET STRING
}the fields work like this:
hashAlgIDis the identifier and parameters for the hash algorithm used to convert the shared secret into a key for the MAC algorithm.macAlgIDis the identifier and parameters for the message authentication code algorithm used to compute the value of thewitnessfield.witnessis the identity proof itself 🔥
The required method starts with an out-of-band transfer of a token, which is the shared secret. The shared secret SHOULD be generated in a random manner. How this token gets distributed is beyond the scope of this document, so that's a separate story 🌈 The client then uses this token for an identity proof like so:
- The PKIData
reqSequencefield (encoded exactly as it appears in the Full PKI Request, including the sequence type and length) is the value to be validated. - Compute a hash of the shared secret as a UTF8 string, using
hashAlgID. - Compute a MAC using the value from Step 1 as the message and the value from Step 2 as the key.
- Encode the result from Step 3 as the
witnessvalue in the Identity Proof Version 2 control.
When the server verifies the Identity Proof Version 2 control, it computes the MAC value the same way and compares it to the witness value in the PKI Request 👀
If a server fails the verification of an Identity Proof Version 2 control, the CMCFailInfo value MUST be present in the Full PKI Response and MUST have a value of badIdentity.
Reusing the shared secret on certification request retries lets the client and server keep the same view of acceptable identity proof values. But reusing the shared secret can potentially open the door to some types of attacks, so be careful, bestie 💀
Implementations MUST be able to support tokens at least 16 characters long. For guidance on how much entropy you actually get from a token of a given length and character set, check Appendix A of [PASSWORD] 🔐
6.2.2. Identity Proof Control ✨
The Identity Proof control is identified by this OID:
id-cmc-identityProof ::= { id-cmc 3 }and its ASN.1 definition is:
IdentifyProof ::= OCTET STRINGThis control gets processed the same way as the Identity Proof Version 2 control. The only difference is that the hash algorithm is fixed to SHA-1 and the MAC algorithm is fixed to HMAC-SHA1 🫶
6.2.3. Identification Control 🌸
Optionally, servers MAY require the inclusion of the unprotected Identification control along with an Identity Proof control. The Identification control is meant to hold a text string that helps the server find the shared secret it needs to validate the contents of the Identity Proof control 🧚 If the Identification control is included in the Full PKI Request, the key derivation in Step 2 (from Section 6.2.1) changes. Instead of hashing just the shared secret, you hash the concatenation of the shared secret and the UTF8 identity value (without the type and length bytes).
The Identification control is identified by this OID:
id-cmc-identification ::= { id-cmc 2 }and it has this ASN.1 definition:
Identification ::= UTF8String6.2.4. Hardware Shared-Secret Token Generation 🔥
Sometimes the shared secret between the EE and the server is computed by a hardware device that generates a series of tokens 🧚 That means the EE can prove its identity by sending this token in plain text along with a name string. The protocol above can be used with a hardware shared-secret token generation device if you make the following changes:
- The Identification control MUST be included, and it MUST contain the hardware-generated token.
- The shared-secret value used above is the same hardware-generated token.
- All certification requests MUST have a subject name, and the subject name MUST contain the fields required to identify the holder of the hardware token device.
- The entire certification request MUST be shrouded in some fashion to prevent eavesdropping. Even though the token is time critical, an active eavesdropper cannot be allowed to extract the token and submit a different certification request with the same token value 😭
6.3. Linking Identity and POP Information 💅
In a Full PKI Request, identity information about the client is carried in the signature of the SignedData that contains all of the certification requests. Proof-of-possession information for key pairs, however, is carried separately for each PKCS #10 or CRMF certification request. (For keys that can generate a digital signature, the POP is provided by the signature on the PKCS #10 or CRMF request. For encryption-only keys, the controls described in Section 6.7 are used.) To prevent substitution-style attacks, the protocol must guarantee that the same entity generated both the POP and the proof-of-identity information 👑
This section describes two ways to link identity and POP information: witness values cryptographically derived from the shared secret (Section 6.3.1.3), and shared-secret/subject distinguished name (DN) matching (Section 6.3.2). Clients and servers MUST support the witness value technique. Clients and servers MAY support shared-secret/subject DN matching or other bilateral techniques of similar strength. Both mechanisms have the same idea: force the client to sign some data into each certification request that can be directly tied to the shared secret. That shuts down attempts to slip certification requests from different entities into a single Full PKI Request 🫶
6.3.1. Cryptographic Linkage 🦋
The first technique for linking identity and POP information forces the client to include a piece of information, cryptographically derived from the shared secret, as a signed extension within each certification request (PKCS #10 or CRMF) ✨
6.3.1.1. POP Link Witness Version 2 Controls 🔗✨
okay so the POP Link Witness Version 2 control is identified by this OID 🦋:
id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }and it has this ASN.1 definition 💅:
PopLinkWitnessV2 ::= SEQUENCE {
keyGenAlgorithm AlgorithmIdentifier,
macAlgorithm AlgorithmIdentifier,
witness OCTET STRING
}Here's what each field means 🌸:
keyGenAlgorithmis the algorithm used to make the key for the MAC algorithm. It's usually a hash algorithm, but it could be something more complex.macAlgorithmis the algorithm used to create the witness value.witnessholds the computed witness value.
This technique is super useful when null subject DNs are used 🙈. The server can generate the subject DN for the certificate based only on the shared-secret, which is so clean. Everything starts when the client gets the shared-secret out-of-band from the server. Then the client works through these steps 🧚:
- The client generates a random byte-string, R, which SHOULD be at least 512 bits in length.
- The key is computed from the shared-secret using the algorithm in
keyGenAlgorithm. - A MAC is then computed over the random value produced in Step 1, using the key computed in Step 2.
- The random value produced in Step 1 is encoded as the value of a POP Link Random control. This control MUST be included in the Full PKI Request. 🔥
- The MAC value produced in Step 3 is placed in either the POP Link Witness control or the witness field of the POP Link Witness V2 control.
- For CRMF, the POP Link Witness/POP Link Witness V2 control is included in the controls field of the CertRequest structure.
- For PKCS #10, the POP Link Witness/POP Link Witness V2 control is included in the attributes field of the CertificationRequestInfo structure.
Upon receipt, servers MUST verify that each certification request contains a copy of the POP Link Witness/POP Link Witness V2 control, and that its value was derived using the above method from the shared-secret and the random string included in the POP Link Random control. No skipping the check, bestie 💀.
The Identification control (see Section 6.2.3) or the subject DN of a certification request can be used to help figure out which shared-secret was used 🔍.
6.3.1.2. POP Link Witness Control 🎀
The POP Link Witness control is identified by the OID:
id-cmc-popLinkWitness ::= { id-cmc 23 }Its ASN.1 definition is:
PopLinkWitness ::= OCTET STRINGFor this control, SHA-1 is used as the key generation algorithm, and HMAC-SHA1 is used as the mac algorithm 🌈.
6.3.1.3. POP Link Random Control 🍓
The POP Link Random control is identified by the OID:
id-cmc-popLinkRandom ::= { id-cmc 22 }and it has the ASN.1 definition:
PopLinkRandom ::= OCTET STRING6.3.2. Shared-Secret/Subject DN Linking 🦋
The second way to link identity and POP information is to tie a particular subject distinguished name (subject DN) to the shared-secrets that get distributed out-of-band. Clients using the shared-secret to prove identity have to include that exact subject DN in every certification request 🫶. It's expected that a lot of client-server connections using shared-secret-based proof-of-identity will use this mechanism. (It's common not to leave the subject DN information out of the certification request.)
When the shared-secret is generated and transferred out-of-band to start the registration process (Section 6.2), a particular subject DN is also associated with the shared-secret and communicated to the client. (The subject DN generated MUST be unique per entity in accordance with the CA policy. A null subject DN cannot be used. A common practice could be to place the identification value as part of the subject DN 💖.) When the client generates the Full PKI Request, it MUST use these two pieces of information as follows 👑:
- The client MUST include the specific subject DN that it received along with the shared-secret as the subject name in every certification request (PKCS #10 and/or CRMF) in the Full PKI Request. The subject names in the certification requests MUST NOT be null. 🙅
- The client MUST include an Identity Proof control (Section 6.2.2) or Identity Proof Version 2 control (Section 6.2.1), derived from the shared-secret, in the Full PKI Request.
The server receiving this message MUST (a) validate the Identity Proof control and then, (b) check that the subject DN included in each certification request matches the one associated with the shared-secret. If either of these checks fails, the certification request MUST be rejected 🚫.
6.3.3. Renewal and Rekey Messages 🌸
When you're doing a renewal or rekey certification request, linking identity and POP information is honestly so easy ✨. The client copies the subject DN for a current signing certificate into the subject name field of each certification request that gets made. The POP for each certification request will now cover that information. The outermost signature layer is created using the current signing certificate, which lets the original identity be associated with the certification request. Since the name in the current signing certificate and the names in the certification requests match, the necessary linking is done 🎉.
6.4. Data Return Control 🎀
The Data Return control lets clients send arbitrary data (usually some kind of internal state information) to the server and have that data returned as part of the Full PKI Response 🧚. Data placed in a Data Return control is considered opaque to the server. The same control is used for both Full PKI Requests and Responses. If the Data Return control appears in a Full PKI Request, the server MUST return it as part of the PKI Response 💅.
If the information in the Data Return control needs to be confidential, it's expected that the client would apply some type of encryption to the contained data. The details of that are outside the scope of this specification 🔐.
The Data Return control is identified by the OID:
id-cmc-dataReturn ::= { id-cmc 4 }and it has the ASN.1 definition:
DataReturn ::= OCTET STRINGA client could use this control to place an identifier marking the exact source of the private key material. This might be the identifier of a hardware device containing the private key 🔑.
6.5. RA Certificate Modification Controls 💅
These controls exist so RAs can modify the contents of a certification request 🪄. Modifications might be necessary for various reasons, including adding certificate extensions or modifying subject and/or subject alternative names.
There are two controls for this purpose. The first one, Modify Certification Request (Section 6.5.1), lets the RA replace or remove any field in the certificate. The second one, Add Extensions (Section 6.5.2), only allows adding extensions 🌈.
6.5.1. Modify Certification Request Control 🦋
The Modify Certification Request control is used by RAs to change fields in a requested certificate 💖.
It's identified by the OID:
id-cmc-modCertTemplate ::= { id-cmc 31 }and the Modify Certification Request has the ASN.1 definition:
ModCertTemplate ::= SEQUENCE {
pkiDataReference BodyPartPath,
certReferences BodyPartList,
replace BOOLEAN DEFAULT TRUE,
certTemplate CertTemplate
}The fields in ModCertTemplate mean the following 🍓:
pkiDataReferenceis the path to the PKI Request containing the certification request(s) to be modified.certReferencesrefers to one or more certification requests in the PKI Request referenced bypkiDataReferencethat are to be modified. Each BodyPartID of the certReferences sequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the certificate extensions included in thecertTemplatefield are applied to every certification request referenced in thecertReferencessequence. If a request corresponding to bodyPartID cannot be found, the CMCFailInfo with a value of badRequest is returned that references this control.replacespecifies if the target certification request is to be modified by replacing or deleting fields. If the value is TRUE, the data in this control replaces the data in the target certification request. If the value is FALSE, the data in the target certification request is deleted. The action is slightly different for the extensions field ofcertTemplate, since each extension is treated individually rather than as a single unit 🧐.certTemplateis a certificate template object [CRMF]. If a field is present andreplaceis TRUE, it replaces that field in the certification request. If the field is present andreplaceis FALSE, the field in the certification request is removed. If the field is absent, no action is performed. Each extension is treated as a single field.
Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. Servers are not required to be able to process every X.509v3 extension transmitted using this protocol, nor are they required to be able to process other, private extensions. Servers are not required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension 🙅♀️. If a certification request is denied due to the inability to handle a requested extension and a Full PKI Response is returned, the server MUST return a CMCFailInfo value with the value of unsupportedExt.
If a certification request is the target of multiple Modify Certification Request controls, the behavior is 👑:
- If control A exists in a layer that contains the layer of control B, control A MUST override control B. In other words, controls should be applied from the innermost layer to the outermost layer.
- If control A and control B are in the same PKIData (i.e., the same wrapping layer), the order of application is non-determinate.
The same order of application is used if a certification request is the target of both a Modify Certification Request control and an Add Extensions control ✨.
6.5.2. Add Extensions Control ✨
Okay so the Add Extensions control is officially deprecated 💀 It got replaced by the Modify Certification Request control, because that one lets you change fields in the certification request that aren't extensions. Glow-up energy 🦋
The Add Extensions control is how RAs slip extra extensions into the certificates 🎀
It's identified by this OID:
id-cmc-addExtensions ::= { id-cmc 8 }And here's the ASN.1 definition, bestie 🌸
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}So the fields mean:
pkiDataReferenceis the body part identity of the embedded certification request. 📦certReferencesis a list of references to one or more of the certification requests inside a PKIData. Each body part identifier in thecertReferencessequence MUST be equal to either the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the certReqId of the CertRequest within a CertReqMsg (CRMF). By definition, the listed extensions get applied to every certification request referenced incertReferences. If a certification request matching bodyPartID can't be found, the CMCFailInfo with a value of badRequest is returned, referencing this control. 🙅♀️extensionsis a sequence of extensions to be applied to the referenced certification requests. 💅
Now the server side, which is lowkey the spicy part 🔥 Servers MUST be able to process all extensions defined, but not prohibited, in [PKIXCERT]. They are not required to process every X.509v3 extension sent over this protocol, and they're also not required to process other, private extensions. Servers aren't required to put all RA-requested extensions into a certificate. Servers are permitted to modify RA-requested extensions. Servers MUST NOT alter an extension so as to reverse the meaning of a client-requested extension. ⚠️ And if a certification request gets denied because the server can't handle a requested extension and a response is sent back, the server MUST return a CMCFailInfo with the value of unsupportedExt.
If multiple Add Extensions controls show up in a Full PKI Request, the exact behavior is left up to the CA policy. That said, it is recommended that the following policy be used. These rules get applied to individual extensions within an Add Extensions control, not in an "all or nothing" way. 🧠
- If the conflict is within a single PKIData, the certification request gets rejected with a CMCFailInfo value of badRequest. 🚫
- If the conflict is between different PKIData, the outermost version of the extension gets used, which lets an RA override the requested extension. 👑
6.6. Transaction Identifier Control and Sender and Recipient Nonce Controls 🎀
Okay so transactions get identified and tracked with a transaction identifier, if one is used 🦋 Clients generate these and hold onto the value until the server responds with a Full PKI Response that completes the transaction. Servers then include the received transaction identifiers in that Full PKI Response. It's giving paper trail 📜
The Transaction Identifier control is identified by this OID:
id-cmc-transactionId ::= { id-cmc 5 }Its ASN.1 definition is:
TransactionId ::= INTEGERThis control identifies a given transaction, and client and server use it to manage the state of an operation. Clients MAY include a Transaction Identifier control in a request. If the original request contains a Transaction Identifier control, all subsequent requests and responses MUST include the same Transaction Identifier control. Main character consistency 💖
Now replay protection 🔐 It's handled with the Sender and Recipient Nonce controls. If nonces are used, the first message of a transaction does NOT carry a Recipient Nonce control. Instead, the transaction originator includes a Sender Nonce control and keeps it for later reference. The recipient reflects that value back to the originator as a Recipient Nonce control and includes its own Sender Nonce control. When the originator gets that response, it compares the Recipient Nonce value to the one it saved. If they match, the message can be accepted for further security processing ✨ The received Sender Nonce value gets kept too, so it can be included in the next message of the same transaction. Very organized, very iconic 💅
The Sender Nonce and Recipient Nonce controls are identified by these OIDs:
id-cmc-senderNonce ::= { id-cmc 6 }
id-cmc-recipientNonce ::= { id-cmc 7 }The ASN.1 definitions are:
SenderNonce ::= OCTET STRINGRecipientNonce ::= OCTET STRINGClients MAY include a Sender Nonce control in the initial PKI Request. If a message includes a Sender Nonce control, the response MUST include the transmitted value of the previously received Sender Nonce control as a Recipient Nonce control, and it MUST include a new value as its Sender Nonce control. 🫶 That's the whole nonce ping-pong, periodt 🌈
6.7. Encrypted and Decrypted POP Controls ✨
Okay so, servers MAY only want this POP method if no other POP method is available 🫶. And servers SHOULD reject every certification request inside a PKIData if any required POP is missing for any element in that PKIData. Lowkey strict, but it's giving security 💅.
Lots of servers wanna see proof that whoever made the certification request actually has the matching private part of the key pair 🔐. For keys that can sign stuff, signing the request with the private key counts as the POP. But for keys that can only do encryption, the POP MUST be done by making the client decrypt a value 🦋. Check out Section 5 of [CRMF] if you want the full tea on POP.
Here's the fun part: POP for encryption-only keys can't happen in one round-trip, because there are four distinct steps 🧚:
- Client tells the server about the public component of a new encryption key pair.
- Server sends the client a POP challenge, encrypted with the presented public encryption key.
- Client decrypts the POP challenge using the private key that corresponds to the presented public key and sends the plaintext back to the server.
- Server validates the decrypted POP challenge and continues processing the certification request.
CMC defines two different controls 👑. The first one handles the encrypted challenge that goes from the server to the user in Step 2. The second one handles the decrypted challenge that goes from the client to the server in Step 3.
The Encrypted POP control is how the server sends the encrypted challenge to the client, as part of the PKIResponse 🌸. (Quick note: this assumes the message in Step 1 is a Full PKI Request, and the response in Step 2 is a Full PKI Response that includes a CMCFailInfo saying a POP is explicitly required, plus the POP challenge in the encryptedPOP control.)
The Encrypted POP control is identified by the OID:
id-cmc-encryptedPOP ::= { id-cmc 9 }The Encrypted POP control has the ASN.1 definition:
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}The Decrypted POP control is identified by the OID:
id-cmc-decryptedPOP ::= { id-cmc 10 }The Decrypted POP control has the ASN.1 definition:
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}Here's how the encrypted POP algorithm goes 🎀:
- The server randomly generates the POP Proof Value and associates it with the request.
- The server returns the Encrypted POP control with the following fields set:
request is the original certification request. It's included here so the client doesn't have to keep its own copy of the request.
cms is an EnvelopedData, with the encapsulated content type being id-data and the content being the POP Proof Value. This value needs to be long enough that nobody can reverse it from the witness hash 🙈. If the certification request has a Subject Key Identifier (SKI) extension, then the recipient identifier SHOULD be the SKI. If the issuerAndSerialNumber form is used, the IssuerName MUST be encoded as NULL and the SerialNumber as the bodyPartID of the certification request.
thePOPAlgID identifies the algorithm used to compute the return POP value.
witnessAlgID identifies the hash algorithm used on the POP Proof Value to create the field witness.
witness is the hashed value of the POP Proof Value.
- The client decrypts the
cmsfield to get the POP Proof Value. Then it computes H(POP Proof Value) usingwitnessAlgIDand compares that to the value ofwitness. If the values don't match, or the decryption doesn't work, the client MUST abort the enrollment process 😭. It aborts by sending a request containing a CMC Status Info control with a CMCFailInfo value ofpopFailed. - The client creates the Decrypted POP control as part of a new PKIData. The fields in the DecryptedPOP are:
bodyPartID refers to the certification request in the new PKI Request.
thePOPAlgID is copied from the encryptedPOP.
thePOP contains the possession proof. This value is computed by thePOPAlgID using the POP Proof Value and the request.
- The server then recomputes the value of
thePOPfrom its cached value and the request, and compares it to the value ofthePOP. If the values don't match, the server MUST NOT issue the certificate. The server MAY re-issue a new challenge, or MAY fail the request altogether 💀.
When you're defining the algorithms for thePOPAlgID and witnessAlgID, you gotta make sure the result of witnessAlgID isn't a useful shortcut for computing thePOPAlgID 🫣. The POP Proof Value is used as the secret value in the HMAC algorithm, and the request is used as the data. If the POP Proof Value is greater than 64 bytes, only the first 64 bytes of the POP Proof Value are used as the secret.
One potential problem with the algorithm above is how much state a CA has to keep around in order to verify the returned POP value 😵. Here's one of many possible ways to fix that by shrinking the state on the CA down to a single value (or a small set of them) 🌈:
- Server generates random seed x, constant across all requests. (The value of x would normally be changed on a regular basis and kept around for a short time afterwards.)
- For certification request R, the server computes y = F(x,R). F can be, for example,
HMAC-SHA1(x,R). All that matters for statelessness is that y can be computed consistently using only the known constant state x and function F, with the other inputs coming from the certification request structure. y should not be predictable based on knowledge of R, which is why you use a one-way function like HMAC-SHA1 🔥.
6.8. RA POP Witness Control 🦋
In a certification request scenario that involves an RA, the CA may allow (or require) that the RA perform the POP protocol with the entity that generated the certification request 💜. In that case, the RA needs a way to tell the CA that it already did the POP. That's exactly what the RA POP Witness control is for ✨.
The RA POP Witness control is identified by the OID:
id-cmc-lraPOPWitness ::= { id-cmc 11 }The RA POP Witness control has the ASN.1 definition:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}The fields in LraPOPWitness mean the following:
pkiDataBodyid contains the body part identifier of the nested TaggedContentInfo that holds the client's Full PKI Request. pkiDataBodyid is set to 0 if the request is in the current PKIData.
bodyIds is a list of certification requests for which the RA has done an out-of-band authentication. The authentication method could be archival of private key material, challenge-response, or some other means 🧚.
If a certification server doesn't allow an RA to do the POP verification, it returns a CMCFailInfo with the value of popFailed. The CA MUST NOT start a challenge-response to re-verify the POP itself 🙅♀️.
6.9. Get Certificate Control 🌸
Everything described in this section is optional to implement.
The Get Certificate control is used to retrieve a certificate that was issued earlier, from a certificate repository 📦. A CA, an RA, or an independent service may provide this repository. The clients expected to use this are the ones where a fully deployed directory is either infeasible or undesirable.
The Get Certificate control is identified by the OID:
id-cmc-getCert ::= { id-cmc 15 }The Get Certificate control has the ASN.1 definition:
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }The fields in GetCert mean the following:
issuerName is the name of the certificate issuer.
serialNumber identifies the certificate to be retrieved.
The server that responds to this request puts the requested certificate in the certificates field of a SignedData. If the Get Certificate control is the only control in a Full PKI Request, the response should be a Simple PKI Response 🎀.
6.10. Get CRL Control 💅
Everything described in this section is optional to implement.
The Get CRL control is used to retrieve CRLs from a repository of CRLs 🔍. A CA, an RA, or an independent service may provide this repository. The clients expected to use this are the ones where a fully deployed directory is either infeasible or undesirable.
The Get CRL control is identified by the OID:
id-cmc-getCRL ::= { id-cmc 16 }The Get CRL control has the ASN.1 definition:
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }The fields in a GetCRL mean the following:
issuerName is the name of the CRL issuer.
cRLName may be the value of CRLDistributionPoints in the subject certificate, or an equivalent value in case the certificate doesn't contain one of those.
time is how the client picks, out of potentially several issues of CRL, the one whose thisUpdate value is less than but nearest to the specified time. If there's no time component, the CA always returns the most recent CRL 🕰️.
reasons is used to pick from among CRLs that are partitioned by revocation reason 🍓. Implementers should keep in mind that while a specific revocation request has a single CRLReason code (so entries in the CRL would have a single CRLReason code value), a single CRL can aggregate information for one or more reasonFlags 🫶.
A server responding to this request puts the requested CRL in the crls field of a SignedData. If the Get CRL control is the only control in a Full PKI Request, the response should be a Simple PKI Response 🌈.
6.11. Revocation Request Control 🚫
okay so the Revocation Request control is how you ask for a certificate to be revoked 💅 bestie, this one is serious
The OID for it is:
id-cmc-revokeRequest ::= { id-cmc 17 }Here's the ASN.1 definition, and it's giving very organized energy:
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }So what does each field mean? Let's go 🎀
issuerName is the issuerName of the certificate you want revoked.
serialNumber is the serial number of that same certificate.
reason is the suggested CRLReason code for why the cert is getting revoked. The CA can use it however it wants when it builds the CRL, so it's a suggestion, not a command 🙈
invalidityDate is also a suggested value, this time for the Invalidity Date CRL Extension. Same deal: the CA decides what to do with it when building the CRL.
sharedSecret is a secret value that the EE registered when it got the certificate. It's there so the cert can still be revoked if the key gets lost 😭
comment is just a human-readable comment, so you can say whatever you need to say 💜
Okay now the tea ☕ If a revocation request needs to hold up in a dispute, you need a strong proof-of-origin. BUT, and this is the lowkey tragic part, if an EE has lost its signature private key, it literally can't produce a digital signature anymore (at least not until it gets a new signature key pair certified). So the Revoke Request control lets the EE send the CA a shared-secret that can be used as an alternative authenticator when the signature private key is lost. Whether that's acceptable is up to local security policy, so check with whoever runs your system 🔐
It's also possible to sign a revocation for the lost certificate with a different certificate in some situations. A client can sign a revocation for an encryption key using a signing certificate, as long as the name information matches. Similarly, an administrator or RA can be given the ability to revoke a third party's certificate. Whether the server accepts any of these depends on local policy 🌸
Now the requirements, which are the most important part so pay attention bestie ✨
Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared-secret (the unsigned message is a SignedData with no signatures). If a client provides shared-secret-based self-revocation, the client MUST be capable of producing a Revocation Request control containing the shared-secret. Servers MUST be capable of accepting both forms of revocation requests 🫶
How the unsigned, shared-secret-based revocation request is structured is up to local implementation, so there's no single correct way to build it 🧚
The shared-secret does not need to be encrypted when it's sent in a Revocation Request control. It's also one-time use (it only exists to request revocation of the certificate), and once the certificate has been revoked, the shared-secret being public knowledge is not a problem 🦋
Clients need to inform users that the same shared-secret SHOULD NOT be used for multiple certificates. Please tell your users this, it's important 🙏
A Full PKI Response MUST be returned for a revocation request. No skipping this one 💀
6.12. Registration and Response Information Controls 📋
The Registration Information control lets clients pass extra information along as part of a Full PKI Request 🍓
Its OID is:
id-cmc-regInfo ::= { id-cmc 18 }And its ASN.1 definition is:
RegInfo ::= OCTET STRINGWhat goes inside is based on a bilateral agreement between the client and the server, so the two sides have to agree on it ahead of time 🤝
The Response Information control is the mirror image. It lets a server send back extra information as part of a Full PKI Response 🌈
Its OID is:
id-cmc-responseInfo ::= { id-cmc 19 }And its ASN.1 definition is:
ResponseInfo ::= OCTET STRINGSame story here: the content is based on a bilateral agreement between the client and the server ✨
6.13. Query Pending Control ⏳
ngl this one is so relatable. In some environments, manual intervention or other identity checks can hold up the certificate for a while 😩 That's where the Query Pending control comes in. It lets clients ask a server what's going on with a pending certification request. The server hands back a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client then copies that pendToken into the Query Pending control so the server knows exactly which request it means 🎯 The server can also return a suggested time for when the client should check back on the state of the pending request ⏰
Its OID is:
id-cmc-queryPending ::= { id-cmc 21 }And its ASN.1 definition is:
QueryPending ::= OCTET STRINGIf a server returns a pending or partial CMCStatusInfo (meaning the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of 'pendInfo' MUST be the same as the original pendInfo value 💜
6.14. Confirm Certificate Acceptance Control ✅
Some CAs want clients to give a positive confirmation that the certificates issued to the EE are acceptable. That's exactly what the Confirm Certificate Acceptance control is for 💅 If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request.
Clients SHOULD wait for the PKI Response from the server saying the confirmation has been received before using the certificate for any purpose. Don't jump the gun, bestie 🙈
Its OID is:
id-cmc-confirmCertAcceptance ::= { id-cmc 24 }And its ASN.1 definition is:
CMCCertId ::= IssuerAndSerialNumberCMCCertId holds the issuer and serial number of the certificate being accepted 🎀
Servers MUST return a Full PKI Response for a Confirm Certificate Acceptance control.
Heads up that if the CA includes this control, there will be two full round-trips of messages 🔁 Here's how it goes:
- The client sends the certification request to the CA.
- The CA returns a Full PKI Response with the certificate and this control.
- The client sends a Full PKI Request to the CA with an Extended CMC Status Info control accepting and a Confirm Certificate Acceptance control, or an Extended CMC Status Info control rejecting the certificate.
- The CA sends a Full PKI Response to the client with an Extended CMC Status Info of success.
6.15. Publish Trust Anchors Control 📢
The Publish Trust Anchors control is how a central authority distributes a set of trust anchors to an EE. The same control is also used to update that set 🌟 Trust anchors get distributed as certificates. These are expected, but not required, to be self-signed certificates. Information is pulled out of these certificates to set the inputs to the certificate validation algorithm in Section 6.1.1 of [PKIXCERT] 🧠
Its OID is:
id-cmc-trustedAnchors ::= { id-cmc 26 }And its ASN.1 definition is:
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}Here's what each field means:
seqNumber is an integer that shows where this update sits within a sequence of updates 🔢
hashAlgorithm is the identifier and parameters for the hash algorithm used to compute the values in the anchorHashes field. All implementations MUST implement SHA-1 for this field 🫡
anchorHashes are the hashes of the certificates that the client should treat as trust anchors. The actual certificates are carried in the certificate bag of the containing SignedData structure 📦
While it's recommended that the sender put the trusted certificates in the PKI Response, it's not required, since the certificates should be obtainable through normal discovery techniques 🔍
Before accepting any trust anchor changes, a client MUST at least do the following: validate the signature on the PKI Response to a current trusted anchor, check with policy to make sure the signer is permitted to use the control, validate that the authenticated publish time in the signature is near the current time, and validate that the sequence number is greater than the one used previously. Don't skip any of these, it's giving security 🔐
If multiple agents publish a set of trust anchors, it's up to local policy to decide how the different trust anchors get combined. Clients SHOULD be able to handle updates to multiple trust anchors independently 💖
Note: Clients that handle this control must use extreme care in validating that the operation is permissible. Incorrect handling of this control allows for an attacker to change the set of trust anchors on the client. 😱
6.16. Authenticated Data Control 🔏
The Authenticated Data control lets a server send data back to the client in an authenticated way 🛡️ It uses the Authenticated Data structure so the data can be validated. This is for the case where the client and server share a shared-secret and a secret identifier, but the client hasn't downloaded a trust anchor yet, so it can't validate the server's signing certificate. The specific case this control was made for is the Publish Trust Anchors control (Section 6.15), but it can be used in other cases too 🦋
Its OID is:
id-cmc-authData ::= { id-cmc 27 }And its ASN.1 definition is:
AuthPublish ::= BodyPartIDAuthPublish is a body part identifier that refers to a member of the cmsSequence element for the current PKI Response or PKI Data. The cmsSequence element is AuthenticatedData, and the encapsulated content is an id-cct-PKIData. The controls in the controlSequence need to be processed if the authentication succeeds. (One example is the Publish Trust Anchors control in Section 6.15.) ✨
If the authentication operation fails, the CMCFailInfo authDataFail is returned 🙅♀️
6.17. Batch Request and Response Controls
okay bestie, this is the batch glow-up 🧺✨ An RA can collect multiple requests together into a single Full PKI Request and forward it to a CA. Then the server processes them and sends back all the results in one Full PKI Response. main character energy 👑
The Batch Request control is identified by the OID:
id-cmc-batchRequests ::= {id-cmc 28}The Batch Response control is identified by the OID:
id-cmc-batchResponses ::= {id-cmc 29}Both the Batch Request and Batch Response controls have the ASN.1 definition:
BodyPartList ::= SEQUENCE of BodyPartIDThe data in these controls is a set of body part identifiers 🫶 Each request or response gets placed as its own entry in the cmcSequence of the new PKIData or PKIResponse. Then the body part identifiers of those entries get stuffed into the body part list that goes with the control. It's like a little tracking list, so everything stays organized 📋🌸
When a server processes a Batch Request control, it MAY return the responses in one or more PKI Responses. Every PKI Response except the last one comes back with a CMCStatus of partial 🧩 The CMCStatus would be success as long as the Batch Request control got processed, because the individual responses carry their own CMCStatus codes. Errors on individual requests do not bubble up to the top level, so one sad request can't ruin the whole party 🥳
When a PKI Response comes back with a CMCStatus of partial, the Query Pending control (Section 6.13) is how the client grabs the rest of the results. The returned status also includes a suggested time for when the client should ask for the additional results ⏰
6.18. Publication Information Control
the Publication Information control lets you change whether already issued certificates get published, either putting them out there or pulling them back down 🌈 A super common use is removing an existing certificate from publication during a rekey operation. This control should always be processed after new certificates have been issued and revocation requests handled. It should not be processed if a certificate failed to be issued 🙅♀️
The Publication Information control is identified by the OID:
id-cmc-publishCert ::= { id-cmc 30 }The Publication Information control has the ASN.1 definition:
CMCPublicationInfo ::= SEQUENCE {
hashAlg AlgorithmIdentifier,
certHashes SEQUENCE of OCTET STRING,
pubInfo PKIPublicationInfo
PKIPublicationInfo ::= SEQUENCE {
action INTEGER {
dontPublish (0),
pleasePublish (1) },
pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL }
-- pubInfos MUST NOT be present if action is "dontPublish"
-- (if action is "pleasePublish" and pubInfos is omitted,
-- "dontCare" is assumed)
SinglePubInfo ::= SEQUENCE {
pubMethod INTEGER {
dontCare (0),
x500 (1),
web (2),
ldap (3) },
pubLocation GeneralName OPTIONAL }
}Here's what the fields in CMCPublicationInfo mean 💅
hashAlgis the algorithm identifier of the hash algorithm used to compute the values incertHashes.certHashesare the hashes of the certificates whose publication is about to change.pubInfois where and how the certificates should be published. Its fields (taken from [CRMF]) mean the following:actiontells the service what to do. There are two values:dontPublishmeans the PKI should not publish the certificate. This might mean the requester plans to publish it themselves 🙃dontPublishalso carries the added vibe of pulling the certificate out of publication if it's already published.pleasePublishmeans the PKI MAY publish the certificate using whatever means it chooses, unlesspubInfosis present. Leaving out the CMC Publication Info control gives you the same behavior ✨
pubInfosindicates how (e.g., X500, Web, IP Address) the PKI SHOULD publish the certificate 🌐
A single certificate SHOULD NOT appear in more than one Publication Information control. If it does, the behavior is undefined, so please don't go there 💀
6.19. Control Processed Control
the Control Processed control lets an RA tell the next control processors that a specific control has already been handled 🧚 This lets an RA sitting in the middle of a processing stream handle a control that's defined either in a local context or in a later document. Iconic flex 💜
The Control Processed control is identified by the OID:
id-cmc-controlProcessed ::= { id-cmc 32 }The Control Processed control has the ASN.1 definition:
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}bodyListis a series of body part identifiers that form a path to each control the RA processed. This control is only needed for controls that aren't part of this standard. Without it, a server that runs into a control not defined in this document would hit an error condition 😭 No error status is needed here, because an error makes the RA send the request back to the client with the error, instead of passing it on to the next server in the processing list.
7. Registration Authorities
okay the RA era begins 🦋 This specification allows the use of RAs. An RA sits between the EE and the CA. From the EE's point of view, the RA looks like the CA, and from the server's point of view, the RA looks like a client. RAs receive PKI Requests, do some local processing, and then forward them on to CAs. Some of the local processing an RA can do includes:
- Batching multiple PKI Requests together,
- Performing challenge/response POP proofs,
- Adding private or standardized certificate extensions to all certification requests,
- Archiving private key material,
- Routing requests to different CAs.
When an RA receives a PKI Request, it has three options 🧠 It may forward the PKI Request without modification, it may add a new wrapping layer to the PKI Request, or it may remove one or more existing layers and add a new wrapping layer.
When an RA adds a new wrapping layer to a PKI Request, it creates a new PKIData. The new layer holds any controls that are needed (for example, if the RA does the POP proof for an encryption key, or uses the Add Extension control to modify a PKI Request) along with the client PKI Request. The client PKI Request goes in the cmsSequence if it's a Full PKI Request, and in the reqSequence if it's a Simple PKI Request. If an RA is batching multiple client PKI Requests together, each one goes into the right spot in the RA's PKIData object, along with all the relevant controls 🎀
If multiple RAs sit in the path between the EE and the CA, the request ends up with multiple wrapping layers 🪆
In processing a PKI Request, an RA MUST NOT alter any certification requests (PKCS #10 or CRMF). Any alteration would invalidate the signature on the certification request, and that would break the POP for the private key 🚫
Here's what it looks like:
SignedData (by RA)
PKIData
controlSequence
RA added control statements
reqSequence
Zero or more Simple PKI Requests from clients
cmsSequence
Zero or more Full PKI Requests from clients
SignedData (signed by client)
PKIDataSometimes an RA is required to remove wrapping layers. The next sections look at the processing needed when encryption layers and signing layers have to come off 🔐
7.1. Encryption Removal
there are two cases where an RA has to remove or change encryption in a PKI Request 🙈 In the first case, the encryption was applied to protect the whole PKI Request from unauthorized entities. If the CA doesn't have a Recipient Info entry in the encryption layer, the RA MUST remove the encryption layer. The RA MAY add a new encryption layer, with or without adding a new signing layer.
The second kind of change is changing the encryption inside a signing layer. In this case, the RA MUST remove all signing layers containing the encryption. All control statements MUST be merged according to local policy rules as each signing layer is removed, and the merged controls MUST be placed in a new signing layer provided by the RA. If the signing layer provided by the EE also needs to come off, the RA can remove that layer too 🧹
7.2. Signature Layer Removal
there are only two situations where an RA should remove a signature layer on a Full PKI Request: when an encryption layer needs to be modified inside the request, or when a CA won't accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request 🙅♀️
If an RA removes a signing layer from a PKI Request, all control statements MUST be merged according to local policy rules. The merged control statements MUST then be placed in a new signing layer provided by the RA 💖
8. Security Considerations 🔐✨
Okay bestie, security is where we get serious. 🫶 Replay attacks might need extra protection depending on where the protocol is running. If the CA keeps a lot of state, replay attacks might be detectable even without the optional nonce mechanisms. Implementers need to think carefully about their environment before deciding whether to use the senderNonce and recipientNonce controls from Section 6.6. Developers of state-constrained PKI clients are strongly encouraged to use these controls. 💅
Archiving a signing key is a big deal, so take extreme care with it 😭. Whoever holds an archived key may be able to use it to make forged signatures. Still, there are good reasons to archive a signing key. An archived CA signing key can be recovered if the CA fails to keep producing CRLs after a disaster. 🌈
Be careful before you archive keys 🎀. Once a key goes to an archiving entity, that entity could use the keys in ways that don't serve the archiving entity. Users should be especially aware that the certificate used to encrypt the private key material is properly verified. 👑
Clients and servers need to run some checks on cryptographic parameters before issuing certificates, so weak parameters don't get used 🔥. The small subgroup attack is described in [X942], and methods for avoiding it are in [SMALL-GROUP]. CMC implementations ought to know about this attack when they validate parameters. 🧚
If you're using a shared secret for authentication, generate it with good random number techniques [RANDOM]. If users pick the secret themselves, dictionary attacks can be mounted against it 🙈.
Extreme care must be used when processing the Publish Trust Anchors control. Incorrect processing can lead to slamming, where an attacker changes the set of trusted anchors to weaken security. 🚨
One way to control the use of the Publish Trust Anchors control goes like this 💖. The client needs to associate each accepted trust anchor with its source. The client should also associate each trust anchor with the types of messages it is valid for, like whether the trust anchor is used to validate S/MIME messages, TLS, or CMC enrollment messages.
When a new message arrives with a Publish Trust Anchors control, the client would accept the new set of trust anchors for specific applications only if three things are true ✨. The signature validates. The signer of the message has the required policy approval to update the trust anchors. Local policy also allows updating the trust anchors. All three, periodt 💅.
The CMS AuthenticatedData structure provides message integrity, but it doesn't provide message authentication in every case 🥺. If you use MACs in this document, these restrictions apply. All messages should be for a single entity. If two entities are placed in one message, they can generate new messages with a valid MAC, which might be assumed to come from the original message sender. Anyone with access to the shared secret can generate messages that pass MAC validation, so take care to keep that value secret 🔒. Whenever possible, use the SignedData structure instead of the AuthenticatedData structure. 🦋
9. IANA Considerations 🌸
This document defines a bunch of control objects 🍓. They're identified by Object Identifiers (OIDs), which come from an arc that IANA delegated to the PKIX Working Group. No further action by IANA is needed for this document or any anticipated updates. Easy peasy 💜.
10. Acknowledgments 🫶
The authors and the PKIX Working Group are so grateful to Xiaoyi Liu and Jeff Weinstein for helping write the original versions of this document 🌷.
The authors also want to thank Brian LaMacchia for developing and writing up many of the concepts in this document 👑. Alex Deacon and Barb Fox get a shout-out too for their contributions ✨.
11. References 📚
11.1. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. 🎀
[CRMF] Schaad, J., "Internet X.509 Certification Request Message Format", RFC 4211, January 2005. 💖
[DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, June 2000. 🦋
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax v1.5", RFC 2314, October 1997. 🧚
Note that this version of PKCS #10 is used for compatibility with the 1988 ASN.1 syntax. The PKIX working group is currently working on an update to the 2003 ASN.1 syntax 🙈.
[PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. 🌈
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. 💅
11.2. Informative References
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008. 🌸
[CMC-COMPL] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008. ⭐
[PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST SP 800-63, April 2006. 🔐
[RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎲
[SMALL-GROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000. 🧚
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. 💜
[RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000. 🍓
Appendix A. ASN.1 Module ✨
okay bestie, this is the vocab list 💅 every CMC control, status code, and request type gets defined right here so everyone speaks the same language. it's giving schema drip 🎀
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
}
ENDAppendix B. Enrollment Message Flows 🦋
okay so this section is informational, which just means it's not normative 🌸 its whole vibe is showing, in an abstracted version, the messages that would flow between the client and server for a bunch of different common cases. think of it as the highlight reel 🎬✨
B.1. Request of a Signing Certificate ✨
okay so this section walks through the messages that go back and forth when an enrollment is happening for a signing-only key 🖋️ if the cert was meant for both signing AND encryption, the only difference is the key usage extension in the certification request. literally one line 💅
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 = 1000Response 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 CAB.2. Single Certification Request, But Modified by RA 🎀
this one is giving middleman 👀 the enrollment has ONE RA sitting in the middle of the data flow, and that RA changes the certification request before it passes it along to the CA. so chaotic, but fine 🫶
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 = 1000Message 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 CAResponse 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 CAB.3. Direct POP for an RSA Certificate 🔐
this section is for an enrollment done for an encryption-only certificate using the direct POP method 🦋 to keep things simple, we assume the certification requester already has a signing-only certificate. ✨
the fact that a second round-trip is needed is implicit rather than explicit 🙈 the server figures this out itself, based on the fact that no other POP exists for the certification request. big brain server moment 🧠
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 certResponse #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 certResponse #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 CAAppendix C. Production of Diffie-Hellman Public Key Certification Requests 🌈
okay so part of a certification request is a signature over the request 🖊️ and Diffie-Hellman is a key agreement algorithm, so it can't be used to directly make that required signature object. not its job, bestie 💀 [DH-POP] gives two ways to produce the necessary signature value. this document ALSO defines a signature algorithm that doesn't give you a POP value, but it CAN be used to produce the necessary signature value ✨
C.1. No-Signature Signature Mechanism 🫧
key management (encryption/decryption) private keys can't always be used to make some type of signature value, because they can live in a decrypt-only device 🔒 certification requests require that the signature field be populated, so this section gives a signature algorithm made for exactly that purpose 💜 the following object identifier and signature value identify this signature type:
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRINGThe 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. no shortcuts, periodt 💅
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.comFull Copyright Statement ✨
Copyright (C) The IETF Trust (2008) 🎀
okay so this doc is covered by the rules, licenses and restrictions in BCP 78 📜, and unless those rules say otherwise, the authors keep all their rights 💖
this document and everything in it is handed over "AS IS" 🫶 and the contributor, the org they represent or are sponsored by (if any), the Internet Society, the IETF Trust and the Internet Engineering Task Force all say NO to ALL warranties, express or implied 🙅♀️ including (but not limited to) any promise that using the info here won't infringe anyone's rights, and any implied warranties of merchantability or fitness for a particular purpose 💀
Intellectual Property 💅
the IETF doesn't take a side on whether any Intellectual Property Rights or other rights claimed to cover the tech in this doc are valid or how far they reach 🧚, or whether a license for them is even available 🌸. it also doesn't claim to have done any independent digging to find such rights 🙈 the rules for rights in RFC docs live in BCP 78 and BCP 79 🦋
copies of IPR disclosures sent to the IETF Secretariat 📬, plus any assurances of licenses that will be made available, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🌈. the same goes for the result of any attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights 💜
the IETF also invites anyone who's interested to flag any copyrights, patents, patent applications or other proprietary rights that might cover tech needed to implement this standard 👑 just send the info to the IETF at ietf-ipr@ietf.org ✨
📦 where this page comes from
- ietf: rfc5272 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms