Network Working Group M. Ounsworth Internet-Draft Entrust Intended status: Standards Track H. Tschofenig Expires: 6 April 2024 Siemens H. Birkholz Fraunhofer SIT 4 October 2023 Use of Remote Attestation with Certificate Signing Requests draft-ietf-lamps-csr-attestation-01 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://lamps- wg.github.io/csr-attestation/draft-ounsworth-csr-attestation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-csr-attestation/. Source for this draft and an issue tracker can be found at https://github.com/lamps-wg/csr-attestation. Ounsworth, et al. Expires 6 April 2024 [Page 1] Internet-Draft Remote Attestation with CSRs October 2023 Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 6 April 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 4. ASN.1 Elements . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Object Identifiers . . . . . . . . . . . . . . . . . . . 6 4.2. Evidence Attribute and Extension . . . . . . . . . . . . 6 4.3. CertificateChoice . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5.1. Object Identifier Allocations . . . . . . . . . . . . . . 9 5.1.1. Module Registration - SMI Security for PKIX Module Identifier . . . . . . . . . . . . . . . . . . . . . 9 5.1.2. Object Identifier Registrations - SMI Security for S/ MIME Attributes . . . . . . . . . . . . . . . . . . . 9 5.1.3. "SMI Security for PKIX Evidence Statement Formats" Registry . . . . . . . . . . . . . . . . . . . . . . 9 Ounsworth, et al. Expires 6 April 2024 [Page 2] Internet-Draft Remote Attestation with CSRs October 2023 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Publishing evidence in an X.509 extension . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 14 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 15 A.1. TPM V2.0 Evidence in CSR . . . . . . . . . . . . . . . . 15 A.2. Platform Security Architecture Attestation Token in CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 B.1. TCG DICE ConceptualMessageWrapper in CSR . . . . . . . . 20 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. 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. This specification defines an attribute and an extension that allow for conveyance of Evidence in Certificate Signing Requests (CSRs) in either PKCS#10 [RFC2986] or Certificate Request Message Format (CRMF) [RFC4211] payloads. As outlined in the RATS Architecture [RFC9334], 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 [I-D.ietf-rats-tpm-based-network-device-attest], 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. Section 3 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 Ounsworth, et al. Expires 6 April 2024 [Page 3] Internet-Draft Remote Attestation with CSRs October 2023 (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 two ATTRIBUTE/Attribute definitions. The first Attribute may be used to carry a set of certificates or public keys that may be required to validate signed Evidence. The second Attribute carries a structure that may be used to convey Evidence. 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 about whether to issue a certificate and what information to populate into the certificate is available to an RA or CA. 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document re-uses the terms defined in [RFC9334] related to remote attestation. Readers of this document are assumed to be familiar with the following terms: Evidence, Claim, Attestation Results (AR), Attester, Verifier, Target Environment, Attesting Environment, and Relying Party (RP). The term "Certification Request" message is defined in [RFC2986]. Specifications, such as [RFC7030], later introduced the term "Certificate Signing Request (CSR)" to refer to the Certification Request message. While the term "Certification 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) [RFC4211] to be "CSRs". We use the terms "CSR" and Certificate Request message interchangeably. Ounsworth, et al. Expires 6 April 2024 [Page 4] Internet-Draft Remote Attestation with CSRs October 2023 3. Architecture Figure 1 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 [RFC9334] 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. .-------------. | | Compare Evidence | Verifier | against | | policy '--------+----' ^ | Evidence | | Attestation | | Result | v .------------. .----|----------. | +-------------->|----' | Compare Attestation | Attester | Evidence | Relying | Result against | | in CSR | Party (RA/CA) | policy '------------' '---------------' Figure 1: Architecture with Background Check Model. 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 Ounsworth, et al. Expires 6 April 2024 [Page 5] Internet-Draft Remote Attestation with CSRs October 2023 identifiers by utilizing attestation technology, which are discussed in Section 11 of RFC 9334. Finally, the keying material used by the Attester need 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. 4. ASN.1 Elements 4.1. Object Identifiers We reference id-pkix and id-aa, both defined in [RFC5912]. We define: -- Arc for Evidence types id-ata OBJECT IDENTIFIER ::= { id-pkix (TBD1) } 4.2. 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. Ounsworth, et al. Expires 6 April 2024 [Page 6] Internet-Draft Remote Attestation with CSRs October 2023 EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER EvidenceStatementSet EVIDENCE-STATEMENT ::= { ... -- Empty for now -- } EvidenceStatement ::= SEQUENCE { type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}), stmt EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}) } id-aa-evidenceStatement OBJECT IDENTIFIER ::= { id-aa TBDAA } -- For PKCS#10 attr-evidence ATTRIBUTE ::= { TYPE SEQUENCE OF EvidenceBundle IDENTIFIED BY id-aa-evidenceStatement } -- For CRMF ext-evidence EXTENSION ::= { SYNTAX SEQUENCE OF EvidenceBundle IDENTIFIED BY id-aa-evidenceStatement } The Extension version 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 Section 6 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. We are leaving the SEQUENCE OF EvidenceBundle since it is in general more flexible than relying on the containing structure to handle multiplicity and allows for this structure to be re-used in the future in other PKIX protocol contexts. Ounsworth, et al. Expires 6 April 2024 [Page 7] Internet-Draft Remote Attestation with CSRs October 2023 4.3. CertificateChoice This is an ASN.1 CHOICE construct used to represent an encoding of a broad variety of certificate types. CertificateChoice ::= CHOICE { cert Certificate, opaqueCert [0] IMPLICIT OCTET STRING, typedCert [1] IMPLICIT TypedCert, typedFlatCert [2] IMPLICIT TypedFlatCert } "Certificate" is a standard X.509 certificate that MUST be compliant with RFC 5280. Enforcement of this constraint is left to the relying parties. "opaqueCert" should be used sparingly as it requires the Verifier to implictly know its format. It is encoded as an OCTET STRING. "TypedCert" is an ASN.1 construct that has the charateristics 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 [RFC5912]). TYPED-CERT ::= TYPE-IDENTIFIER CertType ::= TYPED-CERT.&id TypedCert ::= SEQUENCE { certType TYPED-CERT.&id({TypedCertSet}), content TYPED-CERT.&Type ({TypedCertSet}{@certType}) } TypedCertSet TYPED-CERT ::= { ... -- Empty for now, } "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. Ounsworth, et al. Expires 6 April 2024 [Page 8] Internet-Draft Remote Attestation with CSRs October 2023 TypedFlatCert ::= SEQUENCE { certType OBJECT IDENTIFIER, certBody OCTET STRING } 5. IANA Considerations IANA is requested to open one new registry, 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. 5.1. Object Identifier Allocations 5.1.1. 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 5.1.2. Object Identifier Registrations - SMI Security for S/MIME Attributes * Attest Statement - Decimal: IANA Assigned - Replace *TBDAA* - Description: id-aa-evidenceStatement - References: This Document 5.1.3. "SMI Security for PKIX Evidence Statement Formats" Registry Please open up 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 Ounsworth, et al. Expires 6 April 2024 [Page 9] Internet-Draft Remote Attestation with CSRs October 2023 * 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 6. Security Considerations A PKCS#10 or CRMF Certification Request message consists of a distinguished name, a public key, and optionally a set of attributes, collectively signed by the entity requesting certification. The private key used to sign the CSR MUST be different from the Attesting Key utilized to sign Evidence about the Target Environment. Key separation is an important principle in cryptography and also applies to this specification with regards to the Attestation Key and the CSR signing 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 Figure 2). Figure 2 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. Ounsworth, et al. Expires 6 April 2024 [Page 10] Internet-Draft Remote Attestation with CSRs October 2023 ^ |CSR with |Evidence .-------------+-------------. | | | CSR Library |<-----+ | | | '---------------------------' | | ^ ^ | Private | | Public | Signature | Key | | Key | Operation | Generation | | Export | | | | | | .----------|--|---------|------------. | | | | | Attester| | | v | v (HSM) | | | .-----------------------. | | | | Target Environment | | | | | (with key generation, | | | | | storage and usage) | | | | '--------------+--------' | | | | | | | Collect | | | | Claims | | | | | | | | v | | | .-------------. | | |Attestation | Attesting | | | | Key ----->| Environment +----------+ | | (Firmware) |Evidence| | '-------------' | | | '------------------------------------' Figure 2: Interaction between Attesting and Target Environment Figure 2 places the CSR library outside the Attester, which is an implementation choice. 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 example, one implementation may perform a software measurement of the CSR library along with the crypto library implementation that has access to the keying material. 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. Ounsworth, et al. Expires 6 April 2024 [Page 11] Internet-Draft Remote Attestation with CSRs October 2023 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 [CSBR] 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. 6.1. 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 [RFC9334] 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 an extra message exchange via the Relying Party and the use of timestamps requires synchronized clocks. Epochs also require (unidirectional) communication. None of these things are practical when interacting with Hardware Security Modules (HSM). Additionally, the definition of "fresh" is somewhat ambiguous in the context of CSRs, especially considering that non-automated certificate enrollments are often asyncronous, 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 Ounsworth, et al. Expires 6 April 2024 [Page 12] Internet-Draft Remote Attestation with CSRs October 2023 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. Developers, operators, and designers of protocols, which embed Evidence-carrying-CSRs, need to 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 implementors. 6.2. 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". 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . Ounsworth, et al. Expires 6 April 2024 [Page 13] Internet-Draft Remote Attestation with CSRs October 2023 [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . 7.2. Informative References [CSBR] CA/Browser Forum, "Baseline Requirements for Code-Signing Certificates, v.3.3", June 2023, . [I-D.ietf-rats-tpm-based-network-device-attest] Fedorkow, G., Voit, E., and J. Fitzgerald-McKay, "TPM- based Network Device Remote Integrity Verification", Work in Progress, Internet-Draft, draft-ietf-rats-tpm-based- network-device-attest-14, 22 March 2022, . [I-D.tschofenig-rats-psa-token] Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and T. Fossati, "Arm's Platform Security Architecture (PSA) Attestation Token", Work in Progress, Internet-Draft, draft-tschofenig-rats-psa-token-13, 1 September 2023, . [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., "Enrollment over Secure Transport", RFC 7030, DOI 10.17487/RFC7030, October 2013, . [TCGDICE1.1] Trusted Computing Group, "DICE Attestation Architecture, v.1.1", May 2023, . Ounsworth, et al. Expires 6 April 2024 [Page 14] Internet-Draft Remote Attestation with CSRs October 2023 [TPM20] Trusted Computing Group, "Trusted Platform Module Library Specification, Family 2.0, Level 00, Revision 01.59", November 2019, . Appendix A. 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. A.1. TPM V2.0 Evidence in CSR The following example illustrates a CSR with a signed TPM Quote based on [TPM20]. 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 digitially 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 [TPM20], 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. Certification Request: Data: Version: 1 (0x0) Subject: CN = server.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b9:7c:02:a1:1f:9c:f3:f4:c4:55:3a:d9:3e:26: e8:e5:11:63:84:36:5f:93:a6:99:7d:d7:43:23:0a: 4f:c0:a8:40:46:7e:8d:b2:1a:38:19:ff:6a:a7:38: 16:06:1e:12:9f:d1:d5:58:55:e6:be:6d:bb:e1:fb: f7:70:a7:5c:c9 ASN1 OID: prime256v1 NIST CURVE: P-256 Attributes: EvidenceStatement Ounsworth, et al. Expires 6 April 2024 [Page 15] Internet-Draft Remote Attestation with CSRs October 2023 type: TBD2 (identifying use of TPM V2.0) value: 80:02:00:00:01:99:00:00:00:00:00:00:01:86:00:7e ff:54:43:47:80:18:00:22:00:0b:76:71:0f:61:80:95 8d:89:32:38:a6:cc:40:43:02:4a:da:26:d5:ea:11:71 99:d7:a5:59:a4:18:54:1e:7b:86:00:0d:30:2e:66:6e 6a:37:66:63:39:31:76:62:74:00:00:00:00:00:00:36 5b:bc:0b:71:4f:d8:84:90:09:01:42:82:48:a6:46:53 98:96:00:00:00:01:00:0b:03:0f:00:00:00:20:49:ce 66:9a:aa:7e:52:ff:93:0e:dd:9f:27:97:88:eb:75:cb ad:53:22:e5:ad:2c:9d:44:1e:dd:65:48:6b:88:00:14 00:0b:01:00:15:a4:95:8a:0e:af:04:36:be:35:f7:27 85:bd:7f:87:46:74:18:e3:67:2f:32:f2:bf:b2:e7:af a1:1b:f5:ca:1a:eb:83:8f:2f:36:71:cd:7c:18:ab:50 3d:e6:6e:ab:2e:78:a7:e4:6d:cf:1f:03:e6:46:74:28 a7:6c:d6:1e:44:3f:88:89:36:9a:a3:f0:9a:45:07:7e 01:5e:4c:97:7d:3f:e2:f7:15:59:96:5f:0e:9a:1c:b3 a0:6b:4a:77:a5:c0:e0:93:53:cb:b7:50:59:3d:23:ee 5c:31:00:48:6c:0b:1a:b8:04:a4:14:05:a6:63:bc:36 aa:7f:b9:aa:1f:19:9e:ee:49:48:08:e1:3a:d6:af:5f d5:eb:96:28:bf:41:3c:89:7a:05:4b:b7:32:a2:fc:e7 f6:ad:c7:98:a6:98:99:f6:e9:a4:30:d4:7f:5e:b3:cb d7:cc:76:90:ef:2e:cc:4f:7d:94:ab:33:8c:9d:35:5d d7:57:0b:3c:87:9c:63:89:61:d9:5c:a0:b7:5c:c4:75 21:ae:dc:c9:7c:e3:18:a2:b3:f8:15:27:ff:a9:28:2f cb:9b:17:fe:96:04:53:c4:19:0e:bf:51:0e:9d:1c:83 49:7e:51:64:03:a1:40:f1:72:8b:74:e3:16:79:af:f1 14:a8:5e:44:00:00:01:00:00 Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:45:02:21:00:93:fd:81:03:75:d1:7d:ab:53:6c:a5:19:a7: 68:3d:d6:e2:39:14:d6:9e:47:24:38:b5:76:db:18:a6:ca:c4: 8a:02:20:36:be:3d:71:93:5d:05:c3:ac:fa:a8:f3:e5:46:db: 57:f9:23:ee:93:47:6d:d6:d3:4f:c2:b7:cc:0d:89:71:fe Figure 3: CSR with TPM V2.0 A.2. Platform Security Architecture Attestation Token in CSR The example shown in Figure 4 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 [I-D.tschofenig-rats-psa-token] and contains an Entity Attestation Token (EAT) digitally signed with an attestation private key. Ounsworth, et al. Expires 6 April 2024 [Page 16] Internet-Draft Remote Attestation with CSRs October 2023 Certification Request: Data: Version: 1 (0x0) Subject: CN = server.example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (256 bit) pub: 04:b9:7c:02:a1:1f:9c:f3:f4:c4:55:3a:d9:3e:26: e8:e5:11:63:84:36:5f:93:a6:99:7d:d7:43:23:0a: 4f:c0:a8:40:46:7e:8d:b2:1a:38:19:ff:6a:a7:38: 16:06:1e:12:9f:d1:d5:58:55:e6:be:6d:bb:e1:fb: f7:70:a7:5c:c9 ASN1 OID: prime256v1 NIST CURVE: P-256 Attributes: EvidenceStatement type: TBD1 (referring to the PSA Attestation Token) value: d2:84:43:a1:01:26:a0:59:01:3b:aa:19:01:09:78: 18:68:74:74:70:3a:2f:2f:61:72:6d:2e:63:6f:6d: 2f:70:73:61:2f:32:2e:30:2e:30:19:09:5a:1a:7f: ff:ff:ff:19:09:5b:19:30:00:19:09:5c:58:20:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00: 00:19:09:5d:48:00:00:00:00:00:00:00:00:19:09: 5e:73:31:32:33:34:35:36:37:38:39:30:31:32:33: 2d:31:32:33:34:35:19:09:5f:81:a2:02:58:20:03: 03:03:03:03:03:03:03:03:03:03:03:03:03:03:03: 03:03:03:03:03:03:03:03:03:03:03:03:03:03:03: 03:05:58:20:04:04:04:04:04:04:04:04:04:04:04: 04:04:04:04:04:04:04:04:04:04:04:04:04:04:04: 04:04:04:04:04:04:0a:58:20:01:01:01:01:01:01: 01:01:01:01:01:01:01:01:01:01:01:01:01:01:01: 01:01:01:01:01:01:01:01:01:01:01:19:01:00:58: 21:01:02:02:02:02:02:02:02:02:02:02:02:02:02: 02:02:02:02:02:02:02:02:02:02:02:02:02:02:02: 02:02:02:02:19:09:60:78:2e:68:74:74:70:73:3a: 2f:2f:76:65:72:61:69:73:6f:6e:2e:65:78:61:6d: 70:6c:65:2f:76:31:2f:63:68:61:6c:6c:65:6e:67: 65:2d:72:65:73:70:6f:6e:73:65:58:40:56:f5:0d: 13:1f:a8:39:79:ae:06:4e:76:e7:0d:c7:5c:07:0b: 6d:99:1a:ec:08:ad:f9:f4:1c:ab:7f:1b:7e:2c:47: f6:7d:ac:a8:bb:49:e3:11:9b:7b:ae:77:ae:c6:c8: 91:62:71:3e:0c:c6:d0:e7:32:78:31:e6:7f:32:84: 1a Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:45:02:21:00:93:fd:81:03:75:d1:7d:ab:53:6c:a5:19:a7: Ounsworth, et al. Expires 6 April 2024 [Page 17] Internet-Draft Remote Attestation with CSRs October 2023 68:3d:d6:e2:39:14:d6:9e:47:24:38:b5:76:db:18:a6:ca:c4: 8a:02:20:36:be:3d:71:93:5d:05:c3:ac:fa:a8:f3:e5:46:db: 57:f9:23:ee:93:47:6d:d6:d3:4f:c2:b7:cc:0d:89:71:fe Figure 4: CSR with embedded PSA Attestation Token The decoded Evidence is shown in Appendix A of [I-D.tschofenig-rats-psa-token], 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. Appendix B. ASN.1 Module CSR-ATTESTATION-2023 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix-attest-01(TBDMOD)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ALL; IMPORTS Certificate, id-pkix FROM PKIX1Explicit-2009 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51)} EXTENSION, ATTRIBUTE, AttributeSet{}, SingleAttribute{} FROM PKIX-CommonTypes-2009 -- from [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } id-aa FROM SecureMimeMessageV3dot1 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) } ; Ounsworth, et al. Expires 6 April 2024 [Page 18] Internet-Draft Remote Attestation with CSRs October 2023 -- Branch for attestation statement types id-ata OBJECT IDENTIFIER ::= { id-pkix (TBD1) } CertificateChoice ::= CHOICE { cert Certificate, opaqueCert [0] IMPLICIT OCTET STRING, typedCert [1] IMPLICIT TypedCert, typedFlatCert [2] IMPLICIT TypedFlatCert, ... } TYPED-CERT ::= TYPE-IDENTIFIER CertType ::= TYPED-CERT.&id TypedCert ::= SEQUENCE { certType TYPED-CERT.&id({TypedCertSet}), content TYPED-CERT.&Type ({TypedCertSet}{@certType}) } TypedCertSet TYPED-CERT ::= { ... -- Empty for now, } TypedFlatCert ::= SEQUENCE { certType OBJECT IDENTIFIER, certBody OCTET STRING } EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER EvidenceStatementSet EVIDENCE-STATEMENT ::= { ... -- Empty for now -- } EvidenceStatement ::= SEQUENCE { type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}), stmt EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}) } id-aa-evidenceStatement OBJECT IDENTIFIER ::= { id-aa TBDAA } -- For PKCS#10 attr-evidence ATTRIBUTE ::= { TYPE SEQUENCE OF EvidenceBundle IDENTIFIED BY id-aa-evidenceStatement Ounsworth, et al. Expires 6 April 2024 [Page 19] Internet-Draft Remote Attestation with CSRs October 2023 } -- For CRMF ext-evidence EXTENSION ::= { SYNTAX SEQUENCE OF EvidenceBundle IDENTIFIED BY id-aa-evidenceStatement } EvidenceBundle ::= SEQUENCE { evidence SEQUENCE OF EvidenceStatement, certs SEQUENCE OF CertificateChoice OPTIONAL } END B.1. 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 [TCGDICE1.1]. tcgDiceEvidenceStatementES EVIDENCE-STATEMENT ::= { ConceptualMessageWrapper IDENTIFIED BY tcg-dice-conceptual-message-wrapper } -- where ConceptualMessageWrapper and tcg-dice-conceptual-message-wrapper -- are defined in DICE-Attestation-Architecture-Version-1.1-Revision-17_1August2023.pdf EvidenceStatementSet EVIDENCE-STATEMENT ::= { tpmEvidenceStatementES, ... } Appendix C. 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. Ounsworth, et al. Expires 6 April 2024 [Page 20] Internet-Draft Remote Attestation with CSRs October 2023 We would like to specifically thank Mike StJohns for his work on an earlier version of this draft. Authors' Addresses Mike Ounsworth Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: mike.ounsworth@entrust.com Hannes Tschofenig Siemens Email: Hannes.Tschofenig@gmx.net Henk Birkholz Fraunhofer SIT Rheinstrasse 75 64295 Darmstadt Germany Email: henk.birkholz@sit.fraunhofer.de Ounsworth, et al. Expires 6 April 2024 [Page 21]