]> Entrust Limited

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

Siemens

Germany Hannes.Tschofenig@gmx.net

Fraunhofer SIT

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

USA mwiseman32@acm.org

Intel Corporation

United States ned.smith@intel.com

PKI PKCS#10 CRMF Attestation Evidence Certificate Signing Requests A PKI end entity requesting a certificate from a Certification Authority (CA) may wish to offer trustworthy claims about the platform generating the certification request and the environment associated with the corresponding private key, such as whether the private key resides on a hardware security module. This specification defines an attribute and an extension that allow for conveyance of RATS conceptual messages (see , such as Evidence, Endorsements and Attestation Results, in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This provides an elegant and automatable mechanism for transporting attestation data to a Certification Authority. Including Evidence, Endorsements and Attestation Results along with a CSR can help to improve the assessment of the security posture for the private key, and can help the Certification Authority to assess whether it satisfies the requested certificate profile. 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 When requesting a certificate from a Certification Authority (CA), a PKI end entity may wish to include RATS conceptual messages (see , such as Evidence, Endorsements and Attestation Results , of the security properties of its environments in which the private keys are stored in that request. Evidence and Endorsements are appraised by Verifiers, which typically produces Attestation Results that serve as input for validating incoming certificate requests against specified certificate policies. Verifiers are associated with Registration Authorities (RAs) or CAs and function as logical entities responsible for processing Evidence and Endorsements in order to produce Attestation Results. As remote attestation technology matures, it is natural for a Certification Authority to rely on remote attestation data for proof that the requesting entity is in a state that matches the certificate profile. This is referred to as the RATS Background Check Model, and is illustrated in . Alternatively, the Attester might have a direct connection to a Verifier to which it presents its Evidence and Endorsements, and receives back an Attestation Result signed by the Verifier which it can include directly in the CSR and save the RA / CA from needing a local Verifier. This is referred to as the RATS Passport Model, and is illustrated in . 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 , which 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", which is a natural fit to enforce via remote attestation. This specification defines an attribute and an extension that allow for conveyance of Evidence, Endorsements, and Attestation Results in Certificate Signing Requests (CSRs), such as PKCS#10 or Certificate Request Message Format (CRMF) payloads. This CSR extension satisfies CA/B Forum's CSBR requirements for key protection assurance, provided that the CSR carries attestation data that the RA / CA can parse to obtain the assurance that it needs to satisfy its certificate issuance policies. As outlined in the IETF RATS architecture , an Attester (typically a device) produces a signed collection of Claims that constitute Evidence about its running environment(s). The terms "attestation" or "remote attestation" are not explicitly defined in RFC 9334 but the activity of "attestation" is clarified in . It refers to the process of generating and evaluating remote attestation Evidence and Endorsements. This document relies on as the foundation for how the various roles within the RATS architecture correspond to a certificate requester and a CA/RA. Several standard and proprietary remote attestation technologies are in use at the time of writing. This specification thereby is intended to be as technology-agnostic as is feasible with respect to implemented remote attestation technologies. Hence, this specification focuses on (1) the conveyance of Evidence, Endorsements, and Attestation Results via CSRs while making minimal assumptions about content or format of the transported payload and (2) the conveyance of sets of certificates used for validation of Evidence, Endorsements, and Attestation Results. The certs field of the EvidenceBundle typically contain one or more certification paths rooted in a device manufacturer trust anchor and the end entity certificate being on the device in question. The end entity certificate is associated with key material that takes on the role of an Attestation Key and is used to sign Evidence originating from the Attester. In some interpretations of the RATS Architecture , the Attestation Key Certificate and its corresponding certificate chain are considered to be Endorsements of the Attestation Key. The certs field of the AttestationResultsBundle behaves similarly but the end entity certificate will correspond to a Verifier. For the purposes of this specification, a certificate chain provided for the purposes of validating another signed object is not considered to be an Endorsement in and of itself. Here, the term "Endorsement" means a signed object containing data about the target environment which may or may not be accompanied by a certificate chain.

• Evidence and Endorsements are placed into an EvidenceStatement along with an OID to identify its type and optionally a hint to the Relying Party about which Verifier (software package, a microservice or some other service) will be capable of parsing it. A set of EvidenceStatement structures may be grouped together along with the set of CertificateChoice structures needed to validate them to form a EvidenceBundle. See .
• Attestation Results are carried in the AttestationResult along with an OID to identify its type. A set of AttestationResult structures may be grouped together to form an AttestationResultBundle. See .

