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

Independent

United States montywiseman32@gmail.com

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 that a certificate signing request (CSR) include verifiable attestations. These attestations can contain claims regarding the platform used by the end entity to generate the key pair for which a certificate is sought. These claims can also include 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). The requirements for carrying attestation formats not defined using ASN.1 are specified in .

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. The ASN.1 notation, information object classes, and constraint notation used in this section and in are specified in , , and , respectively. For additional background on information object classes and constraints used in ASN.1 modules, see Sections 2.1.3 and 2.2 of .

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

A CA/RA's issuance policy may place additional requirements on the contents of the attestations sequence, such as requiring claims that are bound to the CSR's public key in a cryptographically verifiable manner. Such a binding may identify the public key directly or through a cryptographically verifiable reference, as defined by the applicable attestation format. See for more discussion. The CertificateChoices structure defined in , and reproduced below along with OtherCertificateFormat, allows for carrying certificates in the default X.509 format or in other certificate formats. Within an AttestationBundle, a CertificateChoices value MUST use only the certificate or other alternative; the extendedCertificate, v1AttrCert, and v2AttrCert alternatives MUST NOT be used. marks extendedCertificate and v1AttrCert as obsolete. Although v2AttrCert is not obsolete, it is excluded here because an attribute certificate does not contain a subject public key that can be used to validate an AttestationStatement. OTHER-CERT-FMT is an ASN.1 information object class. The &id field identifies a certificate format by its OBJECT IDENTIFIER, and the corresponding &Type field specifies the ASN.1 type used to carry that format. For a non-ASN.1 certificate format, an OTHER-CERT-FMT information object MUST specify OCTET STRING as its &Type; otherCertFormat then carries the format's &id, and otherCert carries the encoded certificate in that OCTET STRING. LimitedCertChoices applies an ASN.1 constraint that limits the available alternatives to certificate and other. The certs field is OPTIONAL. When validation of an AttestationStatement requires a public key that cannot be obtained otherwise, certs SHOULD contain a certificate containing that public key. A certificate is not needed when the corresponding public key is already 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. This document does not define, allocate, or register an OID for any attestation-statement format, nor does it establish an IANA registry for such formats. Specification authors who define an attestation-statement format are responsible for assigning its OID from an arc under their control.

CSR Attribute and Extension The ASN.1 ATTRIBUTE and EXTENSION information object classes are defined in . Attributes within a PKCS#10 CSR use ATTRIBUTE, and extensions within a CRMF CSR use EXTENSION. The id-aa object identifier is defined in the SecureMimeMessageV3dot1-2009 module in .

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. The attestation-format specification is responsible for defining how this ambiguity is resolved, particularly for opaque (wrapper) formats. Possible approaches include defining separate OIDs for different Verifier or verification types, even when they share a format structure, or defining a wrapper with a hint that assists Verifier selection. This document does not specify a Verifier selection mechanism.

IANA Considerations IANA is requested to allocate an identifier for the ASN.1 module in the "SMI Security for PKIX Module Identifier" registry and to update the existing early allocation with decimal value 59 in the "SMI Security for S/MIME Attributes" 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: id-mod-pkix-attest-2025
• References: This Document

Object Identifier Update - SMI Security for S/MIME Attributes IANA is requested to update entry 59, early-allocated as "id-aa-evidence", in the id-aa SMI Security for S/MIME Attributes registry (1.2.840.113549.1.9.16.2). The numeric value is unchanged. The updated entry is:

• Decimal: 59
• 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 Key attestation is one use case for the structures defined in this document. It enables a CA/RA to obtain assurance about the key pair for which a certificate is requested, including the generation, protection, permitted use, or extractability of its private key. Platform attestation may provide additional claims about the environment in which the key pair is generated, stored, or used. To provide assurance about the requested key pair, the relevant claims must be bound to the CSR's public key in a cryptographically verifiable manner, and appraisal must establish that they support the claimed properties of that key pair. Including a requester-supplied public key or its hash in a signed platform attestation does not, by itself, demonstrate that the corresponding private key was generated or is protected in the attested environment. Regardless of the topological model, when a CA/RA relies on attestation statements to establish a property of the CSR's public key or the corresponding private key, it MUST ensure that this binding has been validated. The CA/RA may rely on a trusted Verifier to perform this validation but remains responsible for ensuring that it has been performed. The binding may identify the public key directly or through a cryptographically verifiable reference, as defined by the applicable attestation format. When Evidence is used to establish such a key property, validation includes establishing that the claims refer to the requested key pair and support the properties on which the CA/RA relies. This appraisal may be performed by a CA/RA acting as a Verifier or by an external trusted Verifier. When Attestation Results are used for this purpose, the CA/RA MUST authenticate the results and establish that they apply to the CSR's public key and confirm the required properties based on a binding validated by the trusted Verifier. These requirements apply whether Evidence or Attestation Results are carried in the CSR or obtained during its processing. For the code-signing use case described in , the CA/RA therefore needs assurance that the claims of HSM generation and protection apply to the key pair for which the certificate is requested. If no validated binding is available, the CA/RA MUST NOT treat attestation statements as establishing properties of the CSR's public key or the corresponding private key. The CA/RA's issuance policy determines whether to reject the CSR, obtain additional evidence, or issue a certificate based on other acceptable information. The absence of a validated binding does not, by itself, require rejection under this specification. However, an issuance policy that requires attested properties of the requested key cannot be satisfied by attestation statements that lack such validated binding. Multiple attestation statements 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 attestation statements 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 Certificate Management Protocol (CMP) , Enrollment over Secure Transport (EST) , and Certificate Management over CMS (CMC) , these protocols can supply an Attester with a nonce, for example. Further details are specified in .

