]> Cryptic Forest Software

Sioux Lookout, Ontario Canada mike@ounsworth.ca

Siemens

Germany Hannes.Tschofenig@gmx.net

Fraunhofer SIT

Rheinstrasse 75 Darmstadt 64295 Germany henk.birkholz@sit.fraunhofer.de

United States mwiseman@computer.org

United States ned.smith.ietf@gmail.com

PKI PKCS#10 CRMF Attestation Certificate Signing Requests Certification Authorities (CAs) issuing certificates to Public Key Infrastructure (PKI) end entities may require a certificate signing request (CSR) to include additional verifiable information to confirm policy compliance. For example, a CA may require an end entity to demonstrate that the private key corresponding to a CSR's public key is secured by a hardware security module (HSM), is not exportable, etc. The process of generating, transmitting, and verifying additional information required by the CA is called remote attestation. While work is currently underway to standardize various aspects of remote attestation, a variety of proprietary mechanisms have been in use for years, particularly regarding protection of private keys. This specification defines ASN.1 structures which may carry attestation data for PKCS#10 and Certificate Request Message Format (CRMF) messages. Both standardized and proprietary attestation formats are supported by this specification. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Certification Authorities (CAs) issuing certificates to PKI end entities may require a certificate signing request (CSR) include verifiable attestations that contain claims regarding the platform used by the end entity to generate the key pair for which a certificate is sought and also contains claims of attributes of the key pair with respect to its protection, use and extractability. At the time of writing, the most pressing example of the need for remote attestation in certificate enrollment is the Code-Signing Baseline Requirements (CSBR) document maintained by the CA/Browser Forum . The requires compliant CAs to "ensure that a Subscriber's Private Key is generated, stored, and used in a secure environment that has controls to prevent theft or misuse". This requirement is a natural fit to enforce via remote attestation. This specification defines an attribute and an extension that allow for conveyance of verifiable attestations in several Certificate Signing Request (CSR) formats, including PKCS#10 or Certificate Request Message Format (CRMF) messages. Given several standard and proprietary remote attestation technologies are in use, this specification is intended to be as technology-agnostic as is feasible with respect to implemented and future remote attestation technologies. This aligns with the fact that a CA may wish to provide support for a variety of types of devices but cannot dictate what format a device uses to represent attestations. However, if a certificate requester does not include the number and types of attestations required by the CA, it is unlikely the requester will receive the requested certificate. While CSRs are defined using Abstract Syntax Notation One (ASN.1), attestations may be defined using any data description language, i.e., ASN.1 or Concise Data Description Language (CDDL), or represented using any type of encoding, including Distinguished Encoding Rules (DER), Concise Binary Object Representation (CBOR), JavaScript Object Notation (JSON). This specification RECOMMENDS that attestations that are not encoded using the Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER) be wrapped in an ASN.1 OCTET STRING.

Relationship to the IETF RATS Working Group As noted, attestation-related technologies have existed for many years, albeit with no standard format and no standard means of conveying attestation statements to a CA. This draft addresses the latter, and is equally applicable to standard and proprietary attestation formats. The IETF Remote Attestation Procedures (RATS) working group is addressing the former. In , RATS defined vocabulary, architecture, and usage patterns related to the practice of generating and verifying attestations. In its simplest topological model, attestations are generated by the certificate requester and verified by the CA/RA. Section 5 of defines topological patterns that are more complex, including the background check model and the passport model. This document may be applied to instantiating any of these topological models for CSR processing, provided the required security requirements specific to the context of certificate issuance are satisfied. defines several roles that originate, forward or process attestation statements (also see ): the Attester; Endorser; Relying Party; and Verifier. Attestation statements, such as Evidence, may be directed to an entity taking at least one of these roles, including to an CA/RA acting as a Verifier. An CA/RA may also forward attestation statements to a Verifier for appraisal. Each attestation statements may contain one or more claims, including claims that may be required by an RA or CA. Attestation statements transmitted by these parties are defined in as the "conceptual messages" Evidence, Endorsement, and Attestation Results. The structure defined in this specification may be used by any of the roles that originate attestation statements, and is equally applicable to these three conceptual messages.

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. This document re-uses the terms defined in related to remote attestation. Readers of this document are assumed to be familiar with the following terms defined in : Evidence, Endorsement, Claim, Attestation Result (AR), Attester, Relying Party, and Verifier. Per , the CA/RA is the Relying Party with respect to remote attestation. This use of the term "relying party" differs from the traditional PKIX use of the term. This specification uses CA/RA to refer to an Relying Party, which may or may not include an integrated Verifier. The term "Certification Request" message is defined in . Specifications, such as , later introduced the term "Certificate Signing Request (CSR)" to refer to the Certification Request message. While the term "Certification Request" would have been correct, the mistake was unnoticed. In the meanwhile CSR is an abbreviation used beyond PKCS#10. Hence, it is equally applicable to other protocols that use a different syntax and even a different encoding, in particular this document also considers messages in the Certificate Request Message Format (CRMF) to be "CSRs". In this document, the terms "CSR" and Certificate Request message are used interchangeably. The term "hardware security module (HSM)" is used generically to refer to the combination of hardware and software designed to protect keys from unauthorized access. Other commonly used terms include Secure Element, Trusted Platform Module, and Trusted Execution Environment. Since this document combines terminology from two domains, Remote Attestation (RATS) and X.509 PKI, it follows a naming convention to avoid ambiguity. RATS terminology is written in uppercase (e.g., Verifier), while X.509/PKI terminology is written in lowercase (e.g., certification authority (CA)). This distinction clarifies terms that exist in both domains; for instance, a Verifier refers to the RATS entity that processes Evidence, whereas a verifier refers to the PKI entity that validates certificates. This convention is distinct from camel-case identifiers like "AttestationStatement", which denote ASN.1 types.