A CSR may contain one or more Evidence payloads. For example Evidence asserting the storage properties of a private key, Evidence asserting firmware version and other general properties of the device, Evidence signed using different cryptographic algorithms, or Endorsements provided by the device manufacturer. Like-wise, a CSR may also contain one or more Attestation Result payloads. With these attributes, additional information is available to an RA or CA, which may be used to decide whether to issue a certificate and what certificate profile to apply. The scope of this document is, however, limited to the conveyance of Evidence, Endorsements, and Attestation Results within CSRs. The exact format of the Evidence, Endorsements, and Attestation Results being conveyed is out of scope of this document as they are defined in various standard and proprietary specifications.

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: Evidence, Endorsement, Claim, Attestation Result (AR), Attester, Verifier, Target Environment, Attesting Environment, Composite Device, Lead Attester, Attestation Key, and Relying Party (RP). 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 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 "EvidenceStatement", which denote ASN.1 types.

Architecture shows the high-level communication pattern of the RATS background check model where the Attester transmits the Evidence in the CSR to the registration authority (RA) and the certification authority (CA), which is subsequently forwarded to the Verifier. The Verifier appraises the received Evidence and computes an Attestation Result, which is then processed by the RA/CA prior to the certificate issuance. The RA and CA are depicted as separate entities with the RA consuming the Attestation Results and deciding whether or not to forward the certificate request to the CA. In some deployments they are co-located roles. In other deployments, the RA uses a proprietary interface into the CA. In either case, communication between RA and CA is out-of-scope, they can be conceptualized as a single Relying Party entity for the purposes of this specification. This diagram overlays PKI entities with RATS roles in parentheses.

Example data flow demonstrating the architecture with Background Check Model. |----' |------>| | | end | Evidence / | registration | | CA | | entity | Endorsements | authority (RA) | | | | | in CSR | | | | | (Attester) | | (Relying Party) | | | '------------' '-----------------' '-----' ]]>

In addition to the background-check model, the RATS architecture also defines the passport model, as described in . In the passport model, the Attester transmits Evidence directly to the Verifier to obtain an Attestation Result, which is subsequently forwarded to the Relying Party.

Example data flow demonstrating the architecture with Passport Model. | | Compare Evidence / | | (Verifier) | Endorsements | +----------------| | against Appraisal | | '-----------------' Policy | | Attestation | | Result | v .--------|---. .-----------------. .------. | +-->+------------>| Registration |------------->| | | End | Attestation | Authority RA | | CA | | Entity | Result in | | | | | (Attester) | CSR | (Relying Party) | | | '------------' '-----------------' '------' ]]>

The choice of model depends on various factors. For instance, the background-check model is preferred when direct real-time interaction between the Attester and the Verifier is not feasible. The interface by which the Relying Party passes Evidence and Endorsements to the Verifier and receives back Attestation Results may be proprietary or standardized, but in any case is out-of-scope for this document. Like-wise, the interface between the Attester and the Verifier used in the passport model is also out-of-scope for this document. RFC 9334 discusses different security and privacy aspects that need to be considered when developing and deploying a remote attestation solution. For example, Evidence may need to be protected against replay and lists approach for offering freshness. There are also concerns about the exposure of persistent identifiers by utilizing attestation technology, which are discussed in . Finally, the keying material used by the Attester needs to be protected against unauthorized access, and against signing arbitrary content that originated from outside the device. This aspect is described in . Most of these aspects are, however, outside the scope of this specification but relevant for use with a given attestation technology. The focus of this specification is on the transport of Evidence, Endorsements, and Attesation Results from the Attester to the Relying Party via existing CSR messages.

Information Model

Model for Evidence and Endorsements in CSR To support a number of different use cases for the transmission of Evidence, Endorsements and certificate chains needed to validate them in a CSR the structure shown in is used. On a high-level, the structure is composed as follows: A PKCS#10 attribute or a CRMF extension contains one EvidenceBundle structure. The EvidenceBundle contains one or more EvidenceStatement structures as well as one or more CertificateChoices which enable to carry various format of certificates. For the purpose of conveyance within these structures, Evidence and Endorsements are considered interchangeable since they are both signed data objects with a certificate chain that needs to be validated by a Verifier, so for the remainder of this document, the term "Evidence" will be used to refer to both types of RATS conceptual messages. Note: Since an extension must only be included once in a certificate see , this PKCS#10 attribute or the CRMF extension MUST only be included once in a CSR.

