RFC 6402

Certificate Management over CMS (CMC) Updates

📅 published November 2011, from ietf

RFC 6402: Certificate Management over CMS (CMC) Updates ✨

Okay bestie, let's get into RFC 6402 🦋 It's a Standards Track doc from the IETF, written by J. Schaad at Soaring Hawk Consulting, dated November 2011. It's numbered 6402, it has ISSN 2070-1721, and it updates RFC 5272, RFC 5273, and RFC 5274 💜

Abstract

This doc has a set of updates to the base syntax for CMC, which is a Certificate Management protocol built on the Cryptographic Message Syntax (CMS) 💅 It updates RFC 5272, RFC 5273, and RFC 5274.

The new stuff is: new controls for future work on server side key generation, a Subject Information Access value to identify CMC servers, and a registered TCP/IP port number for the CMC service to run on 🌸

Status of This Memo

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 ✨

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6402.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🎀 Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Requirements Terminology . . . . . . . . . . . . . . . . .  3
  1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  3
2.  Updates to RFC 5272 - "Certificate Management over CMS
    (CMC)" . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.1.  New Section 1.3 - "Updates Made by RFC 6402" . . . . . . .  3
  2.2.  Update Section 6 - "Controls"  . . . . . . . . . . . . . .  4
  2.3.  Replace Section 6.3 - "Linking Identity and POP
        Information" . . . . . . . . . . . . . . . . . . . . . . .  4
  2.4.  Replace Section 6.3.3 - "Renewal and Rekey Messages" . . .  5
  2.5.  New Section 6.20 - "RA Identity Proof Witness Control" . .  5
  2.6.  New Section 6.21 - "Response Body Control" . . . . . . . .  7
  2.7.  New Section 7 - "Other Attributes" . . . . . . . . . . . .  8
  2.8.  New Section 7.1 - "Change Subject Name Attribute"  . . . .  8
  2.9.  New Section 9 - "Certificate Requirements" . . . . . . . . 10
  2.10. New Section 9.1 - "Extended Key Usage" . . . . . . . . . . 10
  2.11. New Section 9.2 - "Subject Information Access" . . . . . . 11
  2.12. Update Section 8 - "Security Considerations" . . . . . . . 11
3.  Updates to RFC 5273 - "Certificate Management over CMS
    (CMC): Transport Protocols"  . . . . . . . . . . . . . . . . . 12
  3.1.  Update Section 5 - "TCP-Based Protocol"  . . . . . . . . . 12
  3.2.  New Section 6 - "IANA Considerations"  . . . . . . . . . . 12
4.  Updates to RFC 5274 - "Certificate Management Message over
    CMS (CMC): Compliance Requirements"  . . . . . . . . . . . . . 13
  4.1.  Update to Section 4.2 - "Controls" . . . . . . . . . . . . 13
5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  7.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
  7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A.  ASN.1 Modules . . . . . . . . . . . . . . . . . . . . 15
  A.1.  1988 ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 15
  A.2.  2008 ASN.1 Module  . . . . . . . . . . . . . . . . . . . . 24

1. Introduction ✨

While working on the Suite B profile of CMC [RFC6403], a bunch of deficiencies showed up in the current base CMC specification 🙈 This document has a set of updates to [RFC5272], [RFC5273], and [RFC5274] to fix those issues.

1.1. Requirements Terminology

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

These abbreviations show up in this document. Terms are used as defined in Section 2.1 of RFC 5272 🌈

CA   - Certification Authority
CRL  - Certificate Revocation List
CRMF - Certificate Request Message Format
EE   - End-Entity
MAC  - Message Authentication Code
PKI  - Public Key Infrastructure
RA   - Registration Authority

2. Updates to RFC 5272 - "Certificate Management over CMS (CMC)" 🦋

2.1. New Section 1.3 - "Updates Made by RFC 6402"

Insert this section before the current Section 1.3.

The following updates were made by RFC 6402. Here's the tea 🍓

Add new controls:
- RA Identity Witness allows an RA to do identity checking using the identity and shared-secret, and then tell any following servers that the identity check was successfully performed.
- Response Body allows an RA to identify a nested response for an EE to process.
Create a new attribute, Change Subject Name, that lets a client ask for a change to the subject name and subject alternate name fields in a certificate.
Add Extended Key Usages for CMC to tell server types apart.
Define a new Subject Information Access type to hold locations where clients can contact the CMC server.
Clarify that using a pre-existing certificate isn't limited to just renewal and rekey messages, and that it is required for support. This makes official a requirement for renewal and rekey that used to be implied 💅

2.2. Update Section 6 - "Controls"

Update Table 1 by adding the following rows:

+--------------------------+-----------+-----------------+---------+
| Identifier Description   | OID       | ASN.1 Structure | Section |
+--------------------------+-----------+-----------------+---------+
| id-cmc-raIdentityWitness | id-cmc 35 | BodyPartPath    | 6.20    |
|                          |           |                 |         |
| id-cmc-responseBody      | id-cmc 37 | BodyPartPath    | 6.21    |
+--------------------------+-----------+-----------------+---------+

Addition to Table 1: CMC Control Attributes

2.3. Replace Section 6.3 - "Linking Identity and POP Information"

Replace the text of the section with the following text. 🫶

