Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)
draft-ietf-lamps-attestation-freshness-03
| Document | Type | Active Internet-Draft (lamps WG) | |
|---|---|---|---|
| Authors | Hannes Tschofenig , Hendrik Brockhaus | ||
| Last updated | 2024-11-05 | ||
| Replaces | draft-tschofenig-lamps-nonce-cmp-est | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lamps-attestation-freshness-03
LAMPS Working Group H. Tschofenig
Internet-Draft H. Brockhaus
Intended status: Standards Track Siemens
Expires: 9 May 2025 5 November 2024
Nonce-based Freshness for Remote Attestation in Certificate Signing
Requests (CSRs) for the Certification Management Protocol (CMP) and for
Enrollment over Secure Transport (EST)
draft-ietf-lamps-attestation-freshness-03
Abstract
When an end entity includes attestation Evidence in a Certificate
Signing Request (CSR), it may be necessary to demonstrate the
freshness of the provided Evidence. 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) and 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 May 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.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 1]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Requirements Language . . . . . . . . . . . . 4
3. Conveying a Nonce in CMP . . . . . . . . . . . . . . . . . . 5
4. Conveying a Nonce in EST . . . . . . . . . . . . . . . . . . 8
4.1. Request Methods . . . . . . . . . . . . . . . . . . . . . 8
4.2. Example Requests . . . . . . . . . . . . . . . . . . . . 9
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
5. Nonce Processing Guidelines . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 2]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
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 [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].
Section 4 of [I-D.ietf-lamps-csr-attestation] provides examples where
a CSR contains one or more Evidence statements. For each Evidence
statement the end entity may wish to request a separate nonce.
Since an end entity requires one or more nonces from one or more
Verifier via the RA/CA, 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 a nonce is obtained, the end entity invokes the API on an
Attester, providing the nonce as an input parameter. The Attester
then returns an Evidence, which is embedded into a CSR and
potentially together with further Evidence statements, submitted back
to the RA/CA in a certification request message.
Figure 1 illustrates this interaction:
* One or more nonces are requested in step (0) and obtained in step
(1) using the extension to CMP/EST defined in this document.
* The CSR extension [I-D.ietf-lamps-csr-attestation] conveys one or
more Evidence statements to the RA/CA in step (2).
* One ore more Verifier process the received Evidence 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).
Tschofenig & Brockhaus Expires 9 May 2025 [Page 3]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
Attester Relying Party One or more
(End Entity) (RA/CA) Verifier
| | |
| Certificate | |
| Management | |
| Protocol | |
|<----------------------->| |
| | |
| | |
| Request Nonce(s)(0) | |
|------------------------>| |
| | Request Nonce(s) |
| |----------------------->|
| | Nonce(s) |
| |<-----------------------|
| Nonce(s) (1) | |
|<------------------------| |
| | |
| Attested CSR (2) | |
|------------------------>| |
| | Evidence(s) |
| |----------------------->|
| | Attestation Result(s) |
| |<-----------------------|
| Certificate (3) | |
|<------------------------| |
| | |
| | |
Figure 1: Architecture with Background Check Model.
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].
Tschofenig & Brockhaus Expires 9 May 2025 [Page 4]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
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 SIZE (1..MAX) OF NonceRequest
NonceRequest ::= SEQUENCE {
len INTEGER OPTIONAL,
-- indicates the required length of the requested nonce
type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
-- indicates which Evidence 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 EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
-- indicates which Evidence 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 Verifier.
The EVIDENCE-STATEMENT type is defined in
[I-D.ietf-lamps-csr-attestation]. They allow the Attester to specify
to the Relying Party which Verifier should be contacted to obtain a
nonce. If a NonceRequest structure does not contain type or hint,
the RA/CA should respond with a nonce it MAY generated by itself.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 5]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
The use of the general request/response message exchange introduces
an additional roundtrip 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 a id-it-nonceRequest message to prompt
the RA/CA to send a nonce(s) in response. The message may contain
one or more NonceRequest structures, at a maximum one per Evidence
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, NonceResponse, and EvidenceStatement structures can
contain a type field and a hint 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 EvicenceStatements in the
CSR later. This is important so that the RA/CA can send the Evidence
statement to the Verifier who generated the nonce used by the
Attester who generated it.
When receiving nonces from the RA/CA in a id-it-nonceResponse
message, the end entity MUST use them to request Evidence Statements
from the respective Attester optionally indicated by type and hint.
If a nonce is provides in a NonceResponse structure without
indicating any type or hint, it can be used for all Evidence
statements requiring a nonce.
An Evidence statement generated using a nonce provided with an expiry
value will be accepted by the Verifyer as valid until the respective
expiry time elapsed. It is expected that the respective messages are
delivered in a timely manner.
The interaction is illustrated in Figure 2.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 6]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
End Entity RA/CA
========== =============
-->>--- id-it-NonceRequest --->>--
Verify request
Generate nonce(s)*
Create response
--<<--- id-it-NonceResponse ---<<--
(nonce(s), expiry)
Generate key pair
Generate Evidence(s)*
Generate certification
request message
-->>--- certification request --->>--
+Evidence(s) including nonce)
Verify request
Verify Evidence(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).
Figure 2: CMP Exchange with Nonce and Evidence.
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.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 7]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
+------------------------+-----------------+-------------------+
| Operation |Operation path | Details |
+========================+=================+===================+
| Get Attestation | nonce | {{CMP}} |
| Freshness Nonce | | |
+------------------------+-----------------+-------------------+
4. 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 [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".
4.1. 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.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 8]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
+------------------+------------------------------+---------------+
| 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 |
| | | |
+==================+==============================+===============+
4.2. Example Requests
To retrieve one nonce without providing length, type, or hint using a
GET request:
GET /.well-known/est/nonce HTTP/1.1
To retrieve one or more nonces while specifying the length, type,
and/or hint using a POST request:
POST /.well-known/est/nonce HTTP/1.1
Content-Type: application/json
[
{
"len": 8,
"type": "<OID>",
"hint": "https://example.com"
},
...
]
< ToDo: Fix the json structure regarding the sequence of len, type,
and hint and how the OID for type shall be encoded. >
The payload in a POST request MUST be of content-type "application/
json" and MUST contain an array of JSON objects [RFC7159] containing
"len", "type", and "hint" members The optional member "len"
indicating the length of the requested nonce value in bytes. The
optional "type" (containing an EvicenceStatement OID as defined in
[I-D.ietf-lamps-csr-attestation]) and "hint" members (containing an
FQDN based on the definition in the EvidenceHint structure as defined
in [I-D.ietf-lamps-csr-attestation]) indicate the Verifyer to use.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 9]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
4.3. 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 [RFC7159] with the "nonce" member. The "expiry" member
is optional and indicates the validity period of the nonce. The
optional "type" and "hint" members are copied from the request.
The EST server MAY request HTTP-based client authentication, as
explained in Section 3.2.3 of [RFC7030].
Below is an example response:
HTTP/1.1 200 OK
Content-Type: application/json
[
{
"nonce": "MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=",
"expiry": "2031-10-12T07:20:50.52Z"
"type": "<OID>",
"hint": "https://example.com"
},
...
]
< ToDo: Fix the json structure regarding the sequence of len, type,
and hint and how the OID for type shall be encoded. >
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?
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.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 10]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
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.
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 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]. Importantly, 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]
IANA is also requested to register the following ASN.1 [X.680] module
OID in the "SMI Security for PKIX Module Identifier" registry
(1.3.6.1.5.5.7.0). This OID is defined in Appendix A.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 11]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
+=========+======================+============+
| Decimal | Description | References |
+=========+======================+============+
| TBDMOD | id-mod-att-fresh-req | This-RFC |
+---------+----------------------+------------+
Table 1
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.
8. Acknowledgments
We would like to thank Russ Housley, Thomas Fossati, Watson Ladd,
Ionut Mihalcea, Carl Wallace, and Michael StJohns for their review
comments.
9. References
9.1. Normative References
Tschofenig & Brockhaus Expires 9 May 2025 [Page 12]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-14, 21
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-lamps-csr-attestation-14>.
[I-D.ietf-lamps-rfc4210bis]
Brockhaus, H., von Oheimb, D., Ounsworth, M., and J. Gray,
"Internet X.509 Public Key Infrastructure -- Certificate
Management Protocol (CMP)", Work in Progress, Internet-
Draft, draft-ietf-lamps-rfc4210bis-14, 9 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
rfc4210bis-14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/rfc/rfc5785>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/rfc/rfc7159>.
[RFC8295] Turner, S., "EST (Enrollment over Secure Transport)
Extensions", RFC 8295, DOI 10.17487/RFC8295, January 2018,
<https://www.rfc-editor.org/rfc/rfc8295>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 13]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
[RFC9482] Sahni, M., Ed. and S. Tripathi, Ed., "Constrained
Application Protocol (CoAP) Transfer for the Certificate
Management Protocol", RFC 9482, DOI 10.17487/RFC9482,
November 2023, <https://www.rfc-editor.org/rfc/rfc9482>.
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation
One (ASN.1): Specification of basic notation", ITU-T
Recommendation X.680 , February 2021,
<https://www.itu.int/rec/T-REC.X.680>.
[X.690] ITU-T, "Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ITU-T Recommendation X.690 , February 2021,
<https://www.itu.int/rec/T-REC.X.690>.
9.2. Informative References
[I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[I-D.tschofenig-rats-psa-token]
Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
T. Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-24, 23 September 2024,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-24>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/rfc/rfc4211>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
Tschofenig & Brockhaus Expires 9 May 2025 [Page 14]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
[TPM20] Trusted Computing Group, "Trusted Platform Module Library
Specification, Family 2.0, Level 00, Revision 01.59",
November 2019,
<https://trustedcomputinggroup.org/resource/tpm-library-
specification/>.
Appendix A. ASN.1 Module
The following module adheres to ASN.1 specifications [X.680] and
[X.690].
<CODE BEGINS>
att-fres-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(TBD-PKIXCMP-23) }
-- RFC Editor: The value for id-mod-cmp2023-02 must be set as soon
-- as it is assigned by I-D.ietf-lamps-rfc4210bis
EVIDENCE-STATEMENT, EvidenceStatementSet
FROM CSR-ATTESTATION-2023
{ 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-2023) }
-- 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
;
-- 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 EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
Tschofenig & Brockhaus Expires 9 May 2025 [Page 15]
Internet-Draft Freshness Nonces for Remote Attestation November 2024
-- indicates which Evidence 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 EVIDENCE-STATEMENT.&id({EvidenceStatementSet}) OPTIONAL,
-- indicates which Evidence type to request a nonce for
hint UTF8String OPTIONAL
-- indicates which Verifier to request a nonce from
}
END
<CODE ENDS>
Authors' Addresses
Hannes Tschofenig
Siemens
Germany
Email: hannes.tschofenig@gmx.net
Hendrik Brockhaus
Siemens
Werner-von-Siemens-Strasse 1
80333 Munich
Germany
Email: hendrik.brockhaus@siemens.com
URI: https://www.siemens.com
Tschofenig & Brockhaus Expires 9 May 2025 [Page 16]