Information Model for CSR Evidence Conveyance. | CertificateChoices | | | +-------------------------+ | | | Certificate OR | | | | OtherCertificateFormat | 1 | | +-------------------------+ v 1 v +--------------------+ 1 1..n +-------------------+ | EvidenceBundle |<--------------->| EvidenceStatement | +--------------------+ +-------------------+ | Type | | Statement | | Hint | +-------------------+ ]]>

A conformant implementation of an entity processing the CSR structures MUST be prepared to use certificates found in the EvidenceBundle structure to build a certification path to validate any EvidenceStatement. The following use cases are supported, as described in the sub-sections below.

Case 1 - Evidence Bundle without Certificate Chain A single Attester, which only distributes Evidence without an attached certificate chain. In the use case, the Verifier is assumed to be in possession of the certificate chain already or the Verifier directly trusts the Attestation Key and therefore no certificate chain needs to be conveyed in the CSR. As a result, one EvidenceBundle is included in a CSR that contains a single EvidenceStatement without the CertificateChoices structure. shows this use case.

Case 1: Evidence Bundle without Certificate Chain.

Case 2 - Evidence Bundle with Certificate Chain A single Attester, which shares Evidence together with a certificate chain, is shown in . The CSR conveys an EvidenceBundle with a single EvidenceStatement and a CertificateChoices structure.

Case 2: Single Evidence Bundle with Certificate Chain.

Case 3 - Evidence Bundles with Multiple Evidence Statements and Complete Certificate Chains In a Composite Device, which contains multiple Attesters, a collection of Evidence statements is obtained. In this use case, each Attester returns its Evidence together with a certificate chain. As a result, multiple EvidenceStatement structures and the corresponding CertificateChoices structure with the certification chains as provided by the Attester, are included in the CSR. This approach does not require any processing capabilities by a Lead Attester since the information is merely forwarded. shows this use case.

Case 3: Multiple Evidence Structures each with Complete Certificate Chains.

Model for Attestation Result in CSR illustrates the information model for transmitting Attestation Results as a PKCS#10 attribute or a CRMF extension. This structure includes a single AttestationResultBundle, which in turn comprises one or more AttestationResult structures.

Information Model for CSR Attestation Result Conveyance. +-------------------+ | | | Type | | | | Result | | | | | 1 | | +-------------------+ v 1 v +-------------------------+ | AttestationResultBundle | +-------------------------+ ]]>

A Relying Party receiving a CSR containing an Attestation Result MUST use the Type information to parse the content. The Attestation Result encoding MUST provide information for the Relying Party to determine the Verifier, who created and protected the Attestation Result against modifications.

ASN.1 Elements for Evidence in CSR

Object Identifiers This document references id-pkix and id-aa, both defined in and .

Evidence Attribute and Extension By definition, attributes within a PKCS#10 CSR are typed as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION. This attribute definition contains one Evidence bundle of type EvidenceBundle containing one or more Evidence statements of a type EvidenceStatement along with optional certificates for certification path building. This structure enables different Evidence statements to share a certification path without duplicating it in the attribute.

Definition of EvidenceStatementSet

The expression illustrated in maps ASN.1 Types for Evidence Statements to the OIDs that identify them. These mappings are used to construct or parse EvidenceStatements. Evidence Statements are typically defined in other IETF standards, other standards bodies, or vendor proprietary formats along with corresponding OIDs that identify them. This list is left unconstrained in this document. However, implementers can populate it with the formats that they wish to support.

Definition of EvidenceStatement

