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-01

LAMPS                                                      H. Tschofenig
Internet-Draft                                              H. Brockhaus
Intended status: Standards Track                                 Siemens
Expires: 9 January 2025                                      8 July 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-01

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

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 1]
Internet-Draft         Nonce Extension for CMP/EST             July 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  . . . . . . . . . . . . . . . . . .   7
     4.1.  Request Methods . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Example Requests  . . . . . . . . . . . . . . . . . . . .   8
     4.3.  Server Response . . . . . . . . . . . . . . . . . . . . .   8
   5.  Nonce Processing Guidelines . . . . . . . . . . . . . . . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  12
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

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 January 2025                 [Page 2]
Internet-Draft         Nonce Extension for CMP/EST             July 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 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).

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 3]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

                                 .---------------.
                                 |               |
                                 |   Verifier    |
                                 |               |
                                 '---------------'
                                      |    ^  |    (3)
                                      |    |  | Attestation
                                      |    |  |   Result
                       (1)            |    |  v
    .------------.   Nonce in    .----|----|-----.
    |            |   CMP or EST  |    |    |     |
    |  End       |<-------------------+    |     |
    |  Entity    |               |         |     |
    |    ^       |-------------->|---------'     |
    |    |       |   Evidence    | Relying       |
    |    v       |   in CSR      | Party (RA/CA) |
    |  Attester  |     (2)       |               |
    |            |               |               |
    '------------'               '---------------'

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

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

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 4]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

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.

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 5]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

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

              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.

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 6]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

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

4.1.  Request Methods

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

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 7]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

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

 +-------------------+---------------------------------+---------------+
 | 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 a nonce using a GET request:

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

   To retrieve a nonce while specifying the size and providing a hint
   about the verification service using a POST request:

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

   The payload in a POST request MUST be of content-type "application/
   json" and MUST contain a JSON object [RFC7159] with the member "len"
   indicating the length of the requested nonce value in bytes, and
   optionally the "hint" member, which specifies an FQDN based on the
   definition in the EvidenceHint structure from
   [I-D.ietf-lamps-csr-attestation]).

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 a JSON
   object [RFC7159] with the "nonce" member.  The "expiry" member is
   optional and indicates the validity period of the nonce.

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 8]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

   The EST server MAY request HTTP-based client authentication, as
   explained in Section 3.2.3 of [RFC7030].

   If the request is successful, the EST server response MUST contain a
   HTTP 200 response code with a content-type of "application/json" and
   a JSON object [RFC7159] with the member nonce.  The expiry member is
   optional and indicates the time the nonce is considered valid.  After
   the expiry time is expired, the session is likely garbage collected.

   Below is an example response:

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

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

   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.

   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.

Tschofenig & Brockhaus   Expires 9 January 2025                 [Page 9]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

   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.

Tschofenig & Brockhaus   Expires 9 January 2025                [Page 10]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

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

8.1.  Normative References

   [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-10, 7
              July 2024, <https://datatracker.ietf.org/doc/html/draft-
              ietf-lamps-csr-attestation-10>.

   [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-12, 8 July 2024,
              <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
              rfc4210bis-12>.

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

Tschofenig & Brockhaus   Expires 9 January 2025                [Page 11]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

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

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

8.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-29, 8 July
              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
              rats-eat-29>.

Tschofenig & Brockhaus   Expires 9 January 2025                [Page 12]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

   [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-23, 24 June 2024,
              <https://datatracker.ietf.org/doc/html/draft-tschofenig-
              rats-psa-token-23>.

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

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

   Hannes Tschofenig
   Siemens
   Germany
   Email: hannes.tschofenig@gmx.net

   Hendrik Brockhaus
   Siemens
   Werner-von-Siemens-Strasse 1
   80333 Munich
   Germany

Tschofenig & Brockhaus   Expires 9 January 2025                [Page 13]
Internet-Draft         Nonce Extension for CMP/EST             July 2024

   Email: hendrik.brockhaus@siemens.com
   URI:   https://www.siemens.com

Tschofenig & Brockhaus   Expires 9 January 2025                [Page 14]