In a CMC Full PKI Request, identity proof info about the client is carried in the certificate tied to the signature on the SignedData that holds the certification requests. It can also be carried in one of the two identity proof controls, or in the MAC computed for the AuthenticatedData containing the certification requests. Proof-of-possession (POP) info for key pairs, though, is carried separately for each PKCS #10 or CRMF certification request. (For keys that can make 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 supplied both the POP and the proof-of-identity info 👀

We describe three ways to link identity and POP info: witness values cryptographically derived from a shared-secret (Section 6.3.1), shared-secret/subject name matching (Section 6.3.2), and subject name matching to an existing certificate (Section 6.3.3). Clients and servers MUST support the witness value and the certificate linking techniques. Clients and servers MAY support shared-secret/name matching or MAY support other bilateral techniques of similar strength. The idea behind the first two is to make the client sign some data into each certification request that can be directly tied to the shared-secret. That shuts down attempts to sneak certification requests from different entities into one Full PKI Request 🔥

2.4. Replace Section 6.3.3 - "Renewal and Rekey Messages"

Make the new section title "Existing Certificate Linking". Replace all the text in this section with this text.

Linking between the POP and an identity is easy when an existing certificate is used 🌸 The client copies all of the naming info from the existing certificate (subject name and subject alternative name) into the new certification request. The POP on the new public key is then done by using the new key to sign the identity info, which links the POP to a specific identity. The identity info is then tied to the POP info by signing the entire enrollment request with the private key of the existing certificate.

Existing certificate linking can be used in these situations:

When replacing a certificate by doing a renewal or rekey certification request.
Using an existing certificate to get a new certificate. An example is getting a key establishment certificate after you've already got a signature certificate.
Using a third-party certificate to get a new certificate from a CA. An example is using a certificate and key pair that came with a device to prove an identity. This requires that the CA have an out-of-band channel to map the identity in the device certificate to the new EE identity.

Part 1 is done, and part 2 is coming next! 🧚

2.5. New Section 6.20 - "RA Identity Proof Witness Control" ✨

Insert this section.

Okay bestie, so this control lets an RA tell later control processors "hey, every identity proof requirement is already handled" 🫶. That means the identity proof can happen somewhere closer to the end-entity 🌸. Picture it happening at lots of physical locations while the CA runs company-wide 🏢. The RA does the identity proof and any other tasks that need the secret, and the CA is kept from ever knowing the secret 🙈. If the identity proof fails, the RA sends an error back to the client saying so 💀.

The relevant ASN.1 for the RA Identity Proof Witness control is as follows:

      cmc-raIdentityWitness CMC-CONTROL ::=
         { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }

      id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}

The above ASN.1 defines the following items:

cmc-raIdentityWitness is a CMC-CONTROL associating the object identifier id-cmc-raIdentityWitness and the type BodyPartPath. This object is omitted from the 1988 module. The object is added to the object set Cmc-Control-Set. This control is permitted to appear only in the control sequence of a PKIData object. It MUST NOT appear in the control sequence of a PKIResponse. Only an RA is allowed to use it 🎀. The control may appear multiple times in a control sequence, with each occurrence pointing to a different object 🦋.

id-cmc-raIdentityWitness is the object identifier used to identify this CMC control.

BodyPartPath is the type structure associated with the control. The syntax of BodyPartPath is defined in Section 3.2.2. The path contains a sequence of body part identifiers leading to one of the following items:

Identity Proof control if the RA verified the identity proof in this control.
Identity Proof Version 2 control if the RA verified the identity proof in this control.
Full PKI Request if the RA performed an out-of-band identity proof for this request. The request SHOULD NOT contain either Identity Proof control.
Simple PKI Request if the RA performed an out-of-band identity proof for this request.

The RA Identity Proof Witness control will frequently be paired with a Modify Certification Request control, which changes the name fields in the associated certification requests 📝. That's because the RA knows the actual name to be given to the entity requesting the certificate, while the end-entity doesn't have the name details yet. (The association would be set up by the operator at the time the shared-secret was generated by the RA.)

When this control is placed in a message, it is RECOMMENDED that the Control Processed control be placed in the body sequence as well. Using the explicit new control, rather than relying implicitly on the Control Processed control, really matters because you need to know exactly which identity proofs were performed 🔍. The new control also lets an RA state that out-of-band identity proofs have been performed ✨.

When the identity proof is performed by an RA, the RA also MUST validate the linking between the identity proof and the name information wrapped inside of the key proof-of-possession 🔐.

2.6. New Section 6.21 - "Response Body Control" 🌈

Insert this section.

The Response Body Control is built so an RA can tell an EE that there's an embedded response message that MUST be processed as part of handling this message 📬. It's meant for a couple of cases where an RA did some extra work on the certification request, like key generation 🔑. When an RA generates a key on behalf of an EE, the RA MUST respond with both the original response message from the certificate issuer (containing the certificate issuance) and the response the RA generates (containing the new key) 💖. Another case where this is useful is when the secret is shared between the RA and the EE (instead of between the CA and the EE) and the RA returns the Publish Trust Anchors control, which populates the correct trust points 🧚.

The relevant ASN.1 for the Response Body Control is as follows:

     cmc-responseBody CMC-CONTROL ::= {
        BodyPartPath IDENTIFIED BY id-cmc-responseBody
     }

     id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37}