In , type is an OID that indicates the format of the value of stmt. Based on the responsibilities of the different roles in the RATS architecture, Relying Parties need to relay Evidence to Verifiers for evaluation and obtain an Attestation Result in return. Ideally, the Relying Party should select a Verifier based on the received Evidence without requiring the Relying Party to inspect the Evidence itself. This "routing" decision is simple when there is only a single Verifier configured for use by a Relying Party but gets more complex when there are different Verifiers available and each of them capable of parsing only certain Evidence formats. In some cases, the EvidenceStatement.type OID will be sufficient information for the Relying Party to correctly route it to an appropriate Verifier, however since the type OID only identifies the general data format, it is possible that multiple Verifiers are registered against the same type OID in which case the Relying Party will either require additional parsing of the evidence statement, or the Attester will be required to provide additional information. To simplify the task for the Relying Party to select an appropriate Verifier an optional field, the hint, is available in the EvidenceStatement structure, as shown in . An Attester MAY include the hint to the EvidenceStatement and it MAY be processed by the Relying Party. The Relying Party MAY decide not to trust the information embedded in the hint or policy MAY override any information provided by the Attester via this hint. When the Attester populates the hint, it MUST contain a server name which uniquely identifies a Verifier. Server names are ASCII strings that contain a hostname and optional port, where the port is implied to be "443" if missing. The names use the format of the authority portion of a URI as defined in Section 3.2 of . The names MUST NOT include a "userinfo" portion of an authority. For example, a valid server name might be "verifier.example.com" or "verifier.example.com:8443", but not "verifier@example.com". Relying Parties SHOULD NOT connect to a host name provided in the hint, especially if the verifier has no previous trust relationship with that host name, instead this SHOULD be used only as a lookup string for determining between a list of Verifiers that the Relying Party is pre-configured to use. In a typical usage scenario, the Relying Party is pre-configured with a list of trusted Verifiers and the corresponding hint values can be used to look up appropriate Verifier. The Relying Party is also configured with a trust anchor for each Verifier, which allows the Verifier to validate the signature protecting the Attestation Result. Tricking a Relying Party into interacting with an unknown and untrusted Verifier must be avoided. The CertificateChoices structure defined in 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. CertificateChoices MUST NOT contain extendedCertificate, v1AttrCert, or v2AttrCert. Note that for non-ASN.1 certificate formats, the CertificateChoices MUST use other [3] with an OtherCertificateFormat.Type of OCTET STRING, and then can carry any binary data. The certs field contains a set of certificates that is intended to validate the contents of an Evidence statement contained in evidences, if required. For each Evidence statement, the set of certificates SHOULD contain the certificate that contains the public key needed to directly validate the Evidence statement, unless the signing key is expected to be known to the Verifier or is embedded within the statement. Additional certificates MAY be provided, for example, to chain the Evidence signer key back to an agreed upon trust anchor. No specific order of the certificates in certs SHOULD be expected because certificates contained in certs may be needed to validate different Evidence statements. This specification places no restriction on mixing certificate types within the certs field. For example a non-X.509 Evidence 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.

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 Evidence about the end entity's hardware environment. See for more discussion. By the nature of the PKIX ASN.1 classes , there are multiple ways to convey multiple Evidence statements: by including multiple copies of attr-evidence or ext-evidence, multiple values within the attribute or extension, and finally, by including multiple EvidenceStatement structures within an EvidenceBundle. The latter is the preferred way to carry multiple Evidence statements. Implementations MUST NOT place multiple copies of attr-evidence into a PKCS#10 CSR due to the COUNTS MAX 1 declaration. In a CRMF CSR, implementers SHOULD NOT place multiple copies of ext-evidence.

ASN.1 Elements for Attestation Result in CSR When operating according to the RATS Passport Model, as depicted in , the CSR sent to the CA / RA will contain Attestation Results in place of Evidence or Endorsements. In order to clearly differentiate Background Check and Passport Model use cases, this section registers a different top-level CSR Attribute (PKCS#10) and Extension (CRMF) for carrying Attestation Results, which are syntactically identical to those for carrying Evidence and Endorsements.

Object Identifiers This document defines the OID depicted in as an additional CSR Attribute (PKCS#10) or Extension (CRMF) to carry Attestation Results in a CSR.

New OID for PKIX Attestation Result Formats

Attestation Result Attribute and Extension By definition, attributes within a PKCS#10 CSR are typed as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION. This attribute definition contains one AttestationResultBundle structure.

Definition of AttestationResultSet

The expression illustrated in maps ASN.1 Types for Attestation Result to the OIDs that identify them. These mappings are used to construct or parse AttestationResults. Attestation Results are defined in other IETF standards (see ), other standards bodies, or vendor proprietary formats along with corresponding OIDs that identify them. This list is left unconstrained in this document. However, implementers can populate it with the formats that they wish to support.

Definition of AttestationResult

In , type is an OID that indicates the format of the value of stmt.

Definitions of CSR attribute and extension

Implementation Considerations

Is the CSR constructed inside or outside the Attester? This specification is applicable both in cases where a CSR is constructed internally or externally to the Attesting Environment, from the point of view of the calling application. This section is particularly applicable to the background check model. Cases where the CSR is generated internally to the Attesting Environment are straightforward: the hardware security module (HSM) generates and embeds the Evidence and the corresponding certification paths when constructing the CSR. Cases where the CSR is generated externally might require extra communication between the CSR generator and the Attesting Environment, first to obtain the necessary Evidence about the subject key, and then to use the subject key to sign the CSR; for example, a CSR generated by a popular crypto library about a subject key stored on a PKCS#11 device. As an example, assuming that the HSM is, or contains, the Attesting Environment and some cryptographic library is assembling a CSR by interacting with the HSM over some network protocol, then the interaction would conceptually be:

Example interaction between CSR generator and HSM. | | | |<-----------------| +---------------------+ | | | CSR = assembleCSR() |-| | +---------------------+ | | | | | sign(CSR) | |----------------->| | | |<-----------------| | | ]]>