Conveying Attestations in CSRs The focus of this specification is the conveyance of attestations to a CA/RA as part of a CSR. The following sub-sections define formats to support this conveyance, an optional mechanism to limit support to specific attestation types at the ASN.1 level, and bindings to the attribute and extension mechanisms used in certificate managment protocols.

AttestationStatement and AttestationBundle The AttestationStatement structure (as shown in ) facilitates the representation of Evidence, Endorsements, and Attestation Results generated by an Attester, Endorser, or Verifier for processing by a Verifier or Relying Party, such as verification by a CA/RA.

• The type field is an OBJECT IDENTIFIER that identifies the format of the stmt field.
• The stmt field contains the attestation for processing, constrained by the type field. Formats that are not defined using ASN.1 MUST define an ASN.1 wrapper for use with the AttestationStatement structure. For example, a CBOR-encoded format may be defined as an OCTET STRING for AttestationStatement purposes, where the contents of the OCTET STRING are the CBOR-encoded data.

Definition of AttestationStatement

In some cases, a CA may require CSRs to include a variety of claims, which may require the cooperation of more than one Attester. Similarly, a CA/RA may outsource verification of claims from different Attesters to a single Verifier. The AttestationBundle structure, , facilitates the representation of one or more AttestationStatement structures along with an OPTIONAL collection of certificates that may be useful for certification path building and validation to verify each AttestationStatement. AttestationBundle is the structure included in a CSR attribute or extension.

Definition of AttestationBundle

At least one element in the attestations field SHOULD contain an attestation that is cryptographically bound to the public key that is the subject of the CSR containing the AttestationBundle. The CertificateChoices structure defined in , and reproduced below along with OtherCertificateFormat, allows for carrying certificates in the default X.509 format, or in other non-X.509 certificate formats. CertificateChoices MUST only contain certificate or other. In this context, CertificateChoices MUST NOT contain extendedCertificate, v1AttrCert, or v2AttrCert. Note that for non-ASN.1 certificate formats, the CertificateChoices MUST contain other with an OTHER-CERT-FMT.Type of OCTET STRING and data consistent with OTHER-CERT-FMT.id. LimitedCertChoices is defined to limit the available options to certificate and other. The certs field contains a set of certificates that may be used to validate an AttestationStatement contained in attestations. For each AttestationStatement, the set of certificates SHOULD contain the certificate that contains the public key needed to directly validate the AttestationStatement, unless the signing key is expected to be known to the Verifier or is embedded within the AttestationStatement. Additional certificates MAY be provided, for example, to chain the attestation key back to a trust anchor. No specific order of the certificates in certs should be expected because certificates contained in certs may be needed to validate different AttestationStatement instances. This specification places no restriction on mixing certificate types within the certs field. For example a non-X.509 attestation signer certificate MAY chain to a trust anchor via a chain of X.509 certificates. It is up to the Attester and its Verifier to agree on supported certificate formats.

