| Internet-Draft | Remote Attestation with CSRs | January 2026 |
| Ounsworth, et al. | Expires 16 July 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://lamps-wg.github.io/csr-attestation/draft-ietf-lamps-csr-attestation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/.¶
Source for this draft and an issue tracker can be found at https://github.com/lamps-wg/csr-attestation.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 16 July 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [CSBR]. The [CSBR] 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 [RFC2986] or Certificate Request Message Format (CRMF) [RFC4211] 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.¶
As noted, attestation-related technologies have existed for many years, albeit with no standard format and no standard means of conveying attestation information 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 [RFC9334], 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 [RFC9334] 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.¶
The trust model defined in Section 7 of [RFC9334] identifies several roles that originate or forward attestations: the Attester; Endorser; and Verifier. Attestations, or Evidence per [RFC9334], may be directed to an entity fulfilling one of these roles, including to an RA/CA acting as a Verifier. An RA/CA may also forward attestations to a Verifier for evaluation. Each attestation may contain one or more claims, including claims that may be required by an RA or CA. Attestations transmitted by these parties are defined in Section 8 of [RFC9334] 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 attestations, and is equally applicable to these three conceptual messages.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document re-uses the terms defined in [RFC9334] related to remote attestation. Readers of this document are assumed to be familiar with the following terms defined in [RFC9334]: Evidence, Endorsement, Claim, Attestation Result (AR), Attester, Relying Party, and Verifier. Per [RFC9334], 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 [RFC9334] Relying Party, which may or may not include an integrated Verifier.¶
The term "Certification Request" message is defined in [RFC2986]. Specifications, such as [RFC7030], 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) [RFC4211] 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.¶
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 AttestationStatement structure (as shown in Figure 1) facilitates the representation of Evidence, Endorsements,
and Attestation Results generated by an Attester, Endorser, or Verifier for processing by a Verifer 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.¶
ATTESTATION-STATEMENT ::= TYPE-IDENTIFIER
AttestationStatement ::= SEQUENCE {
type ATTESTATION-STATEMENT.&id({AttestationStatementSet}),
bindsPublicKey BOOLEAN DEFAULT TRUE,
stmt ATTESTATION-STATEMENT.&Type({AttestationStatementSet}{@type}),
attrs Attributes OPTIONAL
}
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, Figure 2, 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.¶
AttestationBundle ::= SEQUENCE {
attestations SEQUENCE SIZE (1..MAX) OF AttestationStatement,
certs SEQUENCE SIZE (1..MAX) OF LimitedCertChoices OPTIONAL,
}
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 [RFC6268], and reproduced below along with OtherCertificateFormat, allows for carrying certificates in the default X.509 [RFC5280] 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.¶
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate,
-- Obsolete
...,
[[3: v1AttrCert [1] IMPLICIT AttributeCertificateV1]],
-- Obsolete
[[4: v2AttrCert [2] IMPLICIT AttributeCertificateV2]],
[[5: other [3] IMPLICIT OtherCertificateFormat]] }
OTHER-CERT-FMT ::= TYPE-IDENTIFIER
OtherCertificateFormat ::= SEQUENCE {
otherCertFormat OTHER-CERT-FMT.
&id({SupportedCertFormats}),
otherCert OTHER-CERT-FMT.
&Type({SupportedCertFormats}{@otherCertFormat})}
LimitedCertChoices ::= CertificateChoices (WITH COMPONENTS {\
certificate, 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 signer 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 ATTESTATION-STATEMENT ::= {
... -- None defined in this document --
}
The expression illustrated in Figure 3 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.¶
By definition, attributes within a PKCS#10 CSR are typed as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION.¶
id-aa-attestations OBJECT IDENTIFIER ::= { id-aa 59 }
-- For PKCS#10
attr-attestations ATTRIBUTE ::= {
TYPE AttestationBundle
COUNTS MAX 1
IDENTIFIED BY id-aa-attestation
}
-- For CRMF
ext-attestations EXTENSION ::= {
SYNTAX AttestationBundle
IDENTIFIED BY id-aa-attestation
}
The Extension variant illustrated in Figure 4 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 [RFC5912], 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 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 two attributes defined within, and open a new registry.¶
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).¶
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).¶
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 [RFC5226].¶
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 [RFC8126]. 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.¶
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.¶
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) [I-D.ietf-rats-msg-wrap].¶
CMW¶
The current registry values can be retrieved from the IANA online website.¶
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 {[RFC2986]} and an attribute to convey that structure in the Certificate Request Message Format defined in {[RFC4211]}. 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.¶
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 [RFC9334], 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:¶
an Evidence that a key pair was generated in an HSM;¶
an Endorsement that states a particular platform is company-owned; and¶
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:¶
the attestation of HSM generation in AttestationStatement 1 applies to the public key in the CSR;¶
the attestation of company ownership in AttestationStatement 2 applies to the platform that contains the HSM; and¶
the attestation that a platform was in a known good state in AttestationStatement 3 applies to the platform that contains the HSM.¶
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 [RFC9334]. Other mechanisms for determining freshness may be used as the CA/RA deems appropriate.¶
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.¶
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 [RFC2986], CRMF [RFC4211], as well as general security concepts relating to remote attestation; many of these concepts are discussed in Section 6 of [RFC9334], Section 7 of [RFC9334], Section 9 of [RFC9334], Section 11 of [RFC9334], and Section 12 of [RFC9334]. Implementers should also be aware of any security considerations relating to the specific attestation formats being carried within the CSR.¶
Examples and sample data will be collected in the "CSR Attestation Sample Data" GitHub repository [SampleData].¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
CSR-ATTESTATION-2025
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix-attest-01(TBDMOD) }
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
Certificate, id-pkix
FROM PKIX1Explicit-2009 -- from [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) }
CertificateChoices, Attributes
FROM CryptographicMessageSyntax-2010
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }
EXTENSION, ATTRIBUTE, AttributeSet{}, SingleAttribute{}
FROM PKIX-CommonTypes-2009 -- from [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkixCommon-02(57) }
id-aa
FROM SecureMimeMessageV3dot1-2009
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1-02(39) }
;
ATTESTATION-STATEMENT ::= TYPE-IDENTIFIER
AttestationStatementSet ATTESTATION-STATEMENT ::= {
... -- None defined in this document --
}
AttestationStatement ::= SEQUENCE {
type ATTESTATION-STATEMENT.&id({AttestationStatementSet}),
bindsPublicKey BOOLEAN DEFAULT TRUE,
stmt ATTESTATION-STATEMENT.&Type(
{AttestationStatementSet}{@type}),
attrs Attributes OPTIONAL
}
-- Arc for Attestation types
id-aa-attestation OBJECT IDENTIFIER ::= { id-aa 59 }
-- For PKCS#10 (Attestation)
attr-attestation ATTRIBUTE ::= {
TYPE AttestationBundle
COUNTS MAX 1
IDENTIFIED BY id-aa-attestation
}
-- For CRMF (Attestation)
ext-attestation EXTENSION ::= {
SYNTAX AttestationBundle
IDENTIFIED BY id-aa-attestation
}
LimitedCertChoices ::= CertificateChoices (WITH COMPONENTS {\
certificate, other})
AttestationBundle ::= SEQUENCE {
attestations SEQUENCE SIZE (1..MAX) OF AttestationStatement,
certs SEQUENCE SIZE (1..MAX) OF LimitedCertChoices OPTIONAL
}
END
¶
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, 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 earlier version of this draft.¶
We would also like to specifically thank Giri Mandyam for providing the appendix illustrating the confidential computing scenario, and to Corey Bonnell for helping with the hackathon scripts to bundle it into a CSR.¶
Finally, we would like to thank Andreas Kretschmer, Hendrik Brockhaus, David von Oheimb, and Thomas Fossati for their feedback based on implementation experience.¶