Separation of RA and CA roles with respect to Attestation Results As described in , CSRs MAY contain either Evidence or Attestation Results (AR), and also the registration authority (RA) and certification authority (CA) MAY be conceptualized as a single Relying Party entity, or as separate entities. There are some implications here worth discussion. In many cases, the Evidence contained within a CSR is intended to be consumed by the RA and not to be placed into the issued certificate. In some RA / CA architectures, it MAY be appropriate for the RA to "consume" the Evidence and remove it from the CSR, re-signing the CSR with an RA signing key. A CRMF CSR also allows the RA to indicate that it verified the CSR without the need to re-signing the CSR. In any case where the RA and CA roles are separated, and Evidence is evaluated and consumed by the RA, the RA does at least implicitly produce Attestation Results as defined in the RATS Architecture . For example, the decision to reject the Evidence and fail back to the client, or to accept the Evidence and forward a request to the CA could be viewed as a boolean Attestation Result. Similarly, if acceptance or rejection of the Evidence controls the presence or absence of a certain policy OID or other extension in the issued certificate, this could also be viewed as an Attestation Result. Alternatively, the RA MAY place explicit Attestation Results into its request to the CA; either for consumption by the CA or for inclusion in the issued certificate. The exact mechanisms for doing this are out-of-scope for this document, but are areas for implementation consideration and potential future standardization work.

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

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

• Decimal: IANA Assigned - Replace TBDMOD
• Description: CSR-ATTESTATION-2023 - 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).

• Evidence Statement
• Decimal: IANA Assigned - This was early-allocated as 59 so that we could generate the sample data.
• Description: id-aa-evidence
• References: This Document
• Attestation Result
• Decimal: IANA Assigned - - Replace TBD2
• Description: id-aa-ar
• References: This Document

Attestation Evidence OID Registry IANA is asked to create a registry that helps developers to find OID/Evidence mappings that may be encountered in the wild, as well as a link to their specification document. This registry should follow the rules for "Specification Required" as laid out in . Each row corresponds to an OID and ASN.1 type that could appear in a EvidenceStatement or AttestationResult, with references for where 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 evidence: 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 Evidence 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 evidence 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 In the RATS architecture, when Evidence or an Attestation Result is presented to a Relying Party (RP), the RP may learn detailed information about the Attester unless that information has been redacted or encrypted. Consequently, a certain amount of trust must be placed in the RP, which raises potential privacy concerns because an RP could be used to track devices. This observation is noted in Section 11 of . In the RATS architecture, RPs are typically application services that consume remote attestation, rather than PKI-style RAs or CAs. Devices already place substantial trust in RA/CA infrastructure, so additional information disclosed through remote attestation to these entities is generally less sensitive than disclosure to application services. The issue of CAs embedding Evidence into X.509 certificates is discussed in . These privacy risks can be mitigated using several approaches, including:

• Shared Attestation Keys: A manufacturer may provision all devices in a product family with the same attestation key. This enables anonymity by making devices indistinguishable from one another, but it also prevents revocation of a single device's key if compromised. To preserve privacy in such cases, Evidence must avoid embedding uniquely identifying information, as this would negate the benefits of shared keys.
• Per-Use Attestation Keys: Devices may be designed to dynamically generate distinct attestation keys (and request the corresponding certificates) for each use case, device, or session. This is analogous to the Privacy CA model, in which a device is initially provisioned with an attestation key and certificate; then, in conjunction with a privacy-preserving CA, it can obtain unique keys and certificates as needed. This strategy reduces the potential for tracking while maintaining strong security assurances. This is the model described in this document.
• Anonymous Attestation Mechanisms: Direct Anonymous Attestation (DAA) and related cryptographic schemes enable devices to produce attestation signatures that are verifiable against a root key, but unlinkable across different uses. This prevents a verifier from using repeated attestations with the same key as a global correlation handle to track devices. extends the RATS architecture with such a DAA scheme, thereby enhancing privacy.

Background Check Model Security Considerations A PKCS#10 or CRMF certification request typically consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. In general, because an Attestation Key is intended solely for signing Evidence, the private key used to sign a CSR SHOULD be distinct from the Attestation Key used to sign Evidence about the Target Environment. Exceptions MAY be allowed when CSRs and Evidence are both part of the process of bootstrapping the Attestation Key. To demonstrate that the private key applied to sign the CSR is generated, and stored in a secure environment that has controls to prevent theft or misuse (including being non-exportable / non-recoverable), the Attesting Environment has to collect claims about this secure environment (or Target Environment, as shown in ). shows the interaction inside an Attester. The Attesting Environment, which is provisioned with an Attestation Key, retrieves claims about the Target Environment. The Target Environment offers key generation, storage and usage, which it makes available to services. The Attesting Environment collects these claims about the Target Environment and signs them and exports Evidence for use in remote attestation via a CSR.

Interaction between Attesting and Target Environment | Environment +----------+ | | (Firmware) |Evidence| | '-------------' | | | '------------------------------------' ]]>

places the CSR library outside the Attester, which is a valid architecture for certificate enrollment. The CSR library may also be located inside the trusted computing base. Regardless of the placement of the CSR library, an Attesting Environment MUST be able to collect claims about the Target Environment such that statements about the storage of the keying material can be made. For the Verifier, the provided Evidence must allow an assessment to be made whether the key used to sign the CSR is stored in a secure location and cannot be exported. Evidence communicated in the attributes and structures defined in this document are meant to be used in a CSR. It is up to the Verifier and to the Relying Party (PKI RA/CA) to place as much or as little trust in this information as dictated by policies. This document defines the transport of Evidence of different formats in a CSR. Some of these encoding formats are based on standards while others are proprietary formats. A Verifier will need to understand these formats for matching the received claim values against policies. Policies drive the processing of Evidence at the Verifier: the Verifier's Appraisal Policy for Evidence will often be based on specifications by the manufacturer of a hardware security module, a regulatory agency, or specified by an oversight body, such as the CA Browser Forum. The Code-Signing Baseline Requirements document is an example of such a policy that has been published by the CA Browser Forum and specifies certain properties, such as non-exportability, which must be enabled for storing publicly-trusted code-signing keys. Other policies influence the decision making at the Relying Party when evaluating the Attestation Result. The Relying Party is ultimately responsible for making a decision of what information in the Attestation Result it will accept. The presence of the attributes defined in this specification provide the Relying Party with additional assurance about an Attester. Policies used at the Verifier and the Relying Party are implementation dependent and out of scope for this document. Whether to require the use of Evidence in a CSR is out-of-scope for this document.

Freshness for the Background Check Model Evidence generated by an Attester generally needs to be fresh in order to provide value to the Verifier since the configuration on the device may change over time. discusses different approaches for providing freshness, including a nonce-based approach, the use of timestamps and an epoch-based technique. The use of nonces requires that nonce to be provided by the Relying Party in some protocol step prior to Evidence and CSR generation, and the use of timestamps requires synchronized clocks which cannot be guaranteed in all operating environments. Epochs also require an out-of-band communication channel. This document leaves the exchange of nonces and other freshness data to certificate management protocols, see . Developers, operators, and designers of protocols, which embed Evidence-carrying-CSRs, MUST consider what notion of freshness is appropriate and available in-context; thus the issue of freshness is left up to the discretion of protocol designers and implementers. In the case of hardware security modules (HSM), the semantics of "freshness" are somewhat ambiguous in the context of CSRs, especially considering that non-automated certificate enrollments are often asynchronous, and considering the common practice of re-using the same CSR for multiple certificate renewals across the lifetime of a key. "Freshness" typically implies both asserting that the data was generated at a certain point-in-time, as well as providing non-replayability. Certain use cases may have special properties impacting the freshness requirements. For example, HSMs are typically designed to not allow downgrade of private key storage properties; for example if a given key was asserted at time T to have been generated inside the hardware boundary and to be non-exportable, then it can be assumed that those properties of that key will continue to hold into the future. Note: Freshness is also a concern for remote attestation in the passport model; however, the protocol between the Attester and the Verifier lies outside the scope of this specification.