The above ASN.1 defines the following items:

cmc-responseBody is a CMC-CONTROL associating the object identifier id-cmc-responseBody with the type BodyPartPath. This object is omitted from the 1988 module. The object is added to the object set Cmc-Control-Set. This control is permitted to appear only in the control sequence of a PKIResponse. It MUST NOT appear in the control sequence of a PKIData. It's expected that only an intermediary RA will use this control. A CA generally doesn't need it, since the CA is creating the original innermost message 🙃.

id-cmc-responseBody is the object identifier used to identify this CMC control.

2.7. New Section 7 - "Other Attributes" 🎀

Insert this section before the current Section 7.

There are a bunch of places where different kinds of attributes can go in either a CMC request or a CMC response message 💅. They include the attribute sequence of a PKCS #10 request, the controls in CRMF (Section 6 of [RFC4211]), and the various CMS attribute sequences 🗂️.

2.8. New Section 7.1 - "Change Subject Name Attribute" 🦋

Insert this section.

The Client Name Change Request attribute lets a client ask for a name change as part of a certification request 🪄. You can't just swap the requested subject name in the certificate template, because of security issues 🚨. The name in the certification request MUST match the name in the certificate used to verify the request, so identity and possession proofs get applied correctly 🔐.

The relevant ASN.1 for the Client Name Change Request attribute is as follows:

      at-cmc-changeSubjectName ATTRIBUTE ::=
         { ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }

      id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36}

      ChangeSubjectName ::= SEQUENCE {
          subject             Name OPTIONAL,
          subjectAlt          SubjectAltName OPTIONAL
      }
      (WITH COMPONENTS {..., subject PRESENT} |
            COMPONENTS {..., subjectAlt PRESENT} )

This attribute is designed to be used as an ATTRIBUTE object. So it gets placed in one of these two spots:

The attributes field in a CertificationRequest.
The controls field of a CertRequest for a CRMF certification request.

The control is identified by the Object Identifier id-cmc-changeSubjectName.

The ASN.1 type associated with the control is ChangeSubjectName. Here's how its fields are set up:

subject contains the requested subject name for the new certificate.

subjectAlt contains the requested subject alternative name for the new certificate.

At least one of the fields in the sequence MUST be present when encoding the structure 🧁.

When the CA processes this attribute in a certification request, it does the following:

If present, the subject field is copied to the name field of the template. If the subject field is absent, the name field of the template will be set to a empty sequence.
If present, the subjectAlt field is used as the content of a SubjectAltName extension in the certificate. If the subjectAlt field is absent, the subjectAltName extension is removed from the certificate template.

2.9. New Section 9 - "Certificate Requirements" 🔐

Insert this section before the current Section 8.

Certificates for servers used in the CMC protocol SHOULD conform to the profile defined in [RFC5280] 📜. This document also defines some additional items that MAY appear in CMC server certificates 🌟. Section 9.1 defines some additional values for the Extended Key Usage extension. Section 9.2 defines a new Subject Information Access value that lets a CMC certificate publish information on how to contact the services it provides 📞.

2.10. New Section 9.1 - "Extended Key Usage" 💜

Insert this section.

The Extended Key Usage (EKU) extension restricts a certificate to specific applications 🎯. This document defines three EKUs. The ASN.1 to define them is:

      id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
      id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
      id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }

Here's the usage description for each of the EKUs:

CMC Certification Authorities are identified by the id-kp-cmcCA extended key usage. The certificate may be the same as or different from the CA certificate. If a different certificate is used, the certificates containing the id-kp-cmcCA extended key usage SHOULD have the same name as the certificate used for issuing the certificates. (Using a separate key pair for CMC protocol operations and for issuing certificates and CRLs decreases the number of operations for which the private key used to sign certificates and CRLs would be used 🔑.)

CMC Registration Authorities are identified by the id-kp-cmcRA extended key usage. This usage is placed into RA certificates 🏷️.

CMC Archive Servers are identified by the id-kp-cmcArchive extended key usage. CMC Archive Servers and the associated protocol are to be defined in a future document 🔮.

2.11. New Section 9.2 - "Subject Information Access" 🧚

Insert this section.

The subject information access extension indicates how to access information and services for the subject of the certificate 🗺️. This document defines a new value for use in this extension, to identify the different locations where CMC services will be available. If this value is placed in a certificate, an appropriate extended key usage defined in Section 9.1 MUST be included in the certificate as well 💅.

The id-ad-cmc OID is used when the subject offers certification services using the CMC protocol. If the CMC services are available via HTTP or FTP, accessLocation MUST be a uniformResourceIdentifier. If the CMC services are available via electronic mail, accessLocation MUST be an rfc822Name. If CMC services are available using TCP/IP, the dNSName or iPAddress name forms MUST be used. Since the GeneralName data structure doesn't allow a port number, the value of 5318 should be used in the absence of other external configuration information. (The port registration is in Section 3.2.) The semantics of other name forms of accessLocation (when accessMethod is id-ad-cmc) are not defined by this specification 🌸.

The ASN.1 type for this extension is GeneralName (see Section 4.2.1.8 of [RFC5280]).

   id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }

2.12. Update Section 8 - "Security Considerations" 🔐

