RATS J.-P. Fiset Internet-Draft Crypto4A Intended status: Standards Track M. Ounsworth Expires: 1 January 2027 Cryptic Forest H. Tschofenig UniBw M. H. Birkholz Fraunhofer SIT M. Wiseman N. Smith 30 June 2026 Evidence Encoding for Hardware Security Modules draft-ietf-rats-pkix-key-attestation-06 Abstract This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. This specification also offers a format for requesting a cryptographic module to produce Evidence tailored for expected use. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ietf-rats- wg.github.io/key-attestation/draft-ietf-rats-pkix-key- attestation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-rats-pkix-key- attestation/. Fiset, et al. Expires 1 January 2027 [Page 1] Internet-Draft Evidence Encoding for HSMs June 2026 Discussion of this document takes place on the RATS Working Group mailing list (mailto:rats@ietf.org), which is archived at https://datatracker.ietf.org/wg/rats/about/. Subscribe at https://www.ietf.org/mailman/listinfo/rats/. Source for this draft and an issue tracker can be found at https://github.com/ietf-rats-wg/key-attestation. 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 1 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Remote audit of a Hardware Security Module (HSM) . . . . 4 2.2. Key import and HSM clustering . . . . . . . . . . . . . . 5 2.3. Attesting subject of a certificate issuance . . . . . . . 5 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 6 3.1. Claims and measurements in generated Evidence . . . . . . 9 Fiset, et al. Expires 1 January 2027 [Page 2] Internet-Draft Evidence Encoding for HSMs June 2026 3.2. Attestation Key Certificate Chain . . . . . . . . . . . . 9 4. Information Model . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Element . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Element Type . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Claim Type . . . . . . . . . . . . . . . . . . . . . . . 12 5. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Platform Element . . . . . . . . . . . . . . . . . . . . 17 5.1.1. vendor . . . . . . . . . . . . . . . . . . . . . . . 19 5.1.2. oemid, hwmodel, hwversion, swname, swversion, dbgstat, uptime, bootcount . . . . . . . . . . . . . . . . . . 19 5.1.3. hwserial . . . . . . . . . . . . . . . . . . . . . . 20 5.1.4. fipsboot, fipsver, fipslevel and fipsmodule . . . . . 20 5.2. Key Element . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. identifier . . . . . . . . . . . . . . . . . . . . . 22 5.2.2. spki . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.3. extractable, sensitive, never-extractable, local . . 23 5.2.4. expiry . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.5. purpose . . . . . . . . . . . . . . . . . . . . . . . 23 5.3. Transaction Element . . . . . . . . . . . . . . . . . . . 25 5.3.1. nonce . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3.2. timestamp . . . . . . . . . . . . . . . . . . . . . . 26 5.3.3. ak-spki . . . . . . . . . . . . . . . . . . . . . . . 26 5.4. Additional Element and Claim Types . . . . . . . . . . . 26 5.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Signing and Verification Procedures . . . . . . . . . . . . . 27 7. Attestation Requests . . . . . . . . . . . . . . . . . . . . 28 7.1. Requested Claims with Specified Values . . . . . . . . . 31 7.1.1. Key Identifiers . . . . . . . . . . . . . . . . . . . 31 7.1.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . 32 7.1.3. Reporting of Attestation Keys . . . . . . . . . . . . 32 7.1.4. Custom Key Selection . . . . . . . . . . . . . . . . 32 7.1.5. Custom Transaction Element Claims . . . . . . . . . . 33 7.2. Processing an Attestation Request . . . . . . . . . . . . 33 7.3. Verification by Presenter . . . . . . . . . . . . . . . . 34 8. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 34 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 10.1. Policies relating to Verifier and Relying Party . . . . 42 10.2. Simple to Implement . . . . . . . . . . . . . . . . . . 43 10.3. Detached Signatures . . . . . . . . . . . . . . . . . . 43 10.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 44 10.5. Authenticating and Authorizing the Presenter . . . . . . 45 10.6. Proof-of-Possession of User Keys . . . . . . . . . . . . 46 10.7. Timestamps and HSMs . . . . . . . . . . . . . . . . . . 46 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 11.1. Normative References . . . . . . . . . . . . . . . . . . 47 11.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. Samples . . . . . . . . . . . . . . . . . . . . . . 49 Fiset, et al. Expires 1 January 2027 [Page 3] Internet-Draft Evidence Encoding for HSMs June 2026 A.1. Simple Platform Evidence . . . . . . . . . . . . . . . . 50 A.2. Key Attestation Evidence . . . . . . . . . . . . . . . . 52 A.3. Multi-HSM and Multi-Tenant Key Attestation Evidence . . . 55 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 1. Introduction This document specifies a vendor-neutral Evidence format for remote attestation in PKIX-based environments, with a focus on hardware security modules (HSMs) and cryptographic keys managed by such devices. The format enables an Attester to convey measured platform and key properties to a Verifier and, ultimately, to a Relying Party in a form that integrates with existing X.509-based trust infrastructures. Concretely, this specification defines: * an ASN.1/DER Evidence envelope containing a to-be-signed section, one or more signature blocks, and optional intermediate certificates; * an element-and- claim data model organized around transaction, platform, and key elements, identified by OIDs; * encoding and signature-verification processing rules for PKIX Evidence; * an attestation request structure that allows a Presenter to request a scoped subset of elements and claims. The design is intentionally PKIX-native. ASN.1 and DER are used to align with existing certificate tooling, certification authority workflows, and HSM implementations where non-ASN.1 formats are less common. This document does not define a transport protocol for carrying Evidence, does not define Verifier appraisal policy, and does not standardize device-internal authentication/authorization mechanisms. It defines the data model and cryptographic container so that such mechanisms can be applied consistently across deployments. 2. Use Cases This section covers use cases that motivated the development of this specification. 2.1. Remote audit of a Hardware Security Module (HSM) There are situations where it is necessary to verify the current running state of an HSM as part of operational or auditing procedures. For example, there are devices that are certified to work in an environment only if certain versions of the firmware are loaded or only if user keys are protected with specific policies. Fiset, et al. Expires 1 January 2027 [Page 4] Internet-Draft Evidence Encoding for HSMs June 2026 The Evidence format offered by this specification allows a platform to report its firmware level along with other collected claims necessary in critical deployments. 2.2. Key import and HSM clustering Consider that an HSM is being added to a logical HSM cluster. Part of the onboarding process could involve the newly-added HSM providing Evidence of its running state, for example that it is a genuine device from the same manufacturer as the existing clustered HSMs, firmware patch level, FIPS mode, etc. It could also be required to provide information about any system-level keys required to establish secure cluster communication. In this scenario, the Verifier and Relying Party will typically be other HSMs in the cluster deciding whether or not to admit the new HSM. A related scenario is when performing a key migration across HSMs. If the key is being migrated is associated with certain properties, for example an environment running in FIPS mode at FIPS Level 3, and the key is set to certain protection properties such as Non- Exportable and Dual-Control, then the HSM might wish to verify that the key was previously stored under the same conditions. This specification provides an Evidence format with sufficient details to support this type of implementation across HSM vendors. These scenarios motivate the design requirements to have an ASN.1 based Evidence format and a data model that more closely matches typical HSM architecture since, as shown in both scenarios, an HSM is acting as Verifier and Relying Party. 2.3. Attesting subject of a certificate issuance Prior to a Certification Authority (CA) issuing a certificate on behalf of a subject, a number of procedures are required to verify that the subject of the certificate is associated with the key that is certified. In some cases, such as issuing a code signing certificate [CNSA2.0] [CSBR], a CA must ensure that the subject key is located in a Hardware Security Module (HSM). The Evidence format offered by this specification is designed to carry the information necessary for a CA to assess the location of the subject key along a number of commonly-required attributes. More specifically, a CA could determine which HSM was used to generate the subject key, whether this device adheres to certain jurisdiction policies (such as FIPS mode) and the constraints applied to the key (such as whether is it extractable). Fiset, et al. Expires 1 January 2027 [Page 5] Internet-Draft Evidence Encoding for HSMs June 2026 For relatively simple HSM devices, storage properties such as "extractable" may always be false for all keys since the devices are not capable of key export and so the Evidence could be essentially a hard-coded template asserting these immutable attributes. However, more complex HSM devices require a more elaborate Evidence format that encompasses the mutability of these attributes. Also, a client requesting a key attestation might wish to scope-down the content of the produced Evidence as the HSM contains much more information than that which is relevant to the transaction. Not reducing the scope of the generated Evidence could, in some scenarios, constitute a privacy violation. 3. 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This specification uses a necessary mixture of PKI terminology and RATS Architecture definitions in order to map concepts between the two domains. The reader is assumed to be familiar with the vocabulary and concepts defined in the RATS Architecture ([RFC9334]) such as Attester, Relying Party, Verifier. The reader is assumed to be familiar with common vocabulary and concepts defined in [RFC5280] such as certificate, signature, attribute, verification and validation. In order to avoid confusion, this document generally capitalizes RATS terms such as Attester, Relying Party, and Claim. Therefore, for example, a "Verifier" should be assumed to be an entity that checks the validity of Evidence as per [RFC9334], whereas a "verifier" could be a more general reference to a PKI entity that checks the validity of an X.509 certificate or other digital signature as per [RFC5280]. The following terms are used in this document: Attestation Key (AK): Cryptographic key controlled solely by the Attester and used only for the purpose of producing Evidence. In other words, it is used to digitally sign the claims collected by the Attester. Attester: Fiset, et al. Expires 1 January 2027 [Page 6] Internet-Draft Evidence Encoding for HSMs June 2026 The term Attester respects the definition offered in [RFC9334]. In this specification, it is also interchangeable with "platform" or "HSM". Attesting Environment: As defined in [RFC9334], the Attesting Environment collects the information to be represented in Claims. In practical terms, an implementation may be designed with services to perform this function. To remain consistent with the RATS Architecture, the term "Attesting Environment" is used throughout this specification. Evidence: The term Evidence respects the definition offered in [RFC9334]. In this specification, it refers to claims, encoded according to the format defined within this document, and signed using Attestation Keys. Hardware Security Module (HSM): A physical computing device that safeguards and manages secrets, such as cryptographic keys, and performs cryptographic operations based on those secrets. This specification takes a broad definition of what counts as an HSM to include smartcards, USB tokens, TPMs, cryptographic co-processors (PCI cards) and "enterprise-grade" or "cloud-service grade" HSMs (possibly rack mounted). In this specification, it is interchangeable with "platform" or "Attester". Key Attestation: Process of producing Evidence containing claims pertaining to user keys found within an HSM. In general, the claims include enough information about a user key and its hosting platform to allow a Relying Party to make judicious decisions about the key, such as whether to issue a certificate for the key. RATS: Remote ATtestation procedureS. Refers to a working group within IETF and all the documents developed under this umbrella of efforts. This specification is developed using concepts developed in RATS but more particularly refers to the RATS Architecture as introduced in [RFC9334]. PKIX: Public Key Infrastructure based on X.509 certificates. Refers to the framework of technology, policies and procedures used to manage and distribute digital certificates based on [RFC5280] and related specifications. Fiset, et al. Expires 1 January 2027 [Page 7] Internet-Draft Evidence Encoding for HSMs June 2026 Platform: The module or device that embodies the Attester. In this specification, it is interchangeable with "Attester" or "HSM". Platform Attestation: Process of producing evidence containing claims pertaining to measured values associated with the platform itself. In general, the claims include enough information about the platform to allow a Relying Party to make judicious decisions about the platform, such as those carried out during audit reviews. Presenter: Role that facilitates communication between the Attester and the Verifier. The Presenter initiates the operation of generating Evidence at the Attester and passes the generated Evidence to the Verifier. In the case of HSMs, the Presenter is responsible of selecting the claims that are part of the generated Evidence. Trust Anchor: As defined in [RFC6024] and [RFC9019], a Trust Anchor "represents an authoritative element via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The Trust Anchor may be a certificate, a raw public key, or other structure, as appropriate. Trusted Platform Module (TPM): A tamper-resistant processor generally located on a computer's motherboard used to enhance attestation functions for the hosting platform as defined by the Trusted Computer Group. TPMs are very specialized Hardware Security Modules and generally use other protocols (than the one presented in this specification) to transmit Evidence. User Key: A user key consists of a key hosted by an HSM (the platform) and intended to be used by a client of the HSM. Other terms used for a user key are "application key", "client key" or "operational key". The access and operations on a user key are controlled by the HSM. Fiset, et al. Expires 1 January 2027 [Page 8] Internet-Draft Evidence Encoding for HSMs June 2026 3.1. Claims and measurements in generated Evidence The RATS Architecture [RFC9334] states that Evidence is made up of claims and that a claim is "a piece of asserted information, often in the form of a name/value pair". The RATS Architecture also mentions the concept of "measurements" that "can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc., and how they are hardened." Some HSMs have a large amount of memory and can therefore contain a substantial amount of elements that can be observed independently by the Attesting Environment. Each of those elements, in turn, can contain a number of measurable attributes. A certain level of complexity arises as multiple elements of the same class can be reported simultaneously in generated Evidence. In this case, multiple similar claims are reported simultaneously but associated with different elements. For example, two independent user keys could be reported simultaneously in Evidence. Each key is associated with a SPKI (SubjectPublicKeyInfo). The measured values for the SPKI of the respective keys are different. To that end, in this specification, the claims are organized as collections where each claim is the association of a claim type with the measured value. The collections, in turn, are organized by "elements". An element represents a logical portion of the Target Environment that is observed by the Attesting Environment. Thus, an element is associated with a collection of claims. Each claim is the association of a claim type with a measured value. The grouping of claims into elements facilitates the comprehension of a large addressable space into portions recognizable by the user. More importantly, it curtails the produced Evidence to portions of the Target Environment that relate to the needs of the Verifier. See Section 10.4. 3.2. Attestation Key Certificate Chain The data format in this specification represents Evidence and requires third-party endorsement in order to establish trust. Part of this endorsement is a trust anchor that chains to the HSM's attestation key (AK) which signs the Evidence. In practice the trust anchor usually is a manufacturing CA belonging to the device vendor which proves that the device is genuine and not counterfeit. The trust anchor can also belong to the device operator as would be the Fiset, et al. Expires 1 January 2027 [Page 9] Internet-Draft Evidence Encoding for HSMs June 2026 case when the AK certificate is replaced as part of onboarding the device into a new operational environment. The AK certificate associated with the AK that signs the evidence have the following constraints: * the certificate MUST include the Extended Key Usage (EKU) certificate extension; * the EKU certificate extension MUST include the id-kp- attestationKey, as defined in this specification; and, * the KeyUsage extension (KU) MUST have the digitalSignature bit set. An EKU that includes only a single KeyPurposeId of id-kp- attestationKey SHOULD be marked as critical. The reasoning here is that the usage of a true attestation key is constrained by the security module it's contained by. Presenting non-attestation data for validation by this AK public key should ALWAYS fail. An EKU that includes a KeyPurposeId of id-kp-attestationKey along with other attestation-related KeyPurposeId SHOULD NOT be marked as critical. Note that the data format specified in Section 5 allows for zero, one, or multiple 'SignatureBlock's, so a single Evidence statement could be un-protected, or could be endorsed by multiple AK chains leading to different trust anchors. See Section 6 for a discussion of handling multiple SignatureBlocks. 4. Information Model The Evidence format is composed of two main sections: * An Evidence description which describes the list of reported elements. * A signature section where one or more digital signatures are offered to prove the origin of the Evidence description and maintain its integrity. The details of the signature section is left to the data model. The remainder of this section deals with the way the information is organized to form the Evidence description. Fiset, et al. Expires 1 January 2027 [Page 10] Internet-Draft Evidence Encoding for HSMs June 2026 The Evidence description is associated with elements to help with the organization and comprehension of the information. Elements are portions of the Target Environment observed by the Attesting Environment. Each element, in turn, is associated with a collection of claims that describes the attributes of the element. Therefore, the Evidence description is composed of a set of elements and each element is composed of a claim set. 4.1. Element An element is a logical construct that refers to a portion of the Target Environment's state. It is addressable via an identifier such as a UUID or a handle (as expressed in [PKCS11]). In general, an element refers to a component recognized by users of the HSM, such as a user key or the platform itself. An element is composed of a type, the element type, and a collection of claims. The element type describes the class of the element while the collection of claims defines its state. An element MUST be reported at most once in an Evidence description. The Evidence description can have multiple elements of the same type (for example reporting multiple keys), but each element MUST relate to different portions of the Target Environment. It is possible for two elements to be quite similar such as in a situation where a key is imported twice in a HSM. In this case, the two related elements could be associated with similar claims. However, they are treated as different elements as they are reporting different portions of the Target Environment. The number of elements reported in an Evidence description, and their respective type, is left to the implementer. For a simple device where there is only one key, the list of reported elements could be fixed. For larger and more complex devices, the list of reported elements should be tailored to what is demanded by the Presenter. In particular, note that the nonce claim contained with the Transaction element is optional, and therefore it is possible that an extremely simple device that holds one static key could have its Evidence generated at manufacturing time and injected statically into the device instead of being generated on-demand. This model would essentially off-board the Attesting Environment to be part of the manufacturing infrastructure. In the RATS Architecture, this configuration would refer to the the information provided this way as an Endorsement provided by the manufacturer as opposed to Evidence generated by the HSM. Fiset, et al. Expires 1 January 2027 [Page 11] Internet-Draft Evidence Encoding for HSMs June 2026 4.2. Element Type An element is defined by its type. This specification defines three element types: * Platform : This element holds claims that describes the state of the platform (or device) itself. Elements of this type hold claims that are global in nature within the Target Environment. * Key : The elements of this type represent a cryptographic key protected within the Target Environment and hold claims that describes that specific key. * Transaction : This element is