]> Entrust Limited

2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Beyond Identity

USA monty.wiseman@beyondidentity.com

University of Applied Sciences Bonn-Rhein-Sieg

Hannes.Tschofenig@gmx.net

Nokia

Bangalore Karnataka India kondtir@gmail.com

Intel Corporation

USA ned.smith@intel.com

Security LAMPS Internet-Draft This document defines extensions for X.509 certificates to include attestation results as part of the certificate's content. The primary use case for these extensions is in the context of Certificate Signing Request (CSR) attestation, where claims about the trustworthiness of an Attester are conveyed to the Certification Authority (CA) as part of the CSR process. These extensions enable the CA to appraise the submitted evidence and embed attestation results into the issued certificate. This allows Relying Parties to evaluate the Attester's trustworthiness consistently and efficiently, supporting scalable policies for verification in environments with diverse attestation technologies.

Introduction Attestation mechanisms are increasingly used to verify the trustworthiness of devices and cryptographic keys. These mechanisms provide evidence that a device or key meets specific security criteria before being relied upon by an application. However, relying parties need a standardized way to access and validate these attestation results. This document introduces the Evidence Claims Certificate Extension, which enables Certification Authorities (CAs) to embed attestation results into issued X.509 certificates. By incorporating attestation results directly into certificates, Relying Parties can assess trustworthiness without requiring additional protocol interactions with external verifiers. This extension is particularly useful in environments where:

• Devices generate key pairs and request certificates while providing evidence of their security characteristics, such as key storage protection and tamper resistance.
• Certification Authorities evaluate and verify attestation claims before issuing a certificate.
• Relying Parties need a standardized way to verify the security characteristics of a key or the platform managing it, as stated in the certificate, without requiring real-time attestation checks, since these characteristics are relatively static.

While PKIX Key Attestation defines a mechanism for carrying attestation evidence within a CSR, this document extends that concept to X.509 certificates by defining a Certificate Evidence Claims extension. This extension allows attestation evidence to be embedded directly into an issued certificate, enabling Relying Parties to verify the security characteristics of a key or its platform without requiring access to the original CSR or real-time attestation. Additionally, this document defines the ASN.1 syntax for the Evidence Claims Certificate Extension and specifies how it should be included in X.509 certificates.

Example Data Flow demonstrating Attested CSR with Background Check Model. |----' '--->|--------------->| | | HSM | Evidence | Registration | CSR with | CA | | (Attester) | in CSR (1) | Authority | Attestation | | | | | (Relying Party) | Result (4) | | '------------' '-----------------' '-----' ^ ^ | | | X.509 Certificate with Attestation Result (5) | | +-----------------------------------------------------+ | | .-----------------. | TLS | | | (with mutual auth.) | Relying Party | +-------------------->| | (6) '-----------------' ]]>

Steps 1 to 4, covering the generation of evidence in a CSR, its verification by a Registration Authority, and the issuance of a CSR with an attestation result, are already specified in .

• Step 5: The CA issues an X.509 certificate embedding the attestation result within the Evidence Claims Certificate Extension.
• Step 6: The Relying Party uses TLS with mutual authentication to verify the certificate and its Evidence Claims, authenticating the Attester.

This ensures that the security characteristics of the key or platform are verifiable without requiring real-time attestation checks.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Certificate Extensions This section specifies the syntax and semantics of the Attestation Result Claims certificate extension, which provides a list of claims associated with the certificate subject appraised by the CA. The Attestation Result Claims certificate extension MAY be included in public key certificates . The Attestation Result Claims certificate extension MUST be identified by the following object identifier: This extension MUST NOT be marked critical. The Attestation Result Claims extension MUST have the following syntax: The AR-Claims field represents a sequence of attestation result claims (ReportedEntity) included by the CA in the certificate. It MUST contain at least one claim. For privacy reasons, the CA MAY choose to include only a subset of the claims from the Attestation Result it received from a Verifier. The CA may include in their certificate profile a list of verified evidence claims (identified by OID) that MAY be copied from the CSR to the certificate, while any other claims MUST NOT be copied. By removing the signature from the evidence, the CA is asserting that it has verified the Evidence to chain to a root that the CA trusts, but it is not required to disclose in the final certificate what that root is. See for a discussion of privacy concerns related to re-publishing Evidence into a certificate. The platform entity and key entity are relevant to the Evidence Claims Certificate Extension in the context of attesting to the security properties of a key or the platform that manages it.