Okay bestie, now we're in the serious security part 😭 Add the following paragraphs to the end of Section 8.

So a bunch of controls, like the RA Identity Proof Witness control, exist so an RA can make assertions about a certification request or modify it 👀 Any upstream request processor, like a CA, MUST verify that the RA is fully identified and authorized to make the assertion or modification it's claiming. If it isn't identified or authorized, then any request MUST be rejected. No exceptions, periodt 💅

CMC servers, both RAs and CAs, need to do their due diligence when checking the contents of a certification request 🧐 At an absolute minimum, all fields should be checked to make sure the policies of the CA/RA are correctly enforced. Every field matters, but special care should be taken with names, name forms, algorithm choices, and algorithm parameters 💖

3. Updates to RFC 5273 - "Certificate Management over CMS (CMC): Transport Protocols" 🚚

3.1. Update Section 5 - "TCP-Based Protocol" 🔌

Replace paragraph 3 in Section 5 with the following.

CMC requires a registered port number to send and receive CMC messages over TCP. The title of this IP Protocol number is pkix-cmc. The value of this TCP port is 5318 ✨

Prior to this update, CMC did not have a registered port number and used an externally configured port from the Private Port range. Client implementations MAY want to continue to allow for this to occur. Servers SHOULD change to use the new port. It is expected that HTTP will continue to be the primary transport method used by CMC installations 🌸

3.2. New Section 6 - "IANA Considerations" 🦋

Insert this new section before the current Section 6.

IANA has assigned a TCP port number in the Registered Port Number range for the use of CMC.

Service name: pkix-cmc
Port Number: 5318
Transport protocol: TCP
Description: PKIX Certificate Management using CMS (CMC)
Reference: RFC 6402
Assignee: iesg@ietf.org
Contact: chair@ietf.org

4. Updates to RFC 5274 - "Certificate Management Message over CMS (CMC): Compliance Requirements" 📋

4.1. Update to Section 4.2 - "Controls" 🧩

Add the following lines to the end of Table 1.

The following table lists the name and level of support required for each control.

          +---------------------------+-----+------+-----+
          | Control                   | EE  | RA   | CA  |
          +---------------------------+-----+------+-----+
          | RA Identity Proof Witness | N/A | MUST | (2) |
          |                           |     |      |     |
          | Response Body             | (6) | (6)  | N/A |
          +---------------------------+-----+------+-----+

             Addition to Table 1: CMC Control Attributes

The following note should be added.

6. EE's SHOULD implement if designed to work with RAs and MUST implement if intended to be used in environments where RAs are used for identity validation or key generation. RAs SHOULD implement and validate responses for consistency.

5. IANA Considerations 🎀

This document contains a new IANA Considerations section to be added to [RFC5273] as part of this update.

6. Security Considerations 🛡️

No changes are made to the existing security considerations of RFC 5273 and RFC 5274. The security considerations for RFC 5272 have been slightly modified (Section 2.12).

7. References 📚

7.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008.
[RFC5273] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008.
[RFC5274] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

7.2. Informative References

[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC6403] Zieglar, L., Turner, S., and M. Peck, "Suite B Profile of Certificate Management over CMS", RFC 6403, November 2011.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, September 2005.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, June 2010.

Appendix A. ASN.1 Modules 🧩

A.1. 1988 ASN.1 Module

This section contains the updated ASN.1 module for [RFC5272]. This module replaces the module in Appendix A of that document. Although a 2008 ASN.1 module is provided, this remains the normative module as per the policy of the PKIX working group 📜

   EnrollmentMessageSyntax-2011-v88
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-enrollMsgSyntax-2011-88(76) }

   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 [RFC5280]
         GeneralName, CRLReason, ReasonFlags, GeneralNames
         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 [RFC5280]
         AlgorithmIdentifier, Extension, Name, CertificateSerialNumber,
         id-ad, id-kp
         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 [RFC4211]
       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 3629.

     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
    -- Request 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
    }

    --

    id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}


    --
    --  Allow for an End-Entity to request a change in name.
    --  This item is added to RegControlSet in CRMF.
    --

    id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36}

    ChangeSubjectName ::= SEQUENCE {
        subject             Name OPTIONAL,
        subjectAlt          GeneralNames OPTIONAL
    }
    -- (WITH COMPONENTS {..., subject PRESENT} |
    --  WITH COMPONENTS {..., subjectAlt PRESENT} )

    --
    --  Embedded response from a third party for processing
    --

    id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37}

    --
    --  Key purpose identifiers are in the Extended Key Usage extension
    --

    id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
    id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
    id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 28 }
    --
    --  Subject Information Access identifier
    --

    id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }

   END

A.2. 2008 ASN.1 Module ✨

okay so the 2008 version is the glow-up 💅 A brand new ASN.1 module got added as part of this update, bestie 🎀 It's basically the 2008 standards cleanup that was already done for [RFC5912], plus all the extra changes made for this document. Major main character energy 👑

