]> Siemens

Werner-von-Siemens-Strasse 1 Munich 80333 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), the freshness of the conveyed Evidence often needs to be established. A common mechanism is a nonce that is obtained from a Relying Party or Verifier and included by the Attester in the Evidence. This document specifies how an end entity requests such an attestation freshness nonce from an RA/CA when using certificate lifecycle management protocols. It defines message formats and protocol bindings for the conveyance of nonce request and response messages in the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC), including optional type-specific information needed to produce fresh Evidence for inclusion in a CSR.

Introduction specifies how Attestation Evidence, as defined in the RATS Architecture , can be conveyed in a Certificate Signing Request (CSR) using PKCS#10 or CRMF . The RATS Architecture calls for establishing the freshness of Evidence, see . A common method for establishing freshness is the use of nonces. Such nonces must be provided by the Relying Party or Verifier and included in the Evidence by the Attester. When the CSR is conveyed using a certificate lifecycle management protocol, such as CMP , EST , or CMC , the end entity can request the required nonce from the RA/CA in a prior message exchange and pass it to the Attester to produce fresh Evidence. This document describes how an end entity can request a nonce from an RA/CA using CMP, EST, and CMC. The following topics are out of scope for this document and either covered in other specifications or are implementation or deployment details:

• whether a CSR requires one or more nonces,
• how the end entity forwards the nonce to the Attester,
• whether the RA/CA or the Verifier generates the nonce and how those entities communicate with each other, and
• other methods for establishing freshness.

In this context, the end entity is a device that contains one or more Attesters, and the RA/CA acts as a Relying Party that communicates with one or more Verifiers.

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 . This document uses RATS and PKIX terminology as described in . It also uses terminology from the applicable certificate lifecycle management protocols: CMP, EST, and CMC.

Architecture and Message Formats According to , a CSR can contain multiple AttestationStatements and multiple certificates for validating those AttestationStatements. This document describes how an end entity can use CMP, EST, or CMC to request a nonce from the RA/CA for a specific type of Evidence to be included in the CSR. The end entity sends a nonce request message with the following fields:

• len: In this OPTIONAL field, the end entity can specify the desired length of the requested nonce in bytes as a value between 8 and 64.
• type: In this OPTIONAL field, the end entity can specify the type of the reqInfo structure.
• reqInfo: If type is set, this OPTIONAL field MUST contain the type-specific content that the RA/CA requires to generate respInfo. If type is not set, reqInfo MUST also be omitted.

The RA/CA can return the requested nonce in a nonce response message together with information specific to the generation of the Evidence. The nonce response message has the following fields:

• nonce: This field MUST contain the nonce if the RA/CA is able and willing to provide it. If a specific length was requested, the RA/CA SHOULD provide a nonce of that size. If the RA/CA doesn't need a freshness proof, the nonce MUST be an empty or zero-length string.
• expiry: In this OPTIONAL field, the RA/CA can specify the validity period of the nonce in seconds as an integer value. The nonce can be used during this period; the response therefore needs to be conveyed promptly.
• type: In this OPTIONAL field, the RA/CA can specify the type of the respInfo structure. The type in the nonce response message is defined by the type in the nonce request message.
• respInfo: If type is set, this OPTIONAL field MUST contain the type-specific content requested by the end entity for generating the Evidence. If type is not set, respInfo MUST also be omitted.

This document does not further specify the content of the reqInfo and respInfo structures; those structures must be defined elsewhere. Each definition must assign an object identifier and specify the exact content of the corresponding field. The definition of the reqInfo structure must also specify the type of the expected respInfo structure. The message structure and the reqInfo or respInfo structures can use different encodings. For example, an ASN.1 message can contain reqInfo or respInfo encoded as JSON, if necessary. The reqInfo structure may be used to provide the required information to the Relying Party to route the nonce request to the appropriate Verifier when multiple verifiers are supported. The respInfo structure may be used to convey Generic Information Elements () such as Attesting Environment IDs and Claim Selection. The generic message flow between the end entity and the RA/CA is shown in .

Message Flow in Background Check Model | | | request nonce | | |-------------------------->| | | | request nonce (optional) | | |--------------------------->| | | nonce (optional) | | |<---------------------------| | nonce | | |<--------------------------| | | attested CSR | | |-------------------------->| | | | Evidence | | |--------------------------->| | | Attestation Result | | |<---------------------------| | certificate | | |<--------------------------| | | | | ]]>

