Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)

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 9 January 2025.¶

Copyright Notice

Copyright (c) 2024 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

The management of certificates, encompassing issuance, CA certificate provisioning, renewal, and revocation, has been streamlined through standardized protocols.¶

The Certificate Management Protocol (CMP) [I-D.ietf-lamps-rfc4210bis] 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) [RFC4211] but also supports PKCS#10 [RFC2986].¶

Enrollment over Secure Transport (EST) ([RFC7030], [RFC8295]) is another certificate management protocol that provides a subset of CMP's features, primarily using PKCS#10 for CSRs.¶

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 as Evidence in remote attestation, the remote attestation extension [I-D.ietf-lamps-csr-attestation] has been defined. It specifies how Evidence produced by an Attester is encoded for inclusion in CRMF or PKCS#10, along with any necessary certificates for its validation.¶

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 T[TPM20] and [I-D.tschofenig-rats-psa-token], often employ nonces to ensure the freshness of Evidence. Further details on ensuring Evidence freshness can be found in Section 10 of [RFC9334].¶

Since an end entity requires a nonce from the Verifier via the Relying Party, an additional roundtrip is necessary. However, a CSR is a one-shot message. Therefore, CMP and EST enable the end entity to request information from the RA/CA before submitting a certification request conveniently.¶

Once the nonce is obtained, the end entity invokes an API on the Attester, providing the nonce as an input parameter. The Attester then returns the Evidence, which is embedded into a CSR and submitted back to the RA/CA in a certification request message.¶

Figure 1 illustrates this interaction:¶

• The nonce is acquired in step (1) using the extension to CMP/EST defined in this document.¶

• The CSR extension [I-D.ietf-lamps-csr-attestation] conveys Evidence to the RA/CA in step (2).¶

• The Verifier processes the received information and sends an Attestation Result to the Relying Party in step (3).¶

The functionality described in this document is divided into two sections:¶

• Section 3 describes how to convey the nonce using CMP.¶

• Section 4 describes the equivalent functionality for EST.¶

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

The terms Attester, Relying Party, Verifier and Evidence are defined in [RFC9334]. The terms end entity, certification authority (CA), and registration authority (RA) are defined in [RFC5280].¶

We use the terms Certificate Signing Request (CSR) and certification request interchangeably.¶

3. Conveying a Nonce in CMP

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

 GenMsg:    {id-it TBD1}, NonceRequestValue
 GenRep:    {id-it TBD2}, NonceResponseValue | < absent >

 id-it-nonceRequest OBJECT IDENTIFIER ::= { id-it TBD1 }
 NonceRequestValue ::= SEQUENCE {
    len INTEGER OPTIONAL,
    -- indicates the required length of the requested nonce
    hint EvidenceHint OPTIONAL
    -- indicates which Verifier to request a nonce from
 }

 id-it-nonceResponse OBJECT IDENTIFIER ::= { id-it TBD2 }
 NonceResponseValue ::= SEQUENCE {
    nonce OCTET STRING
    -- contains the nonce of length len
    -- provided by the Verifier indicated with hint
    expiry Time OPTIONAL
    -- indicates how long the Verifier considers the
    -- nonce valid
 }

Note: The EvidenceHint structure is defined in [I-D.ietf-lamps-csr-attestation]. It allows the Attester to specify to the Relying Party which Verifier should be contacted to obtain the nonce.¶

The use of the general request/response message exchange leads to an extra roundtrip to convey the nonce from the CA/RA to the end entity (and ultimately to the Attester inside the end entity).¶

The use of the general request/response message exchange introduces an additional roundtrip for transmitting the nonce from the CA/RA to the end entity (and subsequently to the Attester within the end entity).¶

The end entity MUST construct a NonceRequest message to prompt the RA/CA to send a nonce in response.¶

Open Issue: Should the request message indicate the remote attestation capability of the Attester rather than relying solely on "policy information"? This might allow the Attester (and the end entity) to inform the RA/CA about the specific attestation technologies available.¶

If the end entity supports remote attestation and the policy dictates the inclusion of Evidence in a CSR, the RA/CA responds with a NonceResponse message containing the requested nonce.¶

The interaction is illustrated in Figure 2.¶