EnrollmentMessageSyntax-2011-v08
    {iso(1) identified-organization(3) dod(6) internet(1)
    security(5) mechanisms(5) pkix(7) id-mod(0)
    id-mod-enrollMsgSyntax-2011-08(76)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
  EXPORTS ALL;
  IMPORTS

  AttributeSet{}, Extension{}, EXTENSION, ATTRIBUTE
  FROM PKIX-CommonTypes-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57)}

  AlgorithmIdentifier{}, DIGEST-ALGORITHM, KEY-WRAP, KEY-DERIVATION,
      MAC-ALGORITHM, SIGNATURE-ALGORITHM, PUBLIC-KEY
  FROM AlgorithmInformation-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0)
      id-mod-algorithmInformation-02(58)}

  CertificateSerialNumber, GeneralName, CRLReason, ReasonFlags,
      CertExtensions, GeneralNames
  FROM PKIX1Implicit-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}

  Name, id-pkix, PublicKeyAlgorithms, SignatureAlgorithms, id-ad, id-kp
  FROM PKIX1Explicit-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)}

  ContentInfo, IssuerAndSerialNumber, CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010
    { iso(1) member-body(2) us(840) rsadsi(113549)
       pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

  CertReqMsg, PKIPublicationInfo, CertTemplate
  FROM PKIXCRMF-2009
      {iso(1) identified-organization(3) dod(6) internet(1) security(5)
      mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005-02(55)}

  mda-sha1
  FROM PKIXAlgs-2009
       { iso(1) identified-organization(3) dod(6)
       internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-pkix1-algorithms2008-02(56)}

  kda-PBKDF2, maca-hMAC-SHA1
  FROM CryptographicMessageSyntaxAlgorithms-2009
      { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
      smime(16) modules(0) id-mod-cmsalg-2001-02(37) }

  mda-sha256
  FROM PKIX1-PSS-OAEP-Algorithms-2009
       { iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-rsa-pkalgs-02(54) } ;

  --  CMS content types defined in this document

  CMC-ContentTypes CONTENT-TYPE ::= { ct-PKIData | ct-PKIResponse, ... }

  --  Signature Algorithms defined in this document

  SignatureAlgs SIGNATURE-ALGORITHM ::= { sa-noSignature }

  --  CMS Unsigned Attributes

  CMC-UnsignedAtts ATTRIBUTE ::= { aa-cmc-unsignedData }

  --
  --

  id-cmc OBJECT IDENTIFIER ::= {id-pkix 7}   -- CMC controls
  id-cct OBJECT IDENTIFIER ::= {id-pkix 12}  -- CMC content types
  -- This is the content type for a request message in the protocol

  ct-PKIData CONTENT-TYPE ::=
      { TYPE PKIData IDENTIFIED BY id-cct-PKIData }
  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
  }

  BodyPartID ::= INTEGER(0..4294967295)

  TaggedAttribute ::= SEQUENCE {
      bodyPartID         BodyPartID,
      attrType           CMC-CONTROL.&id({Cmc-Control-Set}),
      attrValues         SET OF CMC-CONTROL.
                             &Type({Cmc-Control-Set}{@attrType})
  }

  Cmc-Control-Set CMC-CONTROL ::= {
      cmc-identityProof | cmc-dataReturn | cmc-regInfo |
      cmc-responseInfo | cmc-queryPending | cmc-popLinkRandom |
      cmc-popLinkWitness | cmc-identification | cmc-transactionId |
      cmc-senderNonce | cmc-recipientNonce | cmc-statusInfo |
      cmc-addExtensions | cmc-encryptedPOP | cmc-decryptedPOP |
      cmc-lraPOPWitness | cmc-getCert | cmc-getCRL |
      cmc-revokeRequest | cmc-confirmCertAcceptance |
      cmc-statusInfoV2 | cmc-trustedAnchors | cmc-authData |
      cmc-batchRequests | cmc-batchResponses | cmc-publishCert |
      cmc-modCertTemplate | cmc-controlProcessed |
      cmc-identityProofV2 | cmc-popLinkWitnessV2, ...,
      cmc-raIdentityWitness | cmc-responseBody }

  OTHER-REQUEST ::= TYPE-IDENTIFIER

  --  We do not define any other requests in this document.
  --     Examples might be attribute certification requests.

4.2. Controls ✨

