]> Entrust Limited

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

Siemens

Hannes.Tschofenig@gmx.net

Fraunhofer SIT

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

PKI PKCS#10 CFMF Attestation Evidence Certificate Signing Requests A client requesting a certificate from a Certification Authority (CA) may wish to offer believable claims about the protections afforded to the corresponding private key, such as whether the private key resides on a hardware security module or the protection capabilities provided by the hardware. This document describes how to encode Evidence produced by an Attester for inclusion in Certificate Signing Requests (CSRs), and any certificates necessary for validating it. Including Evidence along with a CSR can help to improve the assessment of the security posture for the private key, and the trustworthiness properties of the submitted key to the requested certificate profile. These Evidence Claims can include information about the hardware component's manufacturer, the version of installed or running firmware, the version of software installed or running in layers above the firmware, or the presence of hardware components providing specific protection capabilities or shielded locations (e.g., to protect keys). 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 Evidence of the security properties of its environments in which the private keys are stored in that request. This Evidence can be appraised by authoritative entities, such as a Registration Authority (RA) or a CA, or associated trusted Verifiers as part of validating an incoming certificate request against given certificate policies. Regulatory bodies are beginning to require proof-of-hardware residency for certain classifications of cryptographic keys. At the time of writing, the most notable example is the Code-Signing Baseline Requirements 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". This specification defines an attribute and an extension that allow for conveyance of Evidence in Certificate Signing Requests (CSRs) in either PKCS#10 or Certificate Request Message Format (CRMF) payloads which provides an elegant and automatable mechanism for meeting requirements such as those in the CA/B Forum's . As outlined in the RATS Architecture , an Attester (typically a device) produces a signed collection of Claims that constitutes Evidence about its running environment. While the term "attestation" is not defined in RFC 9334, it was later defined in , it refers to the activity of producing and appraising remote attestation Evidence. A Relying Party may consult an Attestation Result produced by a Verifier that has appraised the Evidence in making policy decisions about the trustworthiness of the Target Environment being assessed via appraisal of Evidence. provides the basis to illustrate in this document how the various roles in the RATS architecture map to a certificate requester and a CA/RA. At the time of writing, several standard and several proprietary attestation technologies are in use. This specification thereby is intended to be as technology-agnostic as it is feasible with respect to implemented remote attestation technologies. Instead, it focuses on (1) the conveyance of Evidence via CSRs while making minimal assumptions about content or format of the transported Evidence and (2) the conveyance of sets of certificates used for validation of Evidence. The certificates typically contain one or more certification paths rooted in a device manufacture trust anchor and the leaf certificate being on the device in question; the latter is the Attestation Key that signs the Evidence statement. This document specifies a CSR Attribute (or Extension for Certificate Request Message Format (CRMF) CSRs) for carrying Evidence. Evidence can be placed into an EvidenceStatement along with an OID to identify its type and optionally a hint to the Relying Party about how to verify it. A set of EvidenceStatements may be grouped together along with the set of CertificateAlternatives needed to validate them to form a EvidenceBundle. One or more EvidenceBundles may be placed into the id-aa-evidence CSR Attribute (or CRFM Extension). A CSR may contain one or more Evidence payloads, for example Evidence asserting the storage properties of a private key as well Evidence asserting firmware version and other general properties of the device, or Evidence signed using different cryptographic algorithms. With these attributes, additional information 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 within CSR. The exact format of the Evidence being conveyed is 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, Claim, Attestation Results (AR), Attester, Verifier, Target Environment, Attesting Environment, 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 Signing 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 Certificate Request Message Format (CRMF) to be "CSRs". We use the terms "CSR" and Certificate Request message interchangeably.

Architecture shows the high-level communication pattern of the RATS background check model where the Attester transmits the Evidence in the CSR to the RA and the 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. In addition to the background check model the RATS architecture also specifies the passport model and combinations. See Section 5.2 of for a description of the passport model. The passport model requires the Attester to transmit Evidence to the Verifier directly in order to obtain the Attestation Result, which is then forwarded to the Relying Party. This specification utilizes the background model since CSRs are often used as one-shot messages where no direct real-time interaction between the Attester and the Verifier is possible. Note that the Verifier is a logical role that may be included in the RA/CA product. In this case the Relying Party and Verifier collapse into a single entity. The Verifier functionality can, however, also be kept separate from the RA/CA functionality, such as a utility or library provided by the device manufacturer. For example, security concerns may require parsers of Evidence formats to be logically or physically separated from the core CA functionality. The interface by which the Relying Party passes Evidence to the Verifier and receives back Attestation Results may be proprietary or standardized, but in any case is out-of-scope for this document.