AttestationStatementSet

Definition of AttestationStatementSet

The expression illustrated in maps ASN.1 Types for attestation statements to the OIDs that identify them. These mappings are used to construct or parse AttestationStatement objects that appear in an AttestationBundle. Attestation statements are typically defined in other IETF standards, in standards produced by other standards bodies, or as vendor proprietary formats along with corresponding OIDs that identify them. AttestationStatementSet is left unconstrained in this document. However, implementers MAY populate it with the formats that they wish to support.

CSR Attribute and Extension By definition, attributes within a PKCS#10 CSR are typed as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION.

Definitions of CSR attribute and extension

The Extension variant illustrated in is intended only for use within CRMF CSRs and is NOT RECOMMENDED to be used within X.509 certificates due to the privacy implications of publishing information about the end entity's hardware environment. Multiple different types of AttestationStatement(s) may be included within a single top-level AttestationBundle. Note that this document does not require the AttestationBundle.attestations field to contain only one AttestationStatement of a given type. For example, if a given type is a "wrapper" type containing the conceptual message wrapper (CMW) structure , multiple copies of a CMW-typed AttestationStatement may be included. Per no more than one instance of a given type of Extension may be carried within an Extensions structure, so an Extensions structure MUST contain no more than one Extension of type id-aa-attestation. PKCS#10 uses the legacy structures Attributes and Attribute rather than the later defined SingleAttribute and AttributeSet structures - all of which are defined against the ATTRIBUTE ASN.1 CLASS. The ATTRIBUTE CLASS has a COUNTS MAX n clause which can be used to limit the copies of ATTRIBUTE related structures. For the purposes of this document the COUNTS MAX 1 clause in the attr-attestation shall be taken to mean the following:

• An Attributes structure carried within a PKCS#10 CSR MUST contain no more than one Attribute of type id-aa-attestation.
• An Attribute of type id-aa-attestation MUST contain exactly one copy of an AttestationBundle.

When multiple Verifiers support the same attestation‑format OID, ambiguity can arise in routing attestations to the appropriate Verifier. Resolving that ambiguity is outside the scope of this document and must be defined by the attestation‑format specification, particularly for opaque (wrapper) formats. Two pragmatic approaches are recommended: (1) assign distinct OIDs for different verifier or verification types even when the underlying format structure is identical, or (2) encapsulate the opaque attestation object in a wrapper that carries an explicit hint. Implementations should adopt one of these approaches and attestation‑format specifications should mandate the precise mechanism for nonce selection and routing of attestations.

IANA Considerations IANA is requested to allocate a value from the "SMI Security for PKIX Module Identifier" registry for the included ASN.1 module, and to allocate a value from "SMI Security for S/MIME Attributes" to identify an attribute defined within.

Module Registration - SMI Security for PKIX Module Identifier IANA is asked to register the following within the registry id-mod SMI Security for PKIX Module Identifier (1.3.6.1.5.5.7.0).

• Decimal: IANA Assigned - Replace TBDMOD
• Description: CSR-ATTESTATION-2025 - id-mod-pkix-attest-01
• References: This Document

Object Identifier Registrations - SMI Security for S/MIME Attributes IANA is asked to register the following within the registry id-aa SMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2).

• Attestation Statement
• Decimal: IANA Assigned - Note: .59 has already been early-allocated as "id-aa-evidence" referencing this document, so the request is to change the name of this entry to "id-aa-attestation" and leave the allocation of .59 as-is.
• Description: id-aa-attestation
• References: This Document

Security Considerations This document defines a structure to convey attestations as additional information in CSRs, as well as an attribute to convey that structure in the Certification Request Message defined in {} and an extension to convey that structure in the Certificate Request Message Format defined in {}. The CA/RA that receives the CSR may choose to verify the attestation(s) to determine if an issuance policy is met, or which of a suite of policies is satisfied. The CA/RA is also free to discard the additional information without processing. A CA which accepts or requires attestation(s) SHOULD document its requirements with its Certification Practice Statement(s). The remainder of this section identifies security considerations that apply when the CA/RA chooses to verify the attestation as part of the evaluation of a CSR.