okay bestie, this is where the CMC controls live 💅 each one gets an OID and a type, so the receiving side always knows what's inside. here's the first chunk of the ASN.1 🎀

  OtherRequests OTHER-REQUEST ::= {...}
  TaggedRequest ::= CHOICE {
      tcr               [0] TaggedCertificationRequest,
      crm               [1] CertReqMsg,
      orm               [2] SEQUENCE {
          bodyPartID            BodyPartID,
          requestMessageType    OTHER-REQUEST.&id({OtherRequests}),
          requestMessageValue   OTHER-REQUEST.&Type({OtherRequests}
                                    {@.requestMessageType})
      }
  }

  TaggedCertificationRequest ::= SEQUENCE {
      bodyPartID            BodyPartID,
      certificationRequest  CertificationRequest
  }

  AttributeList ATTRIBUTE ::= {at-extension-req, ...,
      at-cmc-changeSubjectName}

  CertificationRequest ::= SEQUENCE {
     certificationRequestInfo  SEQUENCE {
         version                   INTEGER,
         subject                   Name,
         subjectPublicKeyInfo      SEQUENCE {
             algorithm                 AlgorithmIdentifier{PUBLIC-KEY,
                                           {PublicKeyAlgorithms}},
             subjectPublicKey          BIT STRING
         },
         attributes                [0] IMPLICIT SET OF
                                       AttributeSet{{AttributeList}}
      },
      signatureAlgorithm        AlgorithmIdentifier
                                    {SIGNATURE-ALGORITHM,
                                        {SignatureAlgorithms}},
      signature                 BIT STRING
  }

  TaggedContentInfo ::= SEQUENCE {
      bodyPartID              BodyPartID,
      contentInfo             ContentInfo
  }

  OTHER-MSG ::= TYPE-IDENTIFIER

  --  No other messages currently defined

  OtherMsgSet OTHER-MSG ::= {...}
  OtherMsg ::= SEQUENCE {
      bodyPartID        BodyPartID,
      otherMsgType      OTHER-MSG.&id({OtherMsgSet}),
      otherMsgValue     OTHER-MSG.&Type({OtherMsgSet}{@otherMsgType}) }

  --  This defines the response message in the protocol

  ct-PKIResponse CONTENT-TYPE ::=
      { TYPE PKIResponse IDENTIFIED BY id-cct-PKIResponse }
  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
  }

  CMC-CONTROL ::= TYPE-IDENTIFIER

  -- The following controls have the type OCTET STRING

  cmc-identityProof CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-identityProof }
  id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}

  cmc-dataReturn CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-dataReturn }
  id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}

  cmc-regInfo CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-regInfo }
  id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}

  cmc-responseInfo CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-responseInfo }
  id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}

  cmc-queryPending CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-queryPending }
  id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}

  cmc-popLinkRandom CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-popLinkRandom }
  id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22}
  cmc-popLinkWitness CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-popLinkWitness }
  id-cmc-popLinkWitness OBJECT IDENTIFIER ::= {id-cmc 23}

  -- The following controls have the type UTF8String

  cmc-identification CMC-CONTROL ::=
      { UTF8String IDENTIFIED BY id-cmc-identification }
  id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}

  -- The following controls have the type INTEGER

  cmc-transactionId CMC-CONTROL ::=
      { INTEGER IDENTIFIED BY id-cmc-transactionId }
  id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}

  -- The following controls have the type OCTET STRING

  cmc-senderNonce CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-senderNonce }
  id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}

  cmc-recipientNonce CMC-CONTROL ::=
      { OCTET STRING IDENTIFIED BY id-cmc-recipientNonce }

  id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}

  -- Used to return status in a response

  cmc-statusInfo CMC-CONTROL ::=
      { CMCStatusInfo IDENTIFIED BY id-cmc-statusInfo }
  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)
  }

  CMCFailInfo ::= INTEGER {
      badAlg          (0),
      badMessageCheck (1),
      badRequest      (2),
      badTime         (3),
      badCertId       (4),
      unsuportedExt   (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

  cmc-addExtensions CMC-CONTROL ::=
      { AddExtensions IDENTIFIED BY id-cmc-addExtensions }
  id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}

  AddExtensions ::= SEQUENCE {
      pkiDataReference    BodyPartID,
      certReferences      SEQUENCE OF BodyPartID,
      extensions          SEQUENCE OF Extension{{CertExtensions}}
  }

  cmc-encryptedPOP CMC-CONTROL ::=
      { EncryptedPOP IDENTIFIED BY id-cmc-encryptedPOP }
  cmc-decryptedPOP CMC-CONTROL ::=
      { DecryptedPOP IDENTIFIED BY id-cmc-decryptedPOP }
  id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
  id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
  EncryptedPOP ::= SEQUENCE {
      request       TaggedRequest,
      cms             ContentInfo,
      thePOPAlgID     AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
      witnessAlgID    AlgorithmIdentifier{DIGEST-ALGORITHM,
                          {WitnessAlgs}},
      witness         OCTET STRING
  }

  POPAlgs MAC-ALGORITHM ::= {maca-hMAC-SHA1, ...}
  WitnessAlgs DIGEST-ALGORITHM ::= {mda-sha1, ...}

  DecryptedPOP ::= SEQUENCE {
      bodyPartID      BodyPartID,
      thePOPAlgID     AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
      thePOP          OCTET STRING
  }

  cmc-lraPOPWitness CMC-CONTROL ::=
      { LraPopWitness IDENTIFIED BY id-cmc-lraPOPWitness }

  id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}

  LraPopWitness ::= SEQUENCE {
      pkiDataBodyid   BodyPartID,
      bodyIds         SEQUENCE OF BodyPartID
  }

  --

  cmc-getCert CMC-CONTROL ::=
      { GetCert IDENTIFIED BY id-cmc-getCert }
  id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}

  GetCert ::= SEQUENCE {
      issuerName      GeneralName,
      serialNumber    INTEGER }


  cmc-getCRL CMC-CONTROL ::=
      { GetCRL IDENTIFIED BY id-cmc-getCRL }
  id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}

  GetCRL ::= SEQUENCE {
      issuerName    Name,
      cRLName       GeneralName OPTIONAL,
      time          GeneralizedTime OPTIONAL,
      reasons       ReasonFlags OPTIONAL }

  cmc-revokeRequest CMC-CONTROL ::=
      { RevokeRequest IDENTIFIED BY id-cmc-revokeRequest}
  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 }


  cmc-confirmCertAcceptance CMC-CONTROL ::=
      { CMCCertId IDENTIFIED BY id-cmc-confirmCertAcceptance }
  id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {id-cmc 24}

  CMCCertId ::= IssuerAndSerialNumber

  -- The following is used to request V3 extensions be added
  --     to a certificate

  at-extension-req ATTRIBUTE ::=
      { TYPE ExtensionReq IDENTIFIED BY id-ExtensionReq }
  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{{CertExtensions}}

  -- The following allows Diffie-Hellman Certification Request
  --     Messages to be well-formed

  sa-noSignature SIGNATURE-ALGORITHM ::= {
      IDENTIFIER id-alg-noSignature
      VALUE NoSignatureValue
      PARAMS TYPE NULL ARE required
      HASHES { mda-sha1 }
  }
  id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}

  NoSignatureValue ::= OCTET STRING

  --  Unauthenticated attribute to carry removable data.

  id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
      rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2)}

  aa-cmc-unsignedData ATTRIBUTE ::=
      { TYPE CMCUnsignedData IDENTIFIED BY id-aa-cmc-unsignedData }
  id-aa-cmc-unsignedData OBJECT IDENTIFIER ::= {id-aa 34}

  CMCUnsignedData ::= SEQUENCE {
      bodyPartPath        BodyPartPath,
      identifier          TYPE-IDENTIFIER.&id,
      content             TYPE-IDENTIFIER.&Type
  }

  --  Replaces CMC Status Info
  --

  cmc-statusInfoV2 CMC-CONTROL ::=
      { CMCStatusInfoV2 IDENTIFIED BY id-cmc-statusInfoV2 }
  id-cmc-statusInfoV2 OBJECT IDENTIFIER ::= {id-cmc 25}


  EXTENDED-FAILURE-INFO ::= TYPE-IDENTIFIER

  ExtendedFailures EXTENDED-FAILURE-INFO ::= {...}

  CMCStatusInfoV2 ::= SEQUENCE {
     cMCStatus             CMCStatus,
     bodyList              SEQUENCE SIZE (1..MAX) OF
                                    BodyPartReference,
     statusString          UTF8String OPTIONAL,
     otherInfo             CHOICE {
         failInfo               CMCFailInfo,
         pendInfo               PendInfo,
         extendedFailInfo       [1] SEQUENCE {
            failInfoOID            TYPE-IDENTIFIER.&id
                                       ({ExtendedFailures}),
            failInfoValue          TYPE-IDENTIFIER.&Type
                                       ({ExtendedFailures}
                                           {@.failInfoOID})
         }
      } OPTIONAL
  }

  BodyPartReference ::= CHOICE {
     bodyPartID           BodyPartID,
     bodyPartPath         BodyPartPath
  }

  BodyPartPath ::= SEQUENCE SIZE (1..MAX) OF BodyPartID
  --  Allow for distribution of trust anchors
  --

  cmc-trustedAnchors CMC-CONTROL ::=
      { PublishTrustAnchors IDENTIFIED BY id-cmc-trustedAnchors }
  id-cmc-trustedAnchors OBJECT IDENTIFIER ::= {id-cmc 26}

  PublishTrustAnchors ::= SEQUENCE {
      seqNumber      INTEGER,
      hashAlgorithm  AlgorithmIdentifier{DIGEST-ALGORITHM,
                         {HashAlgorithms}},
      anchorHashes   SEQUENCE OF OCTET STRING
  }

  HashAlgorithms DIGEST-ALGORITHM ::= {
     mda-sha1 | mda-sha256, ...
  }

  cmc-authData CMC-CONTROL ::=
      { AuthPublish IDENTIFIED BY id-cmc-authData }
  id-cmc-authData OBJECT IDENTIFIER ::= {id-cmc 27}

  AuthPublish ::= BodyPartID

  --   These two items use BodyPartList

  cmc-batchRequests CMC-CONTROL ::=
      { BodyPartList IDENTIFIED BY id-cmc-batchRequests }

  id-cmc-batchRequests OBJECT IDENTIFIER ::= {id-cmc 28}

  cmc-batchResponses CMC-CONTROL ::=
      { BodyPartList IDENTIFIED BY id-cmc-batchResponses }
  id-cmc-batchResponses OBJECT IDENTIFIER ::= {id-cmc 29}

  BodyPartList ::= SEQUENCE SIZE (1..MAX) OF BodyPartID

  cmc-publishCert CMC-CONTROL ::=
      { CMCPublicationInfo IDENTIFIED BY id-cmc-publishCert }
  id-cmc-publishCert OBJECT IDENTIFIER ::= {id-cmc 30}

