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

USA mwiseman32@acm.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 an ASN.1 structure for remote attestation that can accommodate proprietary and standardized attestation mechanisms, as well as an attribute and an extension to carry the structure in PKCS#10 and Certificate Request Message Format (CRMF) messages, respectively. 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) to 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. 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. 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 RA/CA acting as a Verifier. An RA/CA 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 RA/CA 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 RA/CA 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 bindsPublicKey field indicates whether the attestation in the stmt field is cryptographically bound to the public key included in the CSR.
• 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.
• The attrs field enables the inclusion of Attribute values that may inform the verification of the stmt. This specification does not define any Attribute instances.
• The attrs field is not bound to the type of attestation to facilitate reuse of attribute types across attestation statement types and to allow for parsing of an AttestationStatement with no knowledge of the details of a specific type.

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 RA/CA 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. Due to the nature of the PKIX ASN.1 classes , there are multiple ways to convey multiple attestation statements: by including multiple copies of attr-attestations or ext-attestations, multiple values within the attribute or extension, and finally, by including multiple AttestationStatement structures within an AttestationBundle. The latter is the preferred way to carry multiple Attestations statements. Implementations MUST NOT place multiple copies of attr-attestations into a PKCS#10 CSR due to the COUNTS MAX 1 declaration. In a CRMF CSR, implementers SHOULD NOT place multiple AttestationBundle instances in ext-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, allocate a value from "SMI Security for S/MIME Attributes" to identify an attribute defined within, and open a new registry.

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 - This was early-allocated as 59 so that we could generate the sample data.
• Description: id-aa-attestation
• References: This Document

Attestation OID Registry IANA is asked to create a registry that helps developers to find OID/Attestation mappings that may be encountered in the wild, as well as a link to their specification document and an indication as to whether the attestation is cryptographically bound to a public key. This registry should follow the rules for "Specification Required" as laid out in . Each row includes an OID and ASN.1 type that could appear in an AttestationStatement, and references to find the full specification. Registration requests should be formatted as per the registration template below, and receive a three-week review period on the spasm mailing list, with the advice of one or more Designated Experts . However, to allow for the allocation of values prior to publication, the Designated Experts may approve registration once they are satisfied that such a specification will be published. Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register attestation attestation: example"). IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

Registration Template The registry has the following columns:

• OID: The OID number, which has already been allocated. IANA does not allocate OID numbers for use with this registry.
• Type: The ASN.1 type corresponding to the given OID.
• Description: Brief description of the use of the Attestation and the registration of the OID.
• Reference(s): Reference to the document or documents that register the OID and define the ASN.1 type for use with a specific attestation technology, preferably including URIs that can be used to retrieve copies of the documents. An indication of the relevant sections may also be included but is not required.
• Change Controller: The entity that controls the listed data format. For data formats specified in Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. This does not necessarily have to be a standards body, for example in the case of proprietary data formats the Reference may be to a company or a publicly-available reference implementation. In most cases the third party requesting registration in this registry will also be the party that registered the OID. As the intention is for this registry to be a helpful reference, rather than a normative list, a fair amount of discretion is left to the Designated Expert.

Initial Registry Contents The initial registry contents is shown in the table below. It lists entries for several attestation encoding OIDs including an entry for the Conceptual Message Wrapper (CMW) .

• CMW
  • OID: 1 3 6 1 5 5 7 1 35
  • Type: CMW
  • Description: id-pe-cmw
  • Reference(s):
  • Change Controller: IETF

The current registry values can be retrieved from the IANA online website.

Security Considerations This document defines a structure to convey attestations as additional information in CSRs, as well as an extension to convey that structure in the Certification Request Message defined in {} and an attribute 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. 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 pertains 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. an Evidence that a key pair was generated in an HSM;
2. an Endorsement that states a particular platform is company-owned; and
3. an Attestation Result stating 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 in AttestationStatement 1 applies to the public key in the CSR;
2. the attestation of company ownership in AttestationStatement 2 applies to the platform that contains the HSM; and
3. the attestation that a platform was in a known good state in 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.

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 Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. 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. 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. 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. We would like to specifically thank Mike StJohns for his work on an initial version of this draft. 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.