id-pkix-attest-entity-platform (Platform Attestation)

• This attests that the platform hosting the key meets security requirements.
• Useful when the integrity of the system running cryptographic operations is important.
• Example: A certificate extension proving the FIPS level at which the attestor is currently operating in compliance with.

id-pkix-attest-entity-key (Key Attestation)

• This attests to the security properties of a specific cryptographic key, regardless of the platform.
• Ensures that the key is stored securely and follows cryptographic policies.
• Example: A certificate extension proving that the private key of the certificate is hardware-protected and cannot be exported to a software cryptographic module.

ASN.1 Module This section provides an ASN.1 Module for the Evidence Claims certificate extension, and it follows the conventions established in and .

Security Considerations The extension MUST NOT publish in the certificate any privacy-sensitive information that could compromise the end device. What counts as privacy-sensitive will vary by use case. For example:

1. HSM Usage: For a hardware security module (HSM) backing a public code-signing service, the model and firmware patch level could be considered sensitive as it could give an attacker an advantage in exploiting known vulnerabilities.
2. Mobile Devices: For a certificate issued to an end-user mobile computing device, any unique identifier could be used for tracking.
3. IoT Devices: For small IoT devices, knowing hardware and firmware version information could help edge gateways deny access to devices with known vulnerabilities.

The CA MUST have a configurable mechanism to control which information is copied from the provided Evidence into the certificate, for example, via a certificate profile or Certificate Practice Statement (CPS). CA operators should err on the side of caution and exclude unnecessary claims. Avoiding unnecessary claims also mitigates the risk of targeted attacks, where an attacker could exploit knowledge of hardware versions, models, etc.

IANA Considerations For the EvidenceClaims certificate extension in , IANA is requested to assign an object identifier (OID) for the certificate extension. The OID for the certificate extension should be allocated in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1). For the ASN.1 Module in , IANA is requested to assign an object identifier (OID) for the module identifier. The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. Security Theory LLC Mediatek USA Qualcomm Technologies Inc. Red Hound Software, Inc. An Entity Attestation Token (EAT) provides an attested claims set that describes state and characteristics of an entity, a device like a smartphone, IoT device, network equipment or such. This claims set is used by a relying party, server or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with attestation-oriented claims. Entrust Limited Crypto4A Inc. University of Applied Sciences Bonn-Rhein-Sieg Fraunhofer SIT Beyond Identity Intel Corporation This document specifies a vendor-agnostic format for attesting to the protection properties of a symmetric or asymmetric cryptographic key within a hardware cryptographic module to support applications such as providing evidence to a Certification Authority that a key is being protected in accordance with the requested certificate profile, or that HSMs can perform key import and maintain the private key protection properties in a robust way even when migrating keys across HSM vendors. This specification includes a format for requesting a key attestation containing certain attributes. This specification is called "PKIX Attestation" because it is designed to be easy to implement on top of a code base that already supports X.509 and PKCS#11 data models. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCNs). CCNinfo investigates 1) the CCN routing path information per name prefix, 2) the Round-Trip Time (RTT) between the content forwarder and the consumer, and 3) the states of in-network cache per name prefix. CCNinfo is useful to understand and debug the behavior of testbed networks and other experimental deployments of CCN systems. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG). This document represents the consensus view of ICNRG and has been reviewed extensively by several members of the ICN community and the RG. The authors and RG chairs approve of the contents. The document is sponsored under the IRTF, is not issued by the IETF, and is not an IETF standard. This is an experimental protocol and the specification may change in the future. The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates some auxiliary ASN.1 modules to conform to the 2008 version of ASN.1; the 1988 ASN.1 modules remain the normative version. There are no bits- on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.

Acknowledgments The authors would like to thank ...