that's the end of this chunk, bestie 🦋 more is coming, so keep your eyes peeled! 💜

Okay so we're still deep in the ASN.1 module, and it's giving structured. Every control gets its own OID under id-cmc, so the numbers are the star of the show 🔢💖

  CMCPublicationInfo ::= SEQUENCE {
      hashAlg        AlgorithmIdentifier{DIGEST-ALGORITHM,
                           {HashAlgorithms}},
      certHashes     SEQUENCE OF OCTET STRING,
      pubInfo        PKIPublicationInfo
  }
  cmc-modCertTemplate CMC-CONTROL ::=
      { ModCertTemplate IDENTIFIED BY id-cmc-modCertTemplate }

  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

  cmc-controlProcessed CMC-CONTROL ::=
      { ControlsProcessed IDENTIFIED BY id-cmc-controlProcessed }
  id-cmc-controlProcessed OBJECT IDENTIFIER ::= {id-cmc 32}

  ControlsProcessed ::= SEQUENCE {
      bodyList              SEQUENCE SIZE(1..MAX) OF BodyPartReference
  }

  --  Identity Proof control w/ algorithm agility

  cmc-identityProofV2 CMC-CONTROL ::=
      { IdentityProofV2 IDENTIFIED BY id-cmc-identityProofV2 }
  id-cmc-identityProofV2 OBJECT IDENTIFIER ::= { id-cmc 33 }

  IdentityProofV2 ::= SEQUENCE {
      proofAlgID       AlgorithmIdentifier{DIGEST-ALGORITHM,
                           {WitnessAlgs}},
      macAlgId         AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
      witness          OCTET STRING
  }

  cmc-popLinkWitnessV2 CMC-CONTROL ::=
      { PopLinkWitnessV2 IDENTIFIED BY id-cmc-popLinkWitnessV2 }
  id-cmc-popLinkWitnessV2 OBJECT IDENTIFIER ::= { id-cmc 34 }

  PopLinkWitnessV2 ::= SEQUENCE {
      keyGenAlgorithm   AlgorithmIdentifier{KEY-DERIVATION,
                            {KeyDevAlgs}},
      macAlgorithm      AlgorithmIdentifier{MAC-ALGORITHM, {POPAlgs}},
      witness           OCTET STRING
  }

  KeyDevAlgs KEY-DERIVATION ::= {kda-PBKDF2, ...}
  cmc-raIdentityWitness CMC-CONTROL ::=
     { BodyPartPath IDENTIFIED BY id-cmc-raIdentityWitness }

  id-cmc-raIdentityWitness OBJECT IDENTIFIER ::= {id-cmc 35}


  --
  --  Allow for an End-Entity to request a change in name.
  --  This item is added to RegControlSet in CRMF.
  --
  at-cmc-changeSubjectName ATTRIBUTE ::=
     { TYPE ChangeSubjectName IDENTIFIED BY id-cmc-changeSubjectName }

  id-cmc-changeSubjectName OBJECT IDENTIFIER ::= {id-cmc 36}

  ChangeSubjectName ::= SEQUENCE {
      subject             Name OPTIONAL,
      subjectAlt          GeneralNames OPTIONAL
  }
  (WITH COMPONENTS {..., subject PRESENT} |
   WITH COMPONENTS {..., subjectAlt PRESENT} )

  --
  --  Embedded response from a third party for processing
  --

  cmc-responseBody CMC-CONTROL ::= {
     BodyPartPath IDENTIFIED BY id-cmc-responseBody
  }

  id-cmc-responseBody OBJECT IDENTIFIER ::= {id-cmc 37}

  --
  --  Key purpose identifiers are in the Extended Key Usage extension
  --

  id-kp-cmcCA OBJECT IDENTIFIER ::= { id-kp 27 }
  id-kp-cmcRA OBJECT IDENTIFIER ::= { id-kp 28 }
  id-kp-cmcArchive OBJECT IDENTIFIER ::= { id-kp 29 }

  --
  --  Subject Information Access identifier
  --

  id-ad-cmc OBJECT IDENTIFIER ::= { id-ad 12 }