Publishing Evidence in an X.509 Extension This document specifies an Extension for carrying Evidence in a PKCS#10 or CRMF certificate signing request (CSR), but it is intentionally NOT RECOMMENDED for a CA to copy the attr-evidence for PKCS#10 or ext-evidence extension for CRMF into the published certificate. The reason for this is that certificates are considered public information and the Evidence might contain detailed information about hardware and patch levels of the device on which the private key resides. The certificate requester has consented to sharing this detailed device information with the CA but might not consent to having these details published. These privacy considerations are beyond the scope of this document and may require additional signaling mechanisms in the CSR to prevent unintended publication of sensitive information, so we leave it as "NOT RECOMMENDED". Often, the correct layer at which to address this is either in certificate profiles, a Certificate Practice Statement (CPS), or in the protocol or application that carries the CSR to the RA/CA where a flag can be added indicating whether the RA/CA should consider the evidence to be public or private.

Type OID and Verifier Hint The EvidenceStatement includes both a type OID and a hint field with which the Attester can provide information to the Relying Party about which Verifier to invoke to parse a given piece of Evidence. Care should be taken when processing these data since at the time they are used, they are not yet verified. In fact, they are protected by the CSR signature but not by the signature from the Attester and so could be maliciously replaced in some cases. The authors' intent is that the type OID and hint will allow an RP to select between Verifier with which it has pre-established trust relationships. The RP MUST NOT blindly make network calls to unknown domain names and trust the results. Implementers should also be cautious around type OID or hint values that cause a short-circuit in the verification logic, such as None, Null, or similar values that could cause the Evidence to appear to be valid when in fact it was not properly checked.

Additional Security Considerations In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on this this 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 Evidence and Attestation Result 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] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [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. 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. 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. Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA. This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Fraunhofer SIT Independent Linaro University of Applied Sciences Bonn-Rhein-Sieg Google LLC The Conceptual Messages introduced by the RATS Architecture (RFC9334) 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 RFC9334 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. By introducing a shared message format like the CMW, we can consistently support different attestation message types, evolve message serialization formats without breaking compatibility, and avoid having to redefine how messages are handled in each protocol. arm Linaro This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT). Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat. 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. Fraunhofer SIT University of Surrey University of Surrey Ubitech Microsoft This document maps the concept of Direct Anonymous Attestation (DAA) to the Remote Attestation Procedures (RATS) Architecture. The protocol entity DAA Issuer is introduced and its mapping with existing RATS roles in DAA protocol steps is specified. Siemens Siemens When an end entity includes attestation Evidence in a Certificate Signing Request (CSR), it may be necessary to demonstrate the freshness of the provided Evidence. Current attestation technology commonly achieves this using nonces. This document outlines the process through which nonces are supplied to the end entity by an RA/CA for inclusion in Evidence, leveraging the Certificate Management Protocol (CMP) and Enrollment over Secure Transport (EST) Arm Limited Arm Limited HP Labs Linaro The Arm Platform Security Architecture (PSA) is a family of hardware and firmware security specifications, as well as open-source reference implementations, to help device makers and chip manufacturers build best-practice security into products. Devices that are PSA compliant can produce attestation tokens as described in this memo, which are the basis for many different protocols, including secure provisioning and network access control. This document specifies the PSA attestation token structure and semantics. The PSA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by PSA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. Arm Limited Linaro Mediatek Inc The Arm Confidential Compute Architecture (CCA) is series of hardware and software innovations that enhance Arm’s support for Confidential Computing for large, compute-intensive workloads. Devices that implement CCA can produce attestation tokens as described in this memo, which are the basis for trustworthiness assessment of the Confidential Compute environment. This document specifies the CCA attestation token structure and semantics. The CCA attestation token is a profile of the Entity Attestation Token (EAT). This specification describes what claims are used in an attestation token generated by CCA compliant systems, how these claims get serialized to the wire, and how they are cryptographically protected. This informational document is published as an independent submission to improve interoperability with Arm's architecture. It is not a standard nor a product of the IETF. Armidale Consulting Fraunhofer SIT Linaro In the IETF Remote Attestation Procedures (RATS) architecture, a Verifier accepts Evidence and, using Appraisal Policy typically with additional input from Endorsements and Reference Values, generates Attestation Results in formats that are useful for Relying Parties. This document illustrates the purpose and role of Endorsements and discusses some considerations in the choice of message format for Endorsements in the scope of the RATS architecture. This document does not aim to define a conceptual message format for Endorsements and Reference Values. Instead, it extends RFC9334 to provide further details on Reference Values and Endorsements, as these topics were outside the scope of the RATS charter when RFC9334 was developed. Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. CA/Browser Forum Trusted Computing Group Trusted Computing Group OASIS n.d. 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.