End Entity                                          RA/CA
==========                                      =============

              -->>-- NonceRequest -->>--
                                                Verify request
                                                Generate nonce*
                                                Create response
              --<<-- NonceResponse --<<--
                    (nonce, expiry)

Generate key pair
Generate Evidence*
Generate certification request message
              -->>-- certification request -->>--
                   +Evidence including nonce)
                                               Verify request
                                               Verify Evidence*
                                               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 Section 3.6 of [I-D.ietf-lamps-rfc4210bis] MAY be used.¶

 +------------------------+-----------------+-------------------+
 | Operation              |Operation path   | Details           |
 +========================+=================+===================+
 | Get Attestation        | getnonce        | {{CMP}}           |
 | Freshness Nonce        |                 |                   |
 +------------------------+-----------------+-------------------+

If CoAP is used for transferring NonceRequest and NonceResponse messages, the OPTIONAL <operation> path segment defined in Section 2.1 of [RFC9482] MAY be used.¶

 +------------------------+-----------------+-------------------+
 | Operation              |Operation path   | Details           |
 +========================+=================+===================+
 | Get Attestation        | nonce           | {{CMP}}           |
 | Freshness Nonce        |                 |                   |
 +------------------------+-----------------+-------------------+

4. Conveying a Nonce in EST

The EST client requests a nonce 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 [RFC5785] 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          | {{EST}}           |
 +------------------------+-----------------+-------------------+

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

 +-------------------+---------------------------------+---------------+
 | Message type      | Media type(s)                   | Reference     |
 | (per operation)   |                                 |               |
 +===================+=================================+===============+
 | Nonce Request     | N/A (for GET) or                | This section  |
 |                   | application/json (for POST)     |               |
 +===================+=================================+===============+
 | Nonce Response    | application/json                | This section  |
 |                   |                                 |               |
 +===================+=================================+===============+

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

POST /.well-known/est/nonce HTTP/1.1
Content-Type: application/json
{
  "len": 8,
  "hint": "https://example.com"
}

HTTP/1.1 200 OK
Content-Type: application/json

{
    "nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=",
    "expiry": "2031-10-12T07:20:50.52Z"
}

5. 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 [RFC9334], 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 whereby the length depends on the used remote attestation technology as specific nonce length 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 [I-D.tschofenig-rats-psa-token] supports nonce lengths of 32, 48, and 64 bytes. Other attestation technologies employ nonces of similar lengths.¶

When the end entity requests a nonce, the RA/CA SHOULD respond with a nonce in the specified length.¶

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. The returned Evidence is encapsulated within the CSR, as defined in [I-D.ietf-lamps-csr-attestation]. The software generating the CSR treats the Evidence 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 Evidence payload.¶

The processing of CSRs containing Evidence is detailed in [I-D.ietf-lamps-csr-attestation]. mportantly, certificates issued based on this process do not contain the nonce, as specified in [I-D.ietf-lamps-csr-attestation].¶

6. IANA Considerations

This document adds new entries to the "CMP Well-Known URI Path Segments" registry defined in [RFC8615].¶

 +----------------+---------------------------+-----------------+
 | Path Segment   | Description               | Reference       |
 +================+===========================+=================+
 | getnonce       | Get Attestation Freshness | {{cmp}}         |
 |                | Nonce over HTTP           |                 |
 +----------------+---------------------------+-----------------+
 | nonce          | Get Attestation Freshness | {{cmp}}         |
 |                | Nonce over CoAP           |                 |
 +----------------+---------------------------+-----------------+

[Open Issue: Register path segments for EST]¶

7. Security Considerations

This specification details the process of obtaining a nonce via CMP and EST, assuming that the nonce does not require confidentiality protection while maintaining the security properties of the remote attestation protocol. [RFC9334] defines the IETF remote attestation architecture and extensively discusses nonce-based freshness.¶

Section 8.4 of [I-D.ietf-rats-eat] 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 [I-D.tschofenig-rats-psa-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 Evidence in a CSR, the security considerations outlined in [I-D.ietf-lamps-csr-attestation] are pertinent to this specification.¶

Appendix A. Acknowledgments

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

Authors' Addresses