TLS H. Tschofenig Internet-Draft T. Fossati Intended status: Standards Track P. Howard Expires: 27 February 2023 I. Mihalcea Y. Deshpande Arm Limited 26 August 2022 Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) draft-fossati-tls-attestation-01 Abstract Various attestation technologies have been developed and formats have been standardized. Examples include the Entity Attestation Token (EAT) and Trusted Platform Modules (TPMs). Once attestation information has been produced on a device it needs to be communicated to a relying party. This information exchange may happen at different layers in the protocol stack. This specification provides a generic way of passing attestation information in the TLS handshake. 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 27 February 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Tschofenig, et al. Expires 27 February 2023 [Page 1] Internet-Draft Attestation in TLS/DTLS August 2022 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Attestation within the Passport Model . . . . . . . . . . 6 3.2. Attestation within the Background Check Model . . . . . . 7 4. TLS Attestation Type Extension . . . . . . . . . . . . . . . 8 5. TLS Client and Server Handshake Behavior . . . . . . . . . . 10 5.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 12 6. TPM Attestation . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Platform Attestation . . . . . . . . . . . . . . . . . . 13 6.1.1. TPM Platform Attestation Statement Format . . . . . . 13 6.1.2. Signing Procedure . . . . . . . . . . . . . . . . . . 14 6.1.3. Verification Procedure . . . . . . . . . . . . . . . 15 6.2. Key Attestation . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Appendix A. History . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. Working Group Information . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Tschofenig, et al. Expires 27 February 2023 [Page 2] Internet-Draft Attestation in TLS/DTLS August 2022 1. Introduction Attestation is the process by which an entity produces evidence about itself that another party can use to evaluate the trustworthiness of that entity. One format of encoding evidence is standardized with the Entity Attestation Token (EAT) [I-D.ietf-rats-eat] but there are other formats, such as attestation produced by Trusted Platform Modules (TPMs) [TPM1.2] [TPM2.0]. This specification defines how to convey attestation information in the TLS handshake with different encodings being supported. This specification standardizes two attestation formats - EAT and TPM- based attestation. Note: This initial version of the specification focuses on EAT-based attestation. Future versions will also define TPM-based attestation. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following terms are used in this document: * Root of Trust (RoT): A set of software and/or hardware components that need to be trusted to act as a security foundation required for accomplishing the security goals. In our case, the RoT is expected to offer the functionality for attesting to the state of the platform. * Attestation Key (AK): Cryptographic key belonging to the RoT that is only used to sign attestation tokens. * Platform Attestation Key (PAK): An AK used specifically for signing attestation tokens relating to the state of the platform. * Key Attestation Key (KAK): An AK used specifically for signing KATs. In some systems only a single AK is used. In that case the AK is used as a PAK and a KAK. * TLS Identity Key (TIK): The KIK consists of a private and a public key. The private key is used in the CertificateVerify message during the TLS handshake. The public key is included in the Key Attestation Token. Tschofenig, et al. Expires 27 February 2023 [Page 3] Internet-Draft Attestation in TLS/DTLS August 2022 * Attestation Token (AT): A collection of claims that a RoT assembles (and signs) with the purpose of informing - in a verifiable way - Relying Parties about the identity and state of the platform. Essentially a type of "Evidence" as per the RATS architecture terminology. * Platform Attestation Token (PAT): An AT containing claims relating to the state of the software running on the platform. The process of generating a PAT typically involves gathering data during measured boot. * Key Attestation Token (KAT): An AT containing a claim with a proof-of-possession (PoP) key. The KAT may also contain other claims, such as those indicating its validity. The KAT is signed by the KAK. The attestation service part of the RoT conceptually acts as a local certification authority since the KAT behaves like a certificate. * Combined Attestation Bundle (CAB): A structure used to bundle a KAT and a PAT together for transport in the TLS handshake. If the KAT already includes a PAT, in form of a nested token, then it already corresponds to a CAB. 3. Overview The Remote Attestation Procedures (RATS) architecture [I-D.ietf-rats-architecture] defines two types of interaction models for attestation, namely the passport model and the background-check model. The subsections below explain the difference in their interactions. To simplify the description in this section we focus on the use case where the client is the attester and the server is the relying party. Hence, only the client_attestation_type extension is discussed. The verifier is not shown in the diagrams. The described mechanism allows the roles to be reversed. As typical with new features in TLS, the client indicates support for the new extension in the ClientHello. The client_attestation_type extension lists the supported attestation formats. The server, if it supports the extension and one of the attestation formats, it confirms the use of the feature. Note: The newly introduced extension also allows nonces to be exchanged. Those nonces are used for guaranteeing freshness of the generated attestation tokens. Tschofenig, et al. Expires 27 February 2023 [Page 4] Internet-Draft Attestation in TLS/DTLS August 2022 When the attestation extension is successfully negotiated, the content of the Certificate message is replaced with attestation information described in this document. A peer has to demonstrate possession of the private key via the CertificateVerify message. While attestation information is signed by the attester, it typically does not contain a public key (for example via a proof-of-possession key claim [RFC8747]). The attestation service on a device, which creates the attestation information, is unaware of the TLS exchange and the attestation service does not directly sign externally provided data, as it would be required to compute the CertificateVerify message. Hence, the following steps happen: The client generates the TIK, which are referred here as skT and pkT, for example using the following API call: key_id = GenerateKeyPair(alg_id) The private key would be created and stored by the crypto hardware supported by the device (rather than the TLS client in software). Next, the attestation service needs to be triggered to create a Platform Attestation Token (PAT) and the Key Attestation Token (KAT). The Key Attestation Token (KAT) includes a claim containing the public key of the TIK (pkT). The KAT is then signed with the Key Attestation Key (KAK). To ensure freshness of the PAT and the KAT a nonce is provided by the relying party / verifier. Here is the symbolic API call to request a KAT and a PAT, which are concatinated together as the CAB. cab = createCAB(key_id, nonce) Once the Certificate message containing the CAB has been sent, the CertificateVerify has to be created and it requires access to the private key. The signature operation uses the private key of the TIK (skT). The recipient of the Certificate and the CertificateVerify messages first extracts the PAT and the KAT from the Certificate message. The PAT and the KAT need to be conveyed to the verification service, whereby the following checks are made: * The signature protecting the PAT passes verification when using available trust anchor(s). Tschofenig, et al. Expires 27 February 2023 [Page 5] Internet-Draft Attestation in TLS/DTLS August 2022 * The PAT has not been replayed, which can be checked by comparing the nonce included in one of the claims and matching it against the nonce provided to the attester. * The claims in the PAT are matched against stored reference values. * The signature protecting the KAT passes verification. * The claims in the KAT are validated, if needed. Once all these steps are completed, the verifier produces the attestation result and includes (if needed) the TIK public key. In the subsections we will look at how the two message pattern fit align with the TLS exchange. 3.1. Attestation within the Passport Model The passport model is described in Section 5.1 of [I-D.ietf-rats-architecture]. A key feature of this model is that the attester interacts with the verification service before initiating the TLS exchange. It sends evidence to the verification service, which then returns the attestation result (including the TIK public key). The example exchange in Figure 1 shows how a client provides attestation to the server by utilizing EAT tokens [I-D.ietf-rats-eat]. With the ClientHello the TLS client needs to indicate that it supports the EAT-based attestation format. The TLS server acknowledges support for this attestation type in the EncryptedExtensions message. In the Certificate message the TLS client transmits the attestation result to the TLS server, in form a CAB (i.e. a concatinated PAT and KAT). The TLS client then creates the CertificateVerify message by asking the crypto service to sign the TLS handshake message transcript with the TIK private key. The TLS server then verifies this message by utilizing the TIK public key. Tschofenig, et al. Expires 27 February 2023 [Page 6] Internet-Draft Attestation in TLS/DTLS August 2022 Client Server Key ^ ClientHello Exch | + client_attestation_type(eat) | | v --------> ServerHello ^ KeyExch {EncryptedExtensions} ^ Server + client_attestation_type(eat) | {CertificateRequest} v Params {Certificate} ^ {CertificateVerify} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> [Application Data] <-------> [Application Data] Figure 1: Example Exchange with the Passport Model. 3.2. Attestation within the Background Check Model The background check model is described in Section 5.2 of [I-D.ietf-rats-architecture]. The message exchange of the background check model differs from the passport model because the TLS server needs to provide a nonce in the ServerHello to the TLS client so that the attestation service can feed the nonce into the generation of the PAT. The TLS server, when receiving the CAB, will have to contact the verification service. Tschofenig, et al. Expires 27 February 2023 [Page 7] Internet-Draft Attestation in TLS/DTLS August 2022 Client Server Key ^ ClientHello Exch | + client_attestation_type(eat) | | v --------> ServerHello ^ Key client_attestation_type(eat) | Exch + nonce v {EncryptedExtensions} ^ Server {CertificateRequest} v Params {Certificate} ^ {CertificateVerify} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate} Auth | {CertificateVerify} v {Finished} --------> [Application Data] <-------> [Application Data] Figure 2: Example Exchange with the Background Check Model. 4. TLS Attestation Type Extension This document defines a new extension to carry the attestation types. The extension is conceptually similiar to the 'server_certificate_type' and the 'server_certificate_type' defined by [RFC7250]. Tschofenig, et al. Expires 27 February 2023 [Page 8] Internet-Draft Attestation in TLS/DTLS August 2022 struct { select(ClientOrServerExtension) { case client: CertificateType client_attestation_types<1..2^8-1>; opaque nonce<0..2^16-1>; case server: CertificateType client_attestation_type; opaque nonce<0..2^16-1>; } } ClientAttestationTypeExtension; struct { select(ClientOrServerExtension) { case client: CertificateType server_attestation_types<1..2^8-1>; opaque nonce<0..2^16-1>; case server: CertificateType server_attestation_type; opaque nonce<0..2^16-1>; } } ServerAttestationTypeExtension; Figure 3: AttestationTypeExtension Structure. The Certificate payload is used as a container, as shown in Figure 4. The shown Certificate structure is an adaptation of [RFC8446]. Tschofenig, et al. Expires 27 February 2023 [Page 9] Internet-Draft Attestation in TLS/DTLS August 2022 struct { select (certificate_type) { case RawPublicKey: /* From RFC 7250 ASN.1_subjectPublicKeyInfo */ opaque ASN1_subjectPublicKeyInfo<1..2^24-1>; /* attestation type defined in this document */ case EAT: opaque cab<1..2^24-1>; /* attestation type defined in this document */ case TPM: opaque tpmStmtFormat<1..2^24-1>; case X509: opaque cert_data<1..2^24-1>; }; Extension extensions<0..2^16-1>; } CertificateEntry; struct { opaque certificate_request_context<0..2^8-1>; CertificateEntry certificate_list<0..2^24-1>; } Certificate; Figure 4: Certificate Message. To simplify parsing of an EAT-based attestation payload, the PAT and the KAT are typed. 5. TLS Client and Server Handshake Behavior This specification extends the ClientHello and the EncryptedExtensions messages, according to [RFC8446]. The high-level message exchange in Figure 5 shows the client_attestation_type and server_attestation_type extensions added to the ClientHello and the EncryptedExtensions messages. Tschofenig, et al. Expires 27 February 2023 [Page 10] Internet-Draft Attestation in TLS/DTLS August 2022 Client Server Key ^ ClientHello Exch | + key_share* | + signature_algorithms* | + psk_key_exchange_modes* | + pre_shared_key* | + client_attestation_type v + server_attestation_type --------> ServerHello ^ Key + key_share* | Exch + pre_shared_key* v {EncryptedExtensions} ^ Server + client_attestation_type | + server_attestation_type {CertificateRequest*} v Params {Certificate*} ^ {CertificateVerify*} | Auth {Finished} v <-------- [Application Data*] ^ {Certificate*} Auth | {CertificateVerify*} v {Finished} --------> [Application Data] <-------> [Application Data] Figure 5: Attestation Message Overview. 5.1. Client Hello In order to indicate the support of attestation types, clients include the client_attestation_type and/or the server_attestation_type extensions in the ClientHello. The client_attestation_type extension in the ClientHello indicates the attestation types the client is able to provide to the server, when requested using a CertificateRequest message. The server_attestation_type extension in the ClientHello indicates the types of attestation types the client is able to process when provided by the server in a subsequent Certificate payload. The client_attestation_type and server_attestation_type extensions sent in the ClientHello each carry a list of supported attestation types, sorted by client preference. When the client supports only one attestation type, it is a list containing a single element. Tschofenig, et al. Expires 27 February 2023 [Page 11] Internet-Draft Attestation in TLS/DTLS August 2022 The TLS client MUST omit attestation types from the client_attestation_type extension in the ClientHello if it is not equipped with the corresponding attestation functionality, or if it is not configured to use it with the given TLS server. If the client has no attestation types to send in the ClientHello it MUST omit the client_attestation_type extension in the ClientHello. The TLS client MUST omit attestation types from the server_attestation_type extension in the ClientHello if it is not equipped with the attestation verification functionality. If the client has no attestation types to send in the ClientHello it MUST omit the entire server_attestation_type extension from the ClientHello. 5.2. Server Hello If the server receives a ClientHello that contains the client_attestation_type extension and/or the server_attestation_type extension, then three outcomes are possible: * The server does not support the extension defined in this document. In this case, the server returns the EncryptedExtensions without the extensions defined in this document. * The server supports the extension defined in this document, but it does not have any attestation type in common with the client. Then, the server terminates the session with a fatal alert of type "unsupported_certificate". * The server supports the extensions defined in this document and has at least one attestation type in common with the client. In this case, the processing rules described below are followed. The client_attestation_type extension in the ClientHello indicates the attestation types the client is able to provide to the server, when requested using a certificate_request message. If the TLS server wants to request a certificate from the client (via the certificate_request message), it MUST include the client_attestation_type extension in the EncryptedExtensions. This client_attestation_type extension in the EncryptedExtensions then indicates the content the client is requested to provide in a subsequent Certificate payload. The value conveyed in the client_attestation_type extension MUST be selected from one of the values provided in the client_attestation_type extension sent in the client hello. The server MUST also include a certificate_request payload in the EncryptedExtensions message. Tschofenig, et al. Expires 27 February 2023 [Page 12] Internet-Draft Attestation in TLS/DTLS August 2022 If the server does not send a certificate_request payload (for example, because client authentication happens at the application layer or no client authentication is required) or none of the attestation types supported by the client (as indicated in the client_attestation_type extension in the ClientHello) match the server-supported attestation types, then the client_attestation_type payload in the ServerHello MUST be omitted. The server_attestation_type extension in the ClientHello indicates the types of attestation types the client is able to process when provided by the server in a subsequent Certificate message. With the server_attestation_type extension in the EncryptedExtensions, the TLS server indicates the attestation type carried in the Certificate payload. Note that only a single value is permitted in the server_attestation_type extension when carried in the EncryptedExtensions message. 6. TPM Attestation The Trusted Platform Module (TPM) [TPM2.0] is one type of hardware RoT. TPMs offer the ability to produce both key and platform attestation tokens. 6.1. Platform Attestation Platform Configuration Registers (PCRs) represent the core mechanism in TPMs for measuring and conveying information about the platform state via remote attestation. While specifications exist for assigning individual PCRs to specific software components, the choice of which combination of PCRs to include for any attestation procedure (and which hashing algorithm to use) is left to the parties involved. The agreement over and the configuration of the PCR selection falls outside the scope of this specification and is thus expected to occur out-of-band. The attestation evidence is produced through the TPM2_Quote operation. The evidence along with all other relevant metadata is transmitted in a format derived from the [WebAuthn] Attestation Statements. This format and the workflows around it are defined below. 6.1.1. TPM Platform Attestation Statement Format The TPM Platform Attestation Statement is a modified version of the TPM Attestation Statement Format, which covers key attestation tokens. Tschofenig, et al. Expires 27 February 2023 [Page 13] Internet-Draft Attestation in TLS/DTLS August 2022 tpmPlatStmtFormat = { ver: "2.0", ( alg: COSEAlgorithmIdentifier, x5c: [ pakCert: bytes, * (caCert: bytes) ] ) sig: bytes, attestInfo: bytes, } Figure 6: TPM Platform Attestation Statement Format * _ver_: The version of the TPM specification to which the signature conforms. * _alg_: A COSEAlgorithmIdentifier containing the identifier of the algorithm used to generate the attestation signature. * _x5c_: A certificate for the PAK, followed by its certificate chain. The contents of the array SHOULD follow the same requirements as the _x5chain_ header parameter defined in Section 2 of [I-D.ietf-cose-x509], with the sole difference that a CBOR array is also used when only _pakCert_ is present. - _pakCert_: The PAK certificate used for the attestation. * _sig_: The attestation signature, in the form of a TPMT_SIGNATURE structure as specified in Part 2, Section 11.3.4 of [TPM2.0]. * _attestInfo_: The TPMS_ATTEST structure over which the above signature was computed, as specified in Part 2, Section 10.12.8 of [TPM2.0]. 6.1.2. Signing Procedure Generate a signature using the operation specified in Part 3, Section 18.4 of [TPM2.0], using the PAK as the signing key, the out- of-band agreed-upon PCR selection. Freshness of the attestation is given by the nonce provided by the relying party. The nonce is included as qualified data to the TPM2_Quote operation, concatenated with an identifier of the platform being attested, as shown below: _extraData_ = _platformUuid_ || _relyingPartyNonce_ The platform identifier is a 16-bytes long UUID, with the remaining data representing the nonce. The UUID is intended to help the verifier link the platform with its expected reference values. Tschofenig, et al. Expires 27 February 2023 [Page 14] Internet-Draft Attestation in TLS/DTLS August 2022 Set the _attestInfo_ field to the quoted PCR selection produced by the operation, and _sig_ to the signature generated above. 6.1.3. Verification Procedure The inputs to the verification procedure are as follows: * an attestation statement in the format described above * the nonce sent to the attester * a database of reference values for various platforms The steps for verifying the attestation: * Verify that the attestation token is a valid CBOR structure conforming to the CTAP2 canonical CBOR encoding form defined in Section 6 of [CTAP2], and perform CBOR decoding on it to extract the contained fields. * Verify that _alg_ describes a valid, accepted signing algorithm. * Verify that _x5c_ is present and follows the requirements laid out for _x5chain_ in [I-D.ietf-cose-x509]. * Verify the _sig_ is a valid signature over _attestInfo_ using the attestation public key in _pakCert_ with the algorithm specified in _alg_. * Verify that _pakCert_ meets the requirements in Section 8.3.1 of [WebAuthn]. * Verify that _attestInfo_ is valid: - Verify that _magic_ is set to TPM_GENERATED_VALUE. - Verify that _type_ is set to TPM_ST_ATTEST_QUOTE. - Verify that _attested_ contains a TPMS_QUOTE_INFO structure as specified in Part 2, Section 10.12.4 of [TPM2.0]. - Extract _extraData_ and parse it assuming the format defined above to obtain platform UUID and the nonce. Verify that the nonce is correct. - Verify that the platform UUID obtained earlier is valid and represents a platform found in the database. Tschofenig, et al. Expires 27 February 2023 [Page 15] Internet-Draft Attestation in TLS/DTLS August 2022 - Retrieve the reference values defined for this platform. Compute the digest of the concatenation of all relevant PCRs using the hash algorithm defined in _alg_. The PCRs are concatenated as described in "Selecting Multiple PCR" (Part 1, Section 17.5 of [TPM2.0]). Verify that this digest is equal to _pcrDigest_ in _attested_ and that the hash algorithm defined in _pcrSelect_ is aligned with the one in _alg_. - Note that the remaining fields in the "Standard Attestation Structure" (Part 1, Section 31.2 of [TPM2.0]), i.e., _qualifiedSigner_, _clockInfo_ and _firmwareVersion_ are ignored. These fields MAY be used as an input to risk engines. * If successful, return implementation-specific values representing attestation type AttCA and attestation trust path _x5c_. 6.2. Key Attestation Attesting to the provenance and properties of a key is possible through a TPM if the key resides on the TPM. The TPM 2.0 key attestation mechanism used in this specification is TPM2_Certify. The workflow for generating the evidence and assessing them, as well as the format used to transport them, follows closely the TPM Attestation Statement defined in Section 8.3 of [WebAuthn], with one modification: * For both signing and verification, _attToBeSigned_ is unnecessary and therefore its hash is replaced with the nonce coming from the relying party as the qualifying data when signing, and as the expected _extraData_ value during verification. The WebAuthn specification [WebAuthn] uses the term AIK to refer to the signing key. In this specification we use the term KAK instead. The credential (i.e., attested) key is in our case the TIK. 7. Security Considerations TBD. 8. IANA Considerations TBD: Create new registry for attestation types. 9. References 9.1. Normative References Tschofenig, et al. Expires 27 February 2023 [Page 16] Internet-Draft Attestation in TLS/DTLS August 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . 9.2. Informative References [CTAP2] World Wide Web Consortium, "Client to Authenticator Protocol", January 2019, . [I-D.ietf-cose-x509] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificates", Work in Progress, Internet-Draft, draft- ietf-cose-x509-08, 14 December 2020, . [I-D.ietf-rats-architecture] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote Attestation Procedures Architecture", Work in Progress, Internet-Draft, draft-ietf-rats-architecture- 21, 16 August 2022, . [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., and J. O'Donoghue, "The Entity Attestation Token (EAT)", Work in Progress, Internet- Draft, draft-ietf-rats-eat-14, 10 July 2022, . [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, . [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. Tschofenig, "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 2020, . Tschofenig, et al. Expires 27 February 2023 [Page 17] Internet-Draft Attestation in TLS/DTLS August 2022 [TPM1.2] Trusted Computing Group, "TPM Main Specification Level 2 Version 1.2, Revision 116", March 2011, . [TPM2.0] Trusted Computing Group, "Trusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59", November 2019, . [WebAuthn] World Wide Web Consortium, "Web Authentication: An API for accessing Public Key Credentials, Level 2", April 2021, . Appendix A. History RFC EDITOR: PLEASE REMOVE THE THIS SECTION * Initial version Appendix B. Working Group Information The discussion list for the IETF TLS working group is located at the e-mail address tls@ietf.org (mailto:tls@ietf.org). Information on the group and information on how to subscribe to the list is at https://www1.ietf.org/mailman/listinfo/tls (https://www1.ietf.org/mailman/listinfo/tls) Archives of the list can be found at: https://www.ietf.org/mail- archive/web/tls/current/index.html (https://www.ietf.org/mail- archive/web/tls/current/index.html) Authors' Addresses Hannes Tschofenig Arm Limited Email: hannes.tschofenig@arm.com Thomas Fossati Arm Limited Email: Thomas.Fossati@arm.com Paul Howard Arm Limited Email: Paul.Howard@arm.com Tschofenig, et al. Expires 27 February 2023 [Page 18] Internet-Draft Attestation in TLS/DTLS August 2022 Ionut Mihalcea Arm Limited Email: Ionut.Mihalcea@arm.com Yogesh Deshpande Arm Limited Email: Yogesh.Deshpande@arm.com Tschofenig, et al. Expires 27 February 2023 [Page 19]