Architecture with Background Check Model. |----' | Compare Attestation | Attester | Evidence | Relying | Result against | (/w HSM) | in CSR | Party (RA/CA) | policy '------------' '---------------' ]]>

As discussed in RFC 9334, different security and privacy aspects need to be considered. For example, Evidence may need to be protected against replay and Section 10 of RFC 9334 lists approach for offering freshness. There are also concerns about the exposure of persistent identifiers by utilizing attestation technology, which are discussed in Section 11 of RFC 9334. 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 Section 12 of RFC 9334. 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 from the Attester to the Relying Party via existing CSR messages.

Information Model

Interaction with an HSM This specification is intended to be applicable both in cases where the CSR is constructed internally or externally to the attesting environment, from the point of view of the calling application. Cases where the CSR is generated internally to the attesting environment are straightforward: the HSM generates and embeds the Evidence and the corresponding certificate chains when constructing the CSR. Cases where the CSR is generated externally may require extra round-trips of 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, consider 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) | |----------------->| | | |<-----------------| | | ]]>

Implementation Strategies To support a number of different use cases for the transmission of Evidence in a CSR (together with certificate chains) the structure shown in is used. On a high-level, the structure can be explained as follows: A PKCS#10 attribute or a CRMF extension contains one or more EvidenceBundle structures. Each EvidenceBundle contains one or more EvidenceStatement structures as well as one or more CertificateAlternatives which enable to carry various format of certificates.

Information Model for CSR Evidence Conveyance.

The following use cases are supported: Single Attester, which only distributes Evidence without any certificate chains, i.e. the Verifier is assumed to be in possession of the certificate chain already or there is no certificate chain because the Verifier directly trusts the Attester key. As a result a single EvidenceBundle is included in a CSR that contains a single EvidenceStatement without the CertificateAlternatives structure. shows this use case.

Use Case 1: Single Attester without Certificate Chain.

A single Attester, which shares Evidence together with a certificate chain. The CSR conveys a single EvidenceBundle with a single EvidenceStatement and a single CertificateAlternatives structure. shows this use case.

Use Case 2: Single Attester with Certificate Chain.

In a Composite Device, which contains multiple Attesters, a collection of Evidence statements is obtained. Imagine that each Attester returns its Evidence together with a certificate chain. As a result, multiple EvidenceBundle structures, each carrying an EvidenceStatement and the corresponding CertificateAlternative structure with the certificate chain as provided by each Attester, are included in the CSR. This may result in certificates being duplicated across multiple EvidenceBundles. This approach does not require any processing capabilities by a lead Attester since the information is merely forwarded. shows this use case.

Use Case 3: Multiple Attesters in Composite Device.

In the last scenario, we also assume a Composite Device with additional processing capabilities of the Leader Attester, which parses the certificate chains provided by all Attesters in the device and removes redundant certificate information. The benefit of this approach is the reduced transmission overhead. There are several implementation strategies and we show two in .

Use Case 4: Multiple Attesters in Composite Device (with Optimization). | CertificateAlternatives |/ Certificate +-------------------------+ .... +-------------------------+ | EvidenceBundle (n) |\ +-------------------------+ \ Provided by End-Entity | EvidenceStatement | / Attester n Certificate-->| CertificateAlternatives |/ +-------------------------+ Implementation strategy (4b) +------------------------------+ | EvidenceBundle | +------------------------------+ | EvidenceStatement (1) | | ... | | EvidenceStatement (n) | | CertificateAlternatives { | | End Entity Certificate (1) | | ... | | End Entity Certificate (n) | | | | } | +------------------------------+ ]]>

In implementation strategy (4a) we assume that each Attester is provisioned with a unique end-entity certificate. Hence, the certificate chains will at least differ with respect to the end-entity certificates. The Lead Attester will therefore create multiple EvidenceBundle structures, each will carry an EvidenceStatement followed by a certificate chain in the CertificateAlternative structures containing most likely only the end-entity certificate. The shared certificate chain is carried in the first entry of the EvidenceBundle sequence to allow path validation to take place immediately after processing the first structure. This implementation strategy may place extra burden on the Relying Party to parse EvidenceBundles and reconstruct certificate chains if the Verifier requires each EvidenceStatement to be accompanied with a complete certificate chain. Implementation strategy (4b), as an alternative, requires the Lead Attester to merge all certificate chains into a single EvidenceBundle containing a single de-duplicated sequence of CertificateAlternatives structures. This means that each EvidenceBundle is self-contained and any EvidenceStatement can be verified using only the sequence of CertificateAlternatives in its bundle, but Verifiers will have to do proper certification path building since the sequence of CertificateAlternatives is now a cert bag and not a cert chain. This implementation strategy may place extra burden on the Attester in order to allow the Relying Party to treat the Evidence and Certificates as opaque content. It also may place extra burden on the Verifier since this implementation strategy requires it to be able to perform X.509 path building over a bag of certificates that may be out of order or contain extraneous certificates. Note: This specification does not mandate optimizing certificate chains since there is a trade-off between the Attester implementation complexity and the transmission overhead.