The nonce request and nonce response messages allow the end entity to request only one nonce and one respInfo structure from the RA/CA. If the end entity wants to include multiple Evidence statements in a CSR, it can use the composite Attester model described in and , i.e., together with a conceptual message wrapper (CMW) structure, as described in . The lead Attester should then pass the nonce to the sub-Attesters. Based on Figure 2 of , shows an example of how a nonce can be distributed among several Attesters in an end entity. If multiple respInfo structures are required, the reqInfo and respInfo structures can also use a conceptual message wrapper (CMW).

Class 1 Composite Attester | Attester B | | | | | v | |<------------| | | | | | .-------------. | Evidence B '------------' | | | | | attesting | | | | | '--------->| environment | | nonce .------------. | | | '-------------' |------------>| Attester C | | | | Attester A |<------------| | | | '-----------lead Attester----------' Evidence C '------------' | | | '------------------------------end entity-------------------------' ]]>

The interaction between the end entity and the RA/CA is illustrated in .

Exchange with Nonce and Evidence. Verify request Generate or obtain nonce* Create response <---- nonce response ------ (nonce, expiry) Generate key pair Generate Evidence(s)* Generate certification request message -- certification request --> +Evidence(s) including nonce Verify request Verify Evidence(s)* Check freshness/replay* Issue certificate Create response Handle response <-- certification response -- Store certificate *: These steps can require interactions with the Attester (on the end entity side) and with the Verifier (on the RA/CA side). ]]>

The following sections define the generic data structures for nonce request and nonce response message content. CMP and CMC use ASN.1, while EST uses JSON and CBOR, both defined CDDL.

ASN.1 Representation This section defines nonce request and nonce response message content as ASN.1 types for use in CMP, see , and CMC, see . Nonce values conveyed as ASN.1 OCTET STRING values in CMP and CMC are between 8 and 64 bytes in length. A zero-length OCTET STRING indicates that the RA/CA does not require proof of freshness for the upcoming certificate request.

CDDL Representation This section provides a CDDL definition for the JSON and CBOR nonce request and nonce response message content. The nonce-request rule applies to both JSON and CBOR. The nonce-response-json and nonce-response-cbor rules define the encoding-specific representation of the nonce value. For JSON, the base64url-nonce rule captures the allowed character set and encoded length; the decoded nonce length requirements are specified in .

Use with CMP The nonce request and nonce response message content is conveyed as ASN.1 content, see , in a general message (genm) and general response (genp) , respectively. When CMP is transferred over HTTP, the OPTIONAL <operation> path segment defined in MAY be used for the nonce request message.

Operation	Operation path	Details
Get Attestation Freshness Nonce	getnonce

When CMP is transferred over CoAP, the OPTIONAL <operation> path segment defined in MAY be used for the nonce request message.

Operation	Operation path	Details
Get Attestation Freshness Nonce	nonce

In the event of a possible error or if the RA/CA is unable or unwilling to deliver the requested nonce, CMP offers several ways to indicate this. Which variant fits depends on the circumstances.

• Respond with an error message containing the PKIFailureInfo bit as defined by .
• If HTTP or CoAP is used for transferring the general message, return a status code on transfer level as described in or .

Use with EST The nonce request and nonce response message content is conveyed as JSON or CBOR according to the CDDL definition, see , between end entity (EST client) and RA/CA (EST server). A compliant EST server MUST provide an EST endpoint with the path-segment /nonce for this operation.

Operation	Operation path	Details
Request of a nonce	/nonce

Depending on whether additional parameters are to be transferred, the client uses either the GET or POST method:

• The GET method MUST be used if no optional content is to be transferred
• The POST method MUST be used if nonce request message content encoded in JSON or CBOR is to be transferred.

EST over HTTPS If the nonce request and nonce response message content is transferred over HTTPS, the specification in applies. The JSON nonce request object is formally described by the nonce-request CDDL rule in . The JSON nonce response object is formally described by the nonce-response-json CDDL rule in . The JSON structure has the following members:

• The OPTIONAL "len" and "expiry" members, if present, MUST be unsigned integers.
• The "nonce" member MUST either contain a zero-length string or the nonce value between 8 and 64 bytes in length conveyed as a JSON string containing the unpadded base64url encoding, as specified in . Such encodings are between 11 and 86 characters in length.
• The OPTIONAL "type" member, if present, MUST be a text string containing the object identifier as a dotted-decimal OID.
• The OPTIONAL "reqInfo" and "respInfo" members MUST only be included if the corresponding "type" member contains an OID. Their contents are defined by that OID.

