Requesting a Freshness Nonce for Attestation Evidence in Certificate Signing Requests

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 December 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[I-D.ietf-lamps-csr-attestation] specifies how Attestation Evidence, as defined in the RATS Architecture [RFC9334], can be conveyed in a Certificate Signing Request (CSR) using PKCS#10 [RFC2986] or CRMF [RFC4211]. The RATS Architecture calls for establishing the freshness of Evidence, see Section 10 of [RFC9334]. 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 [RFC9810], EST [RFC7030], or CMC [I-D.ietf-lamps-rfc5272bis], 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.¶

2. 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 [RFC2119].¶

This document uses RATS and PKIX terminology as described in Section 3 of [I-D.ietf-lamps-csr-attestation]. It also uses terminology from the applicable certificate lifecycle management protocols: CMP, EST, and CMC.¶

3. Architecture and Message Formats

According to [I-D.ietf-lamps-csr-attestation], 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 (Section 6 of [I-D.ietf-rats-reference-interaction-models]) such as Attesting Environment IDs and Claim Selection.¶

The generic message flow between the end entity and the RA/CA is shown in Figure 1.¶

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 Section 3.3 of [RFC9334] and [I-D.richardson-rats-composite-attesters], i.e., together with a conceptual message wrapper (CMW) [I-D.ietf-rats-msg-wrap] structure, as described in Section 4.3 of [I-D.ietf-lamps-csr-attestation]. The lead Attester should then pass the nonce to the sub-Attesters. Based on Figure 2 of [I-D.richardson-rats-composite-attesters], Figure 2 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).¶

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

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.¶

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
}

nonce-request = {
  ? "len": nonce-length,
  ? "type": dotted-decimal-oid,
  ? "reqInfo": any
}

nonce-response-json = {
    "nonce": json-nonce,
  ? "expiry": uint,
  ? "type": dotted-decimal-oid,
  ? "respInfo": any
}

nonce-response-cbor = {
    "nonce": cbor-nonce,
  ? "expiry": uint,
  ? "type": dotted-decimal-oid,
  ? "respInfo": any
}

nonce-length = 8..64
cbor-nonce = h'' / bstr .size (8..64)
json-nonce = "" / base64url-nonce
base64url-nonce = tstr .regexp "[A-Za-z0-9_-]{11,86}"
dotted-decimal-oid = tstr

4. Use with CMP

The nonce request and nonce response message content is conveyed as ASN.1 content, see Section 3.1, in a general message (genm) Section 5.3.19 of [RFC9810] and general response (genp) Section 5.3.20 of [RFC9810], respectively.¶

GenMsg:    {id-it TBD1}, NonceRequest
GenRep:    {id-it TBD2}, NonceResponse

id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 }
NonceRequestValue ::= NonceRequest

id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 }
NonceResponseValue ::= NonceResponse

When CMP is transferred over HTTP, the OPTIONAL <operation> path segment defined in Section 3.4 of [RFC9811] MAY be used for the nonce request message.¶

When CMP is transferred over CoAP, the OPTIONAL <operation> path segment defined in Section 2.1 of [RFC9482] MAY be used for the nonce request message.¶

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 [RFC9483].¶

• If HTTP or CoAP is used for transferring the general message, return a status code on transfer level as described in [RFC9811] or [RFC9482].¶

5. Use with EST

The nonce request and nonce response message content is conveyed as JSON or CBOR according to the CDDL definition, see Section 3.2, 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.¶

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.¶

GET /.well-known/est/nonce HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/est-attestation-freshness+json

{
  "nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI",
  "expiry": 600
}

POST /.well-known/est/nonce HTTP/1.1
Content-Type: application/est-attestation-freshness+json

{
  "len": 32,
  "type": "1.2.3.4.5",
  "reqInfo": {
    "pcr-index": [0, 1, 2, 3],
    "certificate-name": ["aik-1"]
  }
}

HTTP/1.1 200 OK
Content-Type: application/est-attestation-freshness+json

{
  "nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI",
  "expiry": 600,
  "type": "1.2.3.4.6",
  "respInfo": {
    "certificate-name": "aik-1"
  }
}

6. Use with CMC

The nonce request and nonce response message content is conveyed as ASN.1, see Section 3.1, as CMC Controls in a Full PKI Request, see Section 6 of [I-D.ietf-lamps-rfc5272bis]. 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.¶

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 }

The following example shows the nonce request and nonce response message content:¶

ContentInfo.contentType = id-data
ContentInfo.content
   controlSequence
      {101, id-cmc-senderNonce, 10001}
      {102, id-cmc-nonceReq, <NonceRequest>}

ContentInfo.contentType = id-data
ContentInfo.content
   controlSequence
      {101, id-cmc-senderNonce, 10005}
      {102, id-cmc-recipientNonce, 10001}
      {103, id-cmc-nonceResp, <NonceResponse>}

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 Section 6.1 of [I-D.ietf-lamps-rfc5272bis].¶

7. IANA Considerations

8. 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 [RFC9334], 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 [RFC9783] 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 [I-D.ietf-lamps-csr-attestation]. 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.¶

9. 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 [I-D.ietf-lamps-csr-attestation] 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. [RFC9334] defines the IETF remote attestation architecture and extensively discusses nonce-based freshness.¶

Specific attestation technology specifications such as [RFC9711] and [RFC9783] 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.¶

10. Acknowledgments

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

11. References

Appendix A. ASN.1 Module

The following module adheres to ASN.1 specifications [X.680] and [X.690].¶

<CODE BEGINS>

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
<CODE ENDS>

Authors' Addresses