ASN.1 Elements

Object Identifiers We reference id-pkix and id-aa, both defined in . We define:

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 or more Evidence bundles of type EvidenceBundle which each contain one or more Evidence statements of a type EvidenceStatement along with an optional certificate chain. This structure allows for grouping Evidence statements that share a certificate chain. This is a mapping and ASN.1 Types for Evidence Statements to the OIDs that identify them. These mappings are are used to construct or parse EvidenceStatements. These would typically be Evidence Statement formats defined in other IETF standards, defined by other standards bodies, or vendor proprietary formats along with the OIDs that identify them. This list is left empty in this document. However, implementers should populate it with the formats that they wish to support. The type is on OID indicating the format of the data contained in stmt. The hint is intended for an Attester to indicate to the Relying Party (RP) which Verifier should be invoked to parse this statement. In many cases, the type OID will already uniquely indicate which Verifier to invoke; for example because the OID indicates a proprietary Evidence format for which the RP has corresponding proprietary Verifier. However, in some cases it may still be ambiguous, or the type may indicate another layer of conceptual message wrapping in which case it is helpful to the RP to bring this hint outside of the statement. It is assumed that the RP must be pre-configured with a list of trusted Verifiers and that the contents of this hint can be used to look up the correct Verifier. Under no circumstances must the RP be tricked into contacting an unknown and untrusted Verifier since the returned Attestation Result must not be relied on. The format and contents of the hint are out of scope of this document. The Extension variant is intended only for use within CRMF CSRs and MUST NOT 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. The certs contains a set of certificates that may be needed to validate the contents of an Evidence statement contained in evidence. The set of certificates should contain the object that contains the public key needed to directly validate the evidence. The remaining elements should chain that data back to an agreed upon trust anchor used for attestation. No order is implied, it is up to the Attester and its Verifier to agree on both the order and format of certificates contained in certs. A CSR MAY contain one or more instances of attr-evidence or ext-evidence. This means that the SEQUENCE OF EvidenceBundle is redundant with the ability to carry multiple attr-evidence or ext-evidence at the CSR level; either mechanism MAY be used for carrying multiple Evidence bundles.

CertificateAlternatives This is an ASN.1 CHOICE construct used to represent an encoding of a broad variety of certificate types. "Certificate" is a standard X.509 certificate that MUST be compliant with RFC 5280. Enforcement of this constraint is left to the relying parties. "TypedCert" is an ASN.1 construct that has the characteristics of a certificate, but is not encoded as an X.509 certificate. The certType Field (below) indicates how to interpret the certBody field. While it is possible to carry any type of data in this structure, it's intended the content field include data for at least one public key formatted as a SubjectPublicKeyInfo (see ). "TypedFlatCert" is a certificate that does not have a valid ASN.1 encoding. These are often compact or implicit certificates used by smart cards. certType indicates the format of the data in the certBody field, and ideally refers to a published specification.

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

• 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

• Evidence Statement
  • Decimal: IANA Assigned - Replace TBDAA
  • Description: id-aa-evidence
  • References: This Document

"SMI Security for PKIX Evidence Statement Formats" Registry IANA is asked to create a registry for Evidence Statement Formats within the SMI-numbers registry, allocating an assignment from id-pkix ("SMI Security for PKIX" Registry) for the purpose.

• Decimal: IANA Assigned - replace TBD1
• Description: id-ata
• References: This document
• Initial contents: None
• Registration Regime: Specification Required. Document must specify an EVIDENCE-STATEMENT definition to which this Object Identifier shall be bound.

Columns:

• Decimal: The subcomponent under id-ata
• Description: Begins with id-ata
• References: RFC or other document

Attestation Evidence OID Registry IANA is asked to create a registry that helps developers to find OID/Evidence mappings. Registration requests are evaluated using the criteria described in the registration template below after a three-week review period on the [[TBD]] 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.
• 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 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: For Standards Track RFCs, list the "IESG". For others, give the name of the responsible party. In most cases the third party requesting registration in this registry will also be the party that registered the OID.

Initial Registry Contents The initial registry contents is shown in the table below. It lists two entries, one for DICE-based Evidence and the second for the Conceptual Message Wrapper (CMW) .

