]> Siemens

Germany hannes.tschofenig@gmx.net

Siemens

Werner-von-Siemens-Strasse 1 Munich 80333 Germany hendrik.brockhaus@siemens.com https://www.siemens.com

AKAYLA, Inc.

joe@akayla.com

sn3rd

sean@sn3rd.com

sec LAMPS Working Group Remote Attestation Certificate Signing Request Certificate Management Protocol (CMP) Enrollment over Secure Transport (EST) Certificate Management over CMS (CMC) When an end entity includes attestation statements in a Certificate Signing Request (CSR), this document is specifically concerned with establishing the freshness of Evidence statements among that attestation data. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC).

Introduction The management of certificates, encompassing issuance, CA certificate provisioning, renewal, and revocation, has been streamlined through standardized protocols. The Certificate Management Protocol (CMP) defines messages for X.509v3 certificate creation and management. CMP facilitates interactions between end entities and PKI management entities, such as Registration Authorities (RAs) and Certification Authorities (CAs). For Certificate Signing Requests (CSRs), CMP primarily utilizes the Certificate Request Message Format (CRMF) but also supports PKCS#10 . Enrollment over Secure Transport (EST) (, ) is another certificate management protocol that provides a subset of CMP's features, primarily using PKCS#10 for CSRs. Certificate Management over CMS (CMC) is a certificate management protocol using the Cryptographic Message Syntax (CMS). When an end entity requests a certificate from a Certification Authority (CA), it may need to assert credible claims about the protections of the corresponding private key, such as the use of a hardware security module or the protective capabilities provided by the hardware, as well as claims about the platform itself. To include these claims in a CSR, defines AttestationStatement and AttestationBundle structures. These structures specify how attestation statements, including Evidence produced by an Attester, are encoded for inclusion in CRMF or PKCS#10, along with any necessary certificates for their validation. This specification does not define freshness for all possible attestation statement types carried by . Its focus is specifically the freshness of Evidence generated by an Attester. For a Verifier or Relying Party to ensure the freshness of the Evidence, knowing the exact time of its production is crucial. Current attestation technologies, like and , often employ nonces to ensure the freshness of Evidence. Further details on ensuring Evidence freshness can be found in . In this document, the freshness of Evidence refers to the incorporation of the nonce into the claims carried by the Evidence so that the Verifier can determine that the Evidence was generated for the current appraisal transaction. It does not mean that all other claims in the Evidence are newly collected or updated for each exchange. For example, a measurement claim describing a second-stage bootloader would normally change only when that bootloader software is updated, not merely because a fresh nonce was requested. defines an AttestationBundle that can contain one or more AttestationStatement values. For each Evidence statement whose freshness is to be established using a nonce, the end entity may wish to request a separate nonce. Since an end entity requires one or more nonces from one or more Verifiers via the RA/CA, an additional roundtrip is necessary. However, a CSR is a one-shot message. Therefore, CMP, EST, and CMC enable the end entity to request information from the RA/CA before submitting a certification request conveniently. Once a nonce is obtained, the end entity invokes the API on an Attester, providing the nonce as an input parameter. The Attester then returns Evidence, which is embedded into an AttestationStatement in the CSR and potentially, together with further attestation statements, submitted back to the RA/CA in a certification request message. illustrates this interaction:

• One or more nonces are requested in step (0) and obtained in step (1) using the extension to CMP/EST/CMC defined in this document.
• The CSR attribute or extension defined in conveys an AttestationBundle containing one or more attestation statements to the RA/CA in step (2).
• One or more Verifiers process the received attestation statements that require appraisal and return the Attestation Result(s) to the Relying Party. The CA uses the Attestation Result(s) with the Appraisal Policy and other information to create the requested certificate. The certificate is returned to the End Entity in step (3).

Architecture with Background Check Model. | | | | | | | | | Request Nonce(s)(0) | | |------------------------>| | | | Request Nonce(s) | | |----------------------->| | | Nonce(s) | | |<-----------------------| | Nonce(s) (1) | | |<------------------------| | | | | | Attested CSR (2) | | |------------------------>| | | | Attestation(s) | | |----------------------->| | | Attestation Result(s) | | |<-----------------------| | Certificate (3) | | |<------------------------| | | | | | | | ]]>

The functionality described in this document is divided into three sections:

• describes how to convey the nonce using CMP.
• describes the equivalent functionality for EST.
• describes the equivalent functionality for CMC.

Terminology and Requirements Language 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 RFC 2119 . The terms Attester, Relying Party, Verifier and Evidence are defined in . The terms end entity, certification authority (CA), and registration authority (RA) are defined in . We use the terms Certificate Signing Request (CSR) and certification request interchangeably.

Conveying a Nonce in CMP defines the general request message (genm) and general response (genp). The NonceRequest payload of the genm message, sent by the end entity to request a nonce, optionally includes details on the required length of the nonce from the Attester. The NonceResponse payload of the genp message, sent by the CA/RA in response to the request, contains the nonce itself. id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 } NonceRequestValue ::= SEQUENCE SIZE (1..MAX) OF NonceRequest NonceRequest ::= SEQUENCE { len INTEGER OPTIONAL, -- indicates the required length of the requested nonce type ATTESTATION-STATEMENT.&id({AttestationStatementSet}) OPTIONAL, -- indicates which attestation statement type to request a nonce for hint UTF8String OPTIONAL -- indicates which Verifier to request a nonce from } id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 } NonceResponseValue ::= SEQUENCE SIZE (1..MAX) OF NonceResponse NonceResponse ::= SEQUENCE { nonce OCTET STRING, -- contains the nonce of length len -- provided by the Verifier indicated with hint expiry INTEGER OPTIONAL, -- indicates how long in seconds the Verifier considers -- the nonce valid type ATTESTATION-STATEMENT.&id({AttestationStatementSet}) OPTIONAL, -- indicates which attestation statement type to request a nonce for hint UTF8String OPTIONAL -- indicates which Verifier to request a nonce from } ]]> The end entity may request one or more nonces for different Verifiers. The ATTESTATION-STATEMENT type is defined in . It identifies the attestation statement format to which a nonce request applies. The hint field defined in this specification additionally allows the end entity to indicate which Verifier should be contacted to obtain a nonce. If a NonceRequest structure does not contain type or hint, the RA/CA MAY generate a nonce itself and include it in the response. The use of the general request/response message exchange introduces an additional round trip for transmitting nonce(s) from the CA/RA to the end entity (and subsequently to the Attester within the end entity). The end entity MUST construct an id-it-nonceRequest message to prompt the RA/CA to send one or more nonces in response. The message may contain one or more NonceRequest structures, at a maximum one per attestation statement the end entity wishes to provide in a CSR. If a NonceRequest structure does neither contain a type nor a hint, the RA/CA MAY generate a nonce itself and provide it in the respective NonceResponse structure. If an RA/CA is not able to provide a requested nonce, it MUST provide an empty OCTET STRING in the respective NonceResponse structure. NonceRequest and NonceResponse structures can contain both a type field and a hint field. The AttestationStatement structures carried later in the CSR contain the corresponding type field. In terms of type and hint content, the order in which the NonceRequest structures were sent in the request message MUST match the order of the NonceResponse structures in the response message and the AttestationStatement values in the CSR later. This matching ensures that the RA/CA can associate each attestation statement with the corresponding nonce and, where a hint is present, contact the intended Verifier. When receiving nonces from the RA/CA in an id-it-nonceResponse message, the end entity MUST use them to request fresh attestation information, typically Evidence from the respective Attester, as optionally indicated by type and hint. If a nonce is provided in a NonceResponse structure without indicating any type or hint, it can be used for all attestation statements requiring a nonce. An attestation statement generated using a nonce provided with an expiry value will be accepted by the Verifier as valid until the respective expiry time has elapsed. It is expected that the respective messages are delivered in a timely manner. The interaction is illustrated in .

CMP Exchange with Nonce and Attestation Statements. Verify request Generate nonce(s)* Create response <------ id-it-NonceResponse ----- (nonce(s), expiry) Generate key pair Generate attestation(s)* Generate certification request message ------- certification request ---> +attestation(s) including nonce) Verify request Verify attestation(s)* Check for replay* Issue certificate Create response <------ certification response --- Handle response Store certificate *: These steps require interactions with the Attester (on the EE side) and with the Verifier (on the RA/CA side). ]]>

If HTTP is used to transfer the NonceRequest and NonceResponse messages, the OPTIONAL <operation> path segment defined in MAY be used.

Operation	Operation Path	Details
Get Attestation Freshness Nonce	getnonce

If CoAP is used for transferring NonceRequest and NonceResponse messages, the OPTIONAL <operation> path segment defined in MAY be used.

Operation	Operation Path	Details
Get Attestation Freshness Nonce	nonce

Conveying a Nonce in EST The EST client requests one or more nonces for its Attester from the EST server. This function typically follows the request for CA certificates and precedes other EST operations. The EST server MUST support the path-prefix of "/.well-known/" as defined in and the registered name of "est". Therefore, a valid EST server URI path begins with "https://www.example.com/.well-known/est". Each EST operation is indicated by a path-suffix that specifies the intended operation. The following operation is defined by this specification:

Operation	Operation Path	Details
Retrieval of a nonce	/nonce

The operation path is appended to the path-prefix to form the URI used with HTTP GET or POST to perform the desired EST operation. An example of a valid URI absolute path for the "/nonce" operation is "/.well-known/est/nonce".

Request Methods An EST client uses either a GET or a POST method, depending on whether additional parameters need to be conveyed:

• A GET request MUST be used when the EST client does not want to convey extra parameters.
• A POST request MUST be used when parameters, such as nonce length or a hint about the verification service, are included in the request.

Request Payload (POST) The payload in a POST request MUST be of content-type "application/json" and MUST contain an array of JSON objects with the optional members "len", "type", and "hint".

• The optional "len" member indicates the length of the requested nonce value in bytes.
• The optional "type" member contains an AttestationStatement OID (dotted-decimal string) as defined in .
• The optional "hint" member contains an FQDN or URI identifying the Verifier.

The order of objects in the JSON array is significant and MUST be preserved by the server. The response array MUST contain the same number of elements in the same order so clients can correlate requests and responses by array index.

Example GET

Example POST To retrieve one or more nonces while optionally specifying the length, type, and/or hint:

Server Response If successful, the EST server MUST respond with an HTTP 200 status code and a content-type of "application/json", containing an array of JSON objects with the "nonce" member. The "expiry" member is optional and indicates the absolute expiry time of the nonce encoded as an RFC 3339 timestamp string. The optional "type" and "hint" members MAY be copied from the request to aid correlation. Note: CMP encodes "expiry" as an INTEGER representing seconds of validity. EST encodes "expiry" as an absolute timestamp. Below is an example response: The EST server MAY request HTTP-based client authentication, as explained in Section 3.2.3 of . Open Issue: Should a specific content type be registered for use with EST over CoAP, where the nonce and expiry fields are encoded in a CBOR structure?

Conveying a Nonce in CMC CMC defines Simple and Full PKI Requests for the client to use to request a certificate. Full PKI Requests provide the client with more functionality through the use of Controls, defined in Section 6 of . Currently, the client sends an initial request containing a certification request (CRMF, PKCS#10, or other). To allow the client to request a nonce prior to sending a certification request, this section defines the nonceReq and nonceResp. Generally a Full PKI Request is encapsulated in a SignedData or AuthenticatedData with an encapsulated content type of 'id-cct-PKIData'. To accommodate a generic request for a nonce, the Client/Server SHOULD use the Data content type; id-data, to transmit the nonceReq and nonceResp controls. The syntax for the controls uses the same syntax as the CMP information types defined in . The NonceRequest control is identified by: The NonceResponse control is identified by:

Generic Nonce Request Message Flow The client sends id-cmc-nonceReq structure to the server. Upon receiving and processing the request, the server responds with id-cmc-nonceResp. Once this round-trip transaction is complete, the client will include the nonce in either a Simple or Full PKI Request. Client to Server: Server to Client:

Nonce Processing Guidelines When the RA/CA is requested to provide a nonce to an end entity, it interacts with the Verifier. According to the IETF RATS architecture , the Verifier is responsible for validating Evidence about an Attester and generating Attestation Results for use by a Relying Party. The Verifier also acts as the source of the nonce to prevent replay attacks. The nonce value MUST contain a random byte sequence with at least 64 bits of entropy. The RA/CA MUST ensure that nonces are unique and MUST NOT be reused. The length of the nonce depends on the remote attestation technology in use, as specific nonce lengths may be required by the end entity. This specification assumes that the RA/CA possesses knowledge, either out-of-band or through the len field in the NonceRequest, regarding the required nonce length for the attestation technology. Nonces of incorrect length will cause the remote attestation protocol to fail. For instance, the PSA attestation token supports nonce lengths of 32, 48, and 64 bytes. Other attestation technologies employ nonces of similar lengths. If a specific length was requested, the RA/CA MUST provide a nonce of that size. The end entity MUST use the received nonce if the remote attestation supports the requested length. If necessary, the end entity MAY adjust the length of the nonce by truncating or padding it accordingly. While this specification does not address the semantics of the attestation API or the underlying software/hardware architecture, the API returns Evidence from the Attester in a format specific to the attestation technology used and specified by the type and hint. The returned Evidence is encapsulated in an AttestationStatement within the AttestationBundle carried in the CSR, as defined in . The software generating the CSR treats the attestation statement payload as an opaque blob and does not interpret its format. It's crucial to note that the nonce is included in the Evidence, either implicitly or explicitly, and MUST NOT be conveyed in CSR structures outside of the attestation payload. The processing of CSRs containing attestation statements is detailed in . Importantly, certificates issued based on this process do not contain the nonce, as specified in .

IANA Considerations This document adds new entries to the "CMP Well-Known URI Path Segments" registry defined in .

Path Segment	Description	Reference
getnonce	Get Attestation Freshness Nonce over HTTP
nonce	Get Attestation Freshness Nonce over CoAP

Open issue: register path segments for EST. IANA is also requested to register the following ASN.1 module OID in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0). This OID is defined in .

Decimal	Description	References
TBDMOD	id-mod-att-fresh-req	This-RFC

Security Considerations This specification details the process of obtaining a nonce via CMP, EST, and CMC, assuming that the nonce does not require confidentiality protection while maintaining the security properties of the remote attestation protocol. defines the IETF remote attestation architecture and extensively discusses nonce-based freshness. Section 8.4 of specifies requirements for the randomness and privacy of nonce generation when used with the Entity Attestation Token (EAT). These requirements, which are also adopted by attestation technologies like the PSA attestation token , provide general utility:

• The nonce MUST have at least 64 bits of entropy.
• To prevent disclosure of privacy-sensitive information, it should be derived using a salt from a genuinely random number generator or another reliable source of randomness.

Each attestation technology specification offers guidance on replay protection using nonces and other techniques. Specific recommendations are deferred to these individual specifications in this document. Regarding the use of attestation statements in a CSR, the security considerations outlined in are pertinent to this specification.

Acknowledgments We would like to thank Russ Housley, Thomas Fossati, Watson Ladd, Ionut Mihalcea, Carl Wallace, and Michael StJohns for their review comments.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. [STANDARDS-TRACK] This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The EST (Enrollment over Secure Transport) protocol defines the Well-Known URI (Uniform Resource Identifier) -- /.well-known/est -- along with a number of other path components that clients use for PKI (Public Key Infrastructure) services, namely certificate enrollment (e.g., /simpleenroll). This document defines a number of other PKI services as additional path components -- specifically, firmware and trust anchors as well as symmetric, asymmetric, and encrypted keys. This document also specifies the PAL (Package Availability List), which is an XML (Extensible Markup Language) file or JSON (JavaScript Object Notation) object that clients use to retrieve packages available and authorized for them. This document extends the EST server path components to provide these additional services. This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes. In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry. This document specifies the use of the Constrained Application Protocol (CoAP) as a transfer mechanism for the Certificate Management Protocol (CMP). CMP defines the interaction between various PKI entities for the purpose of certificate creation and management. CoAP is an HTTP-like client-server protocol used by various constrained devices in the Internet of Things space. This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. This document describes how to layer the Certificate Management Protocol (CMP) over HTTP. It includes the updates to RFC 6712 specified in Section 3 of RFC 9480; these updates introduce CMP URIs using a well-known prefix. It obsoletes RFC 6712; and, together with RFC 9810, it also obsoletes RFC 9480. Cryptic Forest Software Siemens Fraunhofer SIT Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. AKAYLA, Inc. sn3rd This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: ITU-T ITU-T Informative References This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Arm's Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, along with open-source reference implementations, aimed at helping device makers and chip manufacturers integrate best-practice security into their products. Devices that comply with PSA can generate attestation tokens as described in this document, which serve as the foundation for various protocols, including secure provisioning and network access control. This document specifies the structure and semantics of the PSA attestation token. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes the claims used in an attestation token generated by PSA-compliant systems, how these claims are serialized for transmission, and how they are cryptographically protected. This Informational document is published as an Independent Submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. Trusted Computing Group

ASN.1 Module The following module adheres to ASN.1 specifications and . att-fresh-req { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-att-fresh-req (TBDMOD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS id-it, InfoTypeAndValue{} FROM PKIXCMP-2023 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp2023-02(116) } ATTESTATION-STATEMENT, AttestationStatementSet FROM CSR-ATTESTATION-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix-attest-01(TBD-CSR-ATTESTATION-2025) } -- RFC Editor: The value for id-mod-pkix-attest-01 must be set as soon -- as it is assigned by I-D.ietf-lamps-csr-attestation CMC-CONTROL FROM EnrollmentMessageSyntax-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-enrollMsgSyntax-2025(TBD1) } ; -- NonceRequest and NonceResponse messages id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 } NonceRequestValue ::= SEQUENCE SIZE (1..MAX) OF NonceRequest NonceRequest ::= SEQUENCE { len INTEGER OPTIONAL, -- indicates the required length of the requested nonce type ATTESTATION-STATEMENT.&id({AttestationStatementSet}) OPTIONAL, -- indicates which attestation statement type to request a nonce for hint UTF8String OPTIONAL -- indicates which Verifier to request a nonce from } id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 } NonceResponseValue ::= SEQUENCE SIZE (1..MAX) OF NonceResponse NonceResponse ::= SEQUENCE { nonce OCTET STRING, -- contains the nonce of length len -- provided by the Verifier indicated with hint expiry INTEGER OPTIONAL, -- indicates how long in seconds the Verifier considers -- the nonce valid type ATTESTATION-STATEMENT.&id({AttestationStatementSet}) OPTIONAL, -- indicates which attestation statement type to request a nonce for hint UTF8String OPTIONAL -- indicates which Verifier to request a nonce from } id-cmc-nonceReq ::= { id-it TBD1 } cmc-nonceReq CMC-CONTROL ::= { NonceRequest IDENTIFIED BY id-cmc-nonceReq } id-cmc-nonceResp ::= { id-it TBD2 } cmc-nonceResp CMC-CONTROL ::= { NonceResponse IDENTIFIED BY id-cmc-nonceResp } END ]]>