Examples This section provides an example that conveys an Arm Platform Security Architecture token, which provides claims about the used hardware and software platform, into the CSR. After publication of this document, additional examples and sample data will be collected at the following GitHub repository : https://github.com/lamps-wg/csr-attestation-examples

Extending EvidenceStatementSet As defined in , EvidenceStatementSet acts as a way to provide an ASN.1 compiler or runtime parser with a list of OBJECT IDENTIFIERs that are known to represent EvidenceStatements -- and are expected to appear in an EvidenceStatement.type field, along with the ASN.1 type that should be used to parse the data in the associated EvidenceStatement.stmt field. Essentially this is a mapping of OIDs to data structures. Implementers are expected to populate it with mappings for the Evidence types that their application will be handling. This specification aims to be agnostic about the type of data being carried, and therefore does not specify any mandatory-to-implement Evidence types. As an example of how to populate EvidenceStatementSet, implementing the CMW and PSA Evidence types would result in the following EvidenceStatementSet definition:

PSA Attestation Token in CSR The Platform Security Architecture (PSA) Attestation Token is defined in and specifies claims to be included in an Entity Attestation Token (EAT). defines key attestation based on the EAT format. In this section the platform attestation offered by is combined with key attestation by binding the key attestation token (KAT) to the platform attestation token (PAT) with the help of the nonce. For details see . The resulting KAT-PAT bundle is, according to , combined in a CMW collection . The encoding of this KAT-PAT bundle is shown in the example below. EvidenceStatement + | +-> type: OID for CMW Collection | 1 3 6 1 5 5 7 1 TBD | +-> stmt: KAT/PAT CMW Collection ]]> The value in EvidenceStatement->stmt is based on the KAT/PAT example from and the result of CBOR encoding the CMW collection shown below (with line-breaks added for readability purposes):

Confidential Compute Architecture (CCA) Platform Token in CSR The Confidential Compute Architecture (CCA) Platform Token is described in and is also based on the EAT format. Although the full CCA attestation is composed of Realm and Platform Evidence, for the purposes of this example only the Platform token is provided. EvidenceStatement + | +-> type: OID for CCA Platform Attestation Toekn | 1 3 6 1 5 5 7 1 TBD | +-> stmt: CCA Platform Token ]]> Although the CCA Platform Token follows the EAT/CMW format, it is untagged. This is because the encoding can be discerned in the CSR based on the OID alone. The untagged token based on a sample claim set is provided below: Realm evidence can be included in a CMW bundle, similar to the PSA token. In this case, the CSR is constructed as follows: EvidenceStatement + | +-> type: OID for CMW Collection | 1 3 6 1 5 5 7 1 TBD | +-> stmt: Realm Token/Platform Token CMW Collection or Realm Claim Set/Platform Token CMW Collection ]]>

ASN.1 Module

TCG DICE Example in ASN.1 This section gives an example of extending the ASN.1 module above to carry an existing ASN.1-based Evidence Statement. The example used is the Trusted Computing Group DICE Attestation Conceptual Message Wrapper, as defined in .

TCG DICE TcbInfo Example in CSR This section gives an example of extending the ASN.1 module above to carry an existing ASN.1-based evidence statement. The example used is the Trusted Computing Group DiceTcbInfo, as defined in .

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, 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.