END

Author's Address 💌

   Jim Schaad
   Soaring Hawk Consulting

   EMail: jimsch@augustcellars.com

📦 where this page comes from

ietf: rfc6402 2011-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms

RFC 6402

RFC 6402: Certificate Management over CMS (CMC) Updates ✨

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction ✨

1.1. Requirements Terminology

1.2. Abbreviations

2. Updates to RFC 5272 - "Certificate Management over CMS (CMC)" 🦋

2.1. New Section 1.3 - "Updates Made by RFC 6402"

2.2. Update Section 6 - "Controls"

2.3. Replace Section 6.3 - "Linking Identity and POP Information"

2.4. Replace Section 6.3.3 - "Renewal and Rekey Messages"

2.5. New Section 6.20 - "RA Identity Proof Witness Control" ✨

2.6. New Section 6.21 - "Response Body Control" 🌈

2.7. New Section 7 - "Other Attributes" 🎀

2.8. New Section 7.1 - "Change Subject Name Attribute" 🦋

2.9. New Section 9 - "Certificate Requirements" 🔐

2.10. New Section 9.1 - "Extended Key Usage" 💜

2.11. New Section 9.2 - "Subject Information Access" 🧚

2.12. Update Section 8 - "Security Considerations" 🔐

3. Updates to RFC 5273 - "Certificate Management over CMS (CMC): Transport Protocols" 🚚

3.1. Update Section 5 - "TCP-Based Protocol" 🔌

3.2. New Section 6 - "IANA Considerations" 🦋

4. Updates to RFC 5274 - "Certificate Management Message over CMS (CMC): Compliance Requirements" 📋

4.1. Update to Section 4.2 - "Controls" 🧩

5. IANA Considerations 🎀

6. Security Considerations 🛡️

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. ASN.1 Modules 🧩

A.1. 1988 ASN.1 Module

A.2. 2008 ASN.1 Module ✨

4.2. Controls ✨

Author's Address 💌