Initial Contents of the Attestation Evidence OID Registry

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

Security Considerations A PKCS#10 or CRMF Certification Request message typically consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. In general usage, the private key used to sign the CSR MUST be different from the Attesting Key utilized to sign Evidence about the Target Environment, though exceptions MAY be made where CSRs and Evidence are involved in bootstrapping the Attesting 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 (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 Evidence generated by an Attester generally needs to be fresh to provide value to the Verifier since the configuration on the device may change over time. Section 10 of 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 (unidirectional) communication prior to Evidence and CSR generation. This document only specifies how to carry existing Evidence formats inside a CSR, and so issues of synchronizing freshness data is left to be handled, for example, via certificate management protocols. 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 definition of "fresh" is 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.

Publishing evidence in an X.509 extension This document specifies and Extension for carrying Evidence in a CRMF Certificate Signing Request (CSR), but it is intentionally NOT RECOMMENDED for a CA to copy the ext-evidence or ext-evidenceCerts extensions 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".

Type OID and verifier hint The EvidenceStatement includes both a type OID and a free form 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, such as Verifier libraries that have been compiled in to the RP application. As an example, the hint may take the form of an FQDN to uniquely identify a Verifier implementation, but 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, Debug, empty CMW contents, or similar values that could cause the Evidence to appear to be valid when in fact it was not properly checked.

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 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. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Fraunhofer SIT Intel Linaro This document defines two encapsulation formats for RATS conceptual messages (i.e., Evidence, Attestation Results, Endorsements and Reference Values.) The first encapsulation format uses a CBOR or JSON array with two mandatory members, one for the type, another for the value, and a third optional member complementing the type field that says which kind of conceptual message(s) are carried in the value. The other format wraps the value in a CBOR byte string and prepends a CBOR tag to convey the type information. This document also defines a corresponding CBOR tag, as well as JSON Web Tokens (JWT) and CBOR Web Tokens (CWT) claims. These allow embedding the wrapped conceptual messages into CBOR-based protocols and web APIs, respectively. 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. Arm Limited Arm Limited HP Labs Linaro The 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 profiled 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 document is produced through the Independent RFC Stream and was not subject to the IETF's approval process. Trusted Computing Group CA/Browser Forum Trusted Computing Group OASIS Juniper Networks, Inc. Cisco Systems National Security Agency This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules [TPM1.2], [TPM2.0], 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 two non-normative examples for embedding Evidence in CSRs. The first example embeds Evidence produced by a TPM in the CSR. The second example conveys an Arm Platform Security Architecture token, which provides claims about the used hardware and software platform, into the CSR. At the time of writing, the authors are not aware of registered OIDs for these evidence formats, and so we leave the OIDs as TBD1 / TBD2.

TPM V2.0 Evidence in CSR The following example illustrates a CSR with a signed TPM Quote based on . The Platform Configuration Registers (PCRs) are fixed-size registers in a TPM that record measurements of software and configuration information and are therefore used to capture the system state. The digests stored in these registers are then digitally signed with an attestation key known to the hardware. Note: The information conveyed in the value field of the EvidenceStatement structure may contain more information than the signed TPM Quote structure defined in the TPM v2.0 specification , such as plaintext PCR values, the up-time, the event log, etc. The detailed structure of such payload is, however, not defined in this document and may be subject to future standardization work in supplementary documents.

CSR with TPM V2.0

Platform Security Architecture Attestation Token in CSR The example shown in illustrates how the Arm Platform Security Architecture (PSA) Attestation Token is conveyed in a CSR. The content of the Evidence in this example is re-used from and contains an Entity Attestation Token (EAT) digitally signed with an attestation private key.

CSR with embedded PSA Attestation Token

The decoded Evidence is shown in Appendix A of , the shown Evidence provides the following information to an RA/CA:

• Boot seed,
• Firmware measurements,
• Hardware security certification reference,
• Identification of the immutable root of trust implementation, and
• Lifecycle state information.

ASN.1 Module

TCG DICE ConceptualMessageWrapper 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 DICE Attestation Conceptual Message Wrapper, 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: 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, Michael StJohns, Carl Wallace, Michael Ricardson, Tomofumi Okubo, Olivier Couillard, John Gray, Eric Amador, Johnson Darren, Herman Slatman, Tiru Reddy, Thomas Fossati, Corey Bonnel, Argenius Kushner, James Hagborg, Monty Wiseman, Ned Smith. We would like to specifically thank Mike StJohns for his work on an earlier version of this draft. Finally, we would like to thank Andreas Kretschmer for his feedback based on his implementation experience, and Daniel Migault and Russ Housley for their review comments.