Resource Exhaustion CSRs are untrusted input to a CA/RA, and processing attestation bundles may consume substantial resources through parsing, cryptographic verification, certification path building and validation, and requests to external Verifiers or other services. An attacker can exploit these costs to cause resource exhaustion, even with a syntactically valid bundle. Implementations SHOULD impose limits appropriate to their deployment on the total bundle size, the number, type and size of attestation statements and certificates, parsing depth, and the computational effort spent processing a request. These limits SHOULD also bound certification path building, as well as the number, duration, and concurrency of external requests. Implementations SHOULD enforce limits as early as practicable. When a limit is exceeded, implementations SHOULD stop the affected processing and release resources allocated to it. An attestation statement whose verification has not completed successfully MUST NOT be treated as successfully verified.

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.

Privacy Considerations Attestation statements and accompanying certificates can disclose information about a device, its software and hardware environment, and its owner or users. These statements may contain Evidence, Endorsements, or Attestation Results. Attesters SHOULD consider how much information is appropriate to disclose to a given CA. Examples include hardware identifiers, software versions, patch levels, and device ownership. These disclosures occur during enrollment, even if no attestation data is copied into the issued certificate. Attestation formats may use stable device-identifying public keys, certificates, device IDs, or other identifiers. These values can enable a CA/RA or Verifier to link multiple CSRs to the same device even when the CSR public key, subject name, or enrollment account changes. Such linkability can affect privacy even when the individual attested claims are not otherwise sensitive. A CA/RA that forwards attestation statements or accompanying certificates to an external Verifier discloses this information to another party. That party may also be able to correlate requests across enrollments or across CAs. The privacy assessment of a deployment therefore needs to cover the entire enrollment and attestation verification path, including third-party processing, retention, and logging. Certificate requesters, CAs/RAs, and Verifiers SHOULD minimize the claims contained in attestation statements and the accompanying certificates they disclose, process, and retain to those needed for the applicable issuance policy. Where supported by the attestation technology and compatible with that policy, deployments SHOULD use mechanisms that reduce device linkability, such as privacy-preserving attestation procedures. Such mechanisms do not eliminate correlation through other disclosed information. Enrollment protocols and communication with external Verifiers SHOULD provide confidentiality protection and authenticate recipients. Transport confidentiality protects against observers but does not prevent correlation by the recipients themselves. Access to stored attestation statements and accompanying certificates, including copies in logs, SHOULD be restricted, and retention SHOULD be limited to the period needed for issuance and applicable audit requirements. Attestation statements are intended as additional information in the issuance process. It is NOT RECOMMENDED for a CA to copy attestation statements into the published certificate. CAs that choose to republish attestation statements or claims contained in them in certificates SHOULD review the contents and omit sensitive or identifying information. Further discussion of remote attestation privacy risks and mitigations is provided in . Deployments should also consider the privacy considerations of the specific attestation formats they use.

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 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 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. 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] ITU-T ITU-T ITU-T 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 Siemens Siemens AKAYLA, Inc. sn3rd When an end entity includes attestation statements in a Certificate Signing Request (CSR), the freshness of the conveyed Evidence often needs to be established. A common mechanism is a nonce that is obtained from a Relying Party or Verifier and included by the Attester in the Evidence. This document specifies how an end entity requests such an attestation freshness nonce from an RA/CA when using certificate lifecycle management protocols. It defines message formats and protocol bindings for the conveyance of nonce request and response messages in the Certificate Management Protocol (CMP), Enrollment over Secure Transport (EST), and Certificate Management over CMS (CMC), including optional type-specific information needed to produce fresh Evidence for inclusion in a CSR. Abstract Syntax Notation One (ASN.1) is widely used throughout the IETF Security Area and has been for many years. Some specifications were written using a now deprecated version of ASN.1 and some were written using the current version of ASN.1. Not all ASN.1 compilers support both older and current syntax. This document is intended to provide guidance to specification authors and to implementers converting ASN.1 modules from one version of ASN.1 to another version without causing changes to the "bits on the wire". This document does not provide a comprehensive tutorial of any version of ASN.1. Instead, it addresses ASN.1 features that are used in IETF Security Area specifications with a focus on items that vary with the ASN.1 version. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides interactions between client systems and PKI components such as a Registration Authority (RA) and a Certification Authority (CA). This document adds support for management of certificates containing a Key Encapsulation Mechanism (KEM) public key and uses EnvelopedData instead of EncryptedValue. This document also includes the updates specified in Section 2 and Appendix A.2 of RFC 9480. This document obsoletes RFC 4210, and together with RFC 9811, it also obsoletes RFC 9480. Appendix F of this document updates Section 9 of RFC 5912. This document presents a framework to assist the writers of certificate policies or certification practice statements for participants within public key infrastructures, such as certification authorities, policy authorities, and communities of interest that wish to rely on certificates. In particular, the framework provides a comprehensive list of topics that potentially (at the writer's discretion) need to be covered in a certificate policy or a certification practice statement. This document supersedes RFC 2527. This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: CMC also requires the use of the transport document (RFC 10003) and the requirements usage document (RFC 10004) along with this document for a full definition. This document obsoletes RFCs 5272 and 6402. The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. 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 Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as 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, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. 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. We thank Ketan Talaulikar for his detailed review during IESG evaluation, and Meral Shirazipour, Shivan Kaul Sahib, and Sean Turner for their Last Call reviews on behalf of Gen-ART, SECDIR, and ARTART, respectively. Finally, we would like to thank Deb Cooley for her review of the document as part of the IESG evaluation process.