Binding Attestations to the CSR's Public Key Regardless of the topological model, the CA/RA is ultimately responsible for validating the binding between the public key and the attestation(s) in the CSR. For CAs issuing in conformance with the CA/Browser Forum's Code Signing Baseline Requirements, this means verifying the attestation of HSM generation and protection is cryptographically bound to the public key in the CSR. Multiple attestations from multiple sources, as envisioned in , can introduce additional complications as shown in the following example. For example, a CA may have an issuance policy that requires key generation in an HSM on a company-owned platform in a known good state. The CSR might contain three AttestationStatements originated by three different attesters:

1. that a key pair was generated in an HSM;
2. that a particular platform is company-owned; and
3. that a particular platform was in a known good state (e.g, up to date on patches, etc.).

While each of these attestations may be independently correct, the CA/RA is responsible for confirming the attestations apply in concert to the public key in the CSR. That is, the CA/RA must analyze the attestations to ensure that:

1. the attestation of HSM generation by AttestationStatement 1 applies to the public key in the CSR;
2. the attestation of company ownership by AttestationStatement 2 applies to the platform that contains the HSM; and
3. the attestation that a platform was in a known good state by AttestationStatement 3 applies to the platform that contains the HSM.

Freshness To avoid replay attacks, the CA/RA may choose to ignore attestations that are stale, or whose freshness cannot be determined. Mechanisms to address freshness and their application to the RATS topological models are discussed in . Other mechanisms for determining freshness may be used as the CA/RA deems appropriate. When CSRs are embedded within certificate management protocols such as EST or CMP, these protocols can supply the Attester with a nonce. Further details are specified in .

Relationship of Attestations and Certificate Extensions Attestations are intended as additional information in the issuance process, and may include sensitive information about the platform, such as hardware details or patch levels, or device ownership. It is NOT RECOMMENDED for a CA to copy attestations into the published certificate. CAs that choose to republish attestations in certificates SHOULD review the contents and delete any sensitive information.

Additional Security Considerations In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on which this specification depends: PKCS#10 , CRMF , as well as general security concepts relating to remote attestation; many of these concepts are discussed in , , , , and . Implementers should also be aware of any security considerations relating to the specific attestation formats being carried within the CSR.

References Normative References 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. 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. 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 the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. [STANDARDS-TRACK] This memo represents a republication of PKCS #10 v1.7 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series, and change control is retained within the PKCS process. The body of this document, except for the security considerations section, is taken directly from the PKCS #9 v2.0 or the PKCS #10 v1.7 document. This memo provides information for the Internet community. 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 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. 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 Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during remote attestation procedures. Conceptual Messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of Conceptual Messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated CBOR tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. This allows CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts like X.509 certificates. Additionally, the draft defines a media type and a CoAP content format to transport CMWs over protocols like HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, evolving message serialization formats without breaking compatibility, and avoiding the need to redefine how messages are handled within each protocol. Siemens Siemens AKAYLA, Inc. sn3rd When an end entity includes attestation statements in a Certificate Signing Request (CSR), this document is specifically concerned with establishing the freshness of Evidence statements among that attestation data. 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), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC). This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA. This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. CA/Browser Forum n.d.

Examples Examples and sample data will be collected in the "CSR Attestation Sample Data" GitHub repository .

ASN.1 Module

Acknowledgments This specification is the work of a design team created by the chairs of the LAMPS working group. We would like to specifically thank Mike StJohns for writing initial version of this draft and for his substantial work on the final version. The following persons, in no specific order, contributed to the work directly, participated in design team meetings, or provided review of the document. Richard Kettlewell, Chris Trufan, Bruno Couillard, Jean-Pierre Fiset, Sander Temme, Jethro Beekman, Zsolt Rózsahegyi, Ferenc Pető, Mike Agrenius Kushner, Tomas Gustavsson, Dieter Bong, Christopher Meyer, Carl Wallace, Michael Richardson, Tomofumi Okubo, Olivier Couillard, John Gray, Eric Amador, Giri Mandyam, Darren Johnson, Herman Slatman, Tiru Reddy, James Hagborg, A.J. Stein, John Kemp, Daniel Migault and Russ Housley. Additionally, we would like to thank Andreas Kretschmer, Hendrik Brockhaus, David von Oheimb, Corey Bonnell, and Thomas Fossati for their feedback based on implementation experience. Close to the end of the specification development process, the working group chairs, Russ Housley and Tim Hollebeek, reached out to Steve Hanna, Tim Polk, and Carl Wallace to help improve the document and resolve contentious issues. Their contributions substantially impacted the final outcome of the document.