If the nonce request message was successful, the EST server MUST respond with an HTTP 200 status code and the nonce response message content MUST be encoded as a JSON object. The HTTP 200 status code MUST also be used if the nonce is an empty string. In the event of a possible error, the EST server MUST respond with an HTTP status code 400 (Bad Request) and MUST omit the nonce response message content. If the nonce request message has been made correctly, but the EST server is unable or unwilling to deliver the requested nonce, it MUST respond with an HTTP 503 (Service Unavailable). The EST server MAY request HTTP-based client authentication as described in . The following media types MUST be used as the Content-Type of the POST request and the response.

Message type (per operation)	Media type(s)	Reference
NonceRequest	N/A (for GET) or application/est-attestation-freshness+json (for POST)
NonceResponse	application/est-attestation-freshness+json

The following example shows a nonce request and nonce response message exchange without transmitting optional parameters in the request: The following example shows a nonce request and nonce response message exchange transmitting optional parameters in the request:

EST over Secure CoAP If the nonce request and nonce response message content is transferred via secure CoAP, the specification in applies. The CBOR nonce request object is formally described by the nonce-request CDDL rule in . The CBOR nonce response object is formally described by the nonce-response-cbor CDDL rule in . The CBOR structure has the following members:

• All map keys are text strings.
• The "nonce" member MUST either contain a zero-length octet string or the nonce value between 8 and 64 bytes in length conveyed as a CBOR byte string.
• The OPTIONAL dotted-decimal-oid "type" member denotes a text string containing an object identifier in dotted-decimal notation.
• The OPTIONAL "reqInfo" and "respInfo" members contain type-specific CBOR values. They MUST only be included if the corresponding "type" member contains an OID. Their CBOR encoding is defined by that OID.

If the nonce request was successful, the EST server MUST respond to a GET request with a code 2.05 and to a POST request with code 2.04 and the nonce response message content MUST be encoded as a CBOR object. The code 2.05 or code 2.04 MUST also be used if the nonce is a zero-length byte string. In the event of a possible error, the EST server MUST respond with a code 4.00 (Bad Request) and MUST omit the nonce response message content. If the nonce request has been made correctly, but the EST server is unable or unwilling to deliver the requested nonce, it MUST respond with a code 5.03 (Service Unavailable). The following media type MUST be used for nonce request and nonce response message content. The corresponding CoAP Content-Format value is used in the CoAP Content-Format and Accept options as specified in .

Message type (per operation)	Media type	Reference
NonceRequest NonceResponse	application/est-attestation-freshness+cbor

Use with CMC The nonce request and nonce response message content is conveyed as ASN.1, see , as CMC Controls in a Full PKI Request, see . The received nonce can be used for a CSR to be transferred in a Simple or Full PKI request. To transfer the controls, the content type id-data SHOULD be used. The following example shows the nonce request and nonce response message content: } ContentInfo.contentType = id-data ContentInfo.content controlSequence {101, id-cmc-senderNonce, 10005} {102, id-cmc-recipientNonce, 10001} {103, id-cmc-nonceResp, } ]]> In the event of an error, or if the server is unable to provide the requested nonce, the CMC Server MAY return status information about the request using either an Extended CMC Status Info Control or a CMC Status Info Control, as defined in .

IANA Considerations

CMP

Well-Known URI Path Segment IANA is requested to add the following entry to the "CMP Well-Known URI Path Segments" registry defined in :

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

Information Type IANA is requested to register the following object identifier in the "SMI Security for PKIX CMP Information Types" registry (1.3.6.1.5.5.7.4):

Decimal	Description	Reference
TBD1	id-it-nonceRequest	This-RFC
TBD2	id-it-nonceResponse	This-RFC

EST IANA is requested to register the following media types in the "Media Types" registry :

JSON Media Type

Type name:

application

Subtype name:

est-attestation-freshness+json

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary

Security considerations:

See of this RFC.

Interoperability considerations:

The same media type is used for EST attestation freshness nonce requests and nonce responses. The protocol context determines whether the JSON payload is a request or response.

Published specification:

This RFC.

Applications that use this media type:

EST implementations using attestation freshness nonces over HTTP.

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/json". At publication of this specification, no fragment identification syntax is defined for "application/json".

Additional information:

Deprecated alias names for this type: N/A

Magic number(s): N/A

File extension(s): N/A

Macintosh file type code(s): N/A

Person & email address to contact for further information:

IETF LAMPS Working Group (spasm@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

IETF LAMPS Working Group

Change controller:

IETF

CBOR Media Type

Type name:

application

Subtype name:

est-attestation-freshness+cbor

Required parameters:

N/A

Optional parameters:

N/A

Encoding considerations:

binary

Security considerations:

See of this RFC.

Interoperability considerations:

The same media type is used for EST attestation freshness nonce requests and nonce responses. The protocol context determines whether the CBOR payload is a request or response.

Published specification:

This RFC.

Applications that use this media type:

EST implementations using attestation freshness nonces over CoAP.

Fragment identifier considerations:

The syntax and semantics of fragment identifiers are as specified for "application/cbor". At publication of this specification, no fragment identification syntax is defined for "application/cbor".

Additional information:

Deprecated alias names for this type: N/A

Magic number(s): N/A

File extension(s): N/A

Macintosh file type code(s): N/A

Person & email address to contact for further information:

IETF LAMPS Working Group (spasm@ietf.org)

Intended usage:

COMMON

Restrictions on usage:

N/A

Author:

IETF LAMPS Working Group

Change controller:

IETF

CoAP Content-Format IANA is requested to register the following Content-Format in the "CoAP Content-Formats" subregistry within the "CoRE Parameters" registry . This registration uses the IETF Review or IESG Approval range defined for that registry.

Media Type	ID	Reference
application/est-attestation-freshness+cbor	TBD3	This-RFC

CMC

Control IANA is requested to register the following object identifier in the "SMI Security for PKIX CMC Controls" registry (1.3.6.1.5.5.7.7):

Decimal	Description	Reference
TBD4	id-cmc-nonceReq	This-RFC
TBD5	id-cmc-nonceResp	This-RFC

ASN.1 Module IANA is 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

Operational Considerations When the RA/CA is requested to provide a nonce to an end entity, it can generate the nonce locally or obtain it through an interaction 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 nonce value MUST contain a random byte sequence with at least 64 bits of entropy. The RA/CA MUST ensure that a nonce it generates is unique and MUST NOT be reused. If the RA/CA obtains a nonce from the Verifier, it MUST ensure that the Verifier utilizes the same policy for uniqueness and non-reuse properties. 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 nonce request message, regarding the required nonce length for the attestation technology. Nonces of incorrect length may 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. The end entity MUST use the received nonce if the remote attestation technology used supports the requested length. If the selected attestation statement type defines a deterministic nonce transformation for use by a specific Attester or sub-Attester, the end entity MUST apply only that transformation and only for the purpose defined by that specification. If attestation-type-specific response information is returned with the nonce, the end entity MUST process that information according to the selected type when invoking the attestation technology. Such information MAY include parameters or metadata needed to apply, identify, or validate a deterministic nonce transformation defined by the attestation statement type. 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 identified by the AttestationStatement type. The returned Evidence is encapsulated in the 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 is 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 freshness established by the nonce applies to the Evidence as bound to the nonce used by the attestation technology. This specification does not assign independent freshness semantics to other claims contained in the Evidence. The interpretation of any other claim, including whether it represents current state, historical state, configuration state, or measurement results, is defined by the attestation technology, the appraisal policy, and the Verifier or Relying Party processing rules. Using nonces causes the Relying Party to create state for outstanding freshness challenges. This state increases the attack surface for denial-of-service attacks, for example by causing the Relying Party to allocate memory for many nonce requests that never result in corresponding Evidence. Relying Parties SHOULD reduce this exposure by limiting nonce lifetimes, bounding the number of outstanding nonces, applying rate limits, associating nonce state with an authenticated or otherwise constrained requester where possible, and promptly discarding expired state. The use of a stateless cookie mechanism to reduce this state-management burden is also possible but not further detailed in this specification.

Security Considerations This specification details the process of obtaining a nonce via CMP, EST, and CMC. Therefore, the security considerations of these protocols apply. Regarding the use of attestation statements in a CSR, the security considerations outlined in are pertinent to this specification. The nonce itself does not generally require confidentiality protection while maintaining the security properties of the remote attestation protocol. However, optional attestation-type-specific request or response information conveyed together with the nonce MAY reveal privacy-sensitive or deployment-sensitive information, such as platform topology, certificate identifiers, or measurement selections. defines the IETF remote attestation architecture and extensively discusses nonce-based freshness. Specific attestation technology specifications such as and offer guidance on replay protection using nonces. This document defers specific recommendations to those specifications. If an attestation technology or Composite Attester profile transforms a received nonce before embedding it in Evidence, that transformation MUST be deterministic, MUST preserve at least the minimum entropy required by the attestation technology, and MUST provide the Verifier with enough information to reconstruct or validate the transformed value when needed. Specifications defining such transformations SHOULD use well-analyzed cryptographic mechanisms for nonce expansion or size adjustment to ensure that the resulting entropy and security properties remain acceptable. If attestation-type-specific nonce exchange information is used, the corresponding specification MUST define the syntax and semantics of that information, including any confidentiality requirements. Implementations SHOULD minimize the amount of such information returned by the RA/CA and SHOULD protect it using the message or transport security mechanisms of the enrollment protocol when confidentiality is required by deployment policy or by the attestation technology 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. Cryptic Forest Software Siemens Fraunhofer SIT Independent 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: 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 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. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates. 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 proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. 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 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. ITU-T ITU-T Informative References Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Sandelman Software Works Fraunhofer SIT Arm Linaro This document clarifies and extends the meaning of Composite Attester from RFC9334. A system of annotated diagram components is defined as a small language to explain the different ways that components can interact to form composites. These diagram components are then used to define a few popular classes of composites. Fraunhofer SIT Fraunhofer SIT Huawei Technologies Cisco Systems This document describes interaction models for remote attestation procedures (RATS) [RFC9334]. Three conveying mechanisms -- Challenge/Response, Uni-Directional, and Streaming Remote Attestation -- are illustrated and defined. Analogously, a general overview about the information elements typically used by corresponding conveyance protocols are highlighted. 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. This document aims at simple, interoperable, and automated PKI management operations covering typical use cases of industrial and Internet of Things (IoT) scenarios. This is achieved by profiling the Certificate Management Protocol (CMP), the related Certificate Request Message Format (CRMF), and transfer based on HTTP or Constrained Application Protocol (CoAP) in a succinct but sufficiently detailed and self-contained way. To make secure certificate management for simple scenarios and constrained devices as lightweight as possible, only the most crucial types of operations and options are specified as mandatory. More specialized or complex use cases are supported with optional features. 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.

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) } id-cmc, 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(TBDCMC) } -- RFC Editor: TBDCMC shall be TBD1 as defined by -- Section 11 of draft-ietf-lamps-rfc5272bis ; -- NonceRequest and NonceResponse types ATTESTATION-NONCE-REQUEST ::= TYPE-IDENTIFIER AttestationNonceRequestSet ATTESTATION-NONCE-REQUEST ::= { ... -- None defined in this document -- } ATTESTATION-NONCE-RESPONSE ::= TYPE-IDENTIFIER AttestationNonceResponseSet ATTESTATION-NONCE-RESPONSE ::= { ... -- None defined in this document -- } NonceRequest ::= SEQUENCE { len INTEGER (8..64) OPTIONAL, -- indicates the required length of the requested nonce type ATTESTATION-NONCE-REQUEST.&id( {AttestationNonceRequestSet}) OPTIONAL, -- identifies the nonce-request syntax for the selected -- attestation statement type reqInfo ATTESTATION-NONCE-REQUEST.&Type( {AttestationNonceRequestSet}{@type}) OPTIONAL -- contains type-specific nonce-request information } NonceResponse ::= SEQUENCE { nonce OCTET STRING (SIZE(0 | 8..64)), -- contains the nonce of length len -- a zero-length OCTET STRING indicates that no freshness -- proof is required expiry INTEGER OPTIONAL, -- indicates how long in seconds the nonce issuer considers -- the nonce valid type ATTESTATION-NONCE-RESPONSE.&id( {AttestationNonceResponseSet}) OPTIONAL, -- identifies the nonce-response syntax for the selected -- attestation statement type respInfo ATTESTATION-NONCE-RESPONSE.&Type( {AttestationNonceResponseSet}{@type}) OPTIONAL -- contains type-specific nonce-response information } id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 } NonceRequestValue ::= NonceRequest id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 } NonceResponseValue ::= NonceResponse cmc-nonceReq CMC-CONTROL ::= { NonceRequest IDENTIFIED BY id-cmc-nonceReq } id-cmc-nonceReq OBJECT IDENTIFIER ::= { id-cmc TBD4 } cmc-nonceResp CMC-CONTROL ::= { NonceResponse IDENTIFIED BY id-cmc-nonceResp } id-cmc-nonceResp OBJECT IDENTIFIER ::= { id-cmc TBD5 } END ]]>