Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-02
| Document | Type | Active Internet-Draft (lamps WG) | |
|---|---|---|---|
| Authors | Mike Ounsworth , Hannes Tschofenig , Henk Birkholz | ||
| Last updated | 2023-10-12 (Latest revision 2023-10-09) | ||
| Replaces | draft-ounsworth-csr-attestation, draft-stjohns-csr-attest | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-lamps-csr-attestation-02
Network Working Group M. Ounsworth
Internet-Draft Entrust
Intended status: Standards Track H. Tschofenig
Expires: 11 April 2024 Siemens
H. Birkholz
Fraunhofer SIT
9 October 2023
Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-02
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 11 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 11 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. CertificateAlternatives . . . . . . . . . . . . . . . . . 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 11 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 11 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 11 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 11 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 11 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})
}
EvidenceBundle ::= SEQUENCE
{
evidence SEQUENCE OF EvidenceStatement,
certs SEQUENCE OF CertificateAlternatives OPTIONAL
}
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-
Ounsworth, et al. Expires 11 April 2024 [Page 7]
Internet-Draft Remote Attestation with CSRs October 2023
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.
4.3. CertificateAlternatives
This is an ASN.1 CHOICE construct used to represent an encoding of a
broad variety of certificate types.
CertificateAlternatives ::=
CHOICE {
cert Certificate,
typedCert [0] IMPLICIT TypedCert,
typedFlatCert [1] 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.
"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 11 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 11 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 11 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 11 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 11 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/rfc/rfc4211>.
Ounsworth, et al. Expires 11 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,
<https://www.rfc-editor.org/rfc/rfc5912>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
7.2. Informative References
[CSBR] CA/Browser Forum, "Baseline Requirements for Code-Signing
Certificates, v.3.3", June 2023, <https://cabforum.org/wp-
content/uploads/Baseline-Requirements-for-the-Issuance-
and-Management-of-Code-Signing.v3.3.pdf>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
tpm-based-network-device-attest-14>.
[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,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-13>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<https://www.rfc-editor.org/rfc/rfc7030>.
[TCGDICE1.1]
Trusted Computing Group, "DICE Attestation Architecture,
v.1.1", May 2023, <https://trustedcomputinggroup.org/wp-
content/uploads/DICE-Attestation-Architecture-Version-1.1-
Revision-17_1August2023.pdf>.
Ounsworth, et al. Expires 11 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,
<https://trustedcomputinggroup.org/resource/tpm-library-
specification/>.
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 11 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 11 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 11 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 11 April 2024 [Page 18]
Internet-Draft Remote Attestation with CSRs October 2023
-- Branch for attestation statement types
id-ata OBJECT IDENTIFIER ::= { id-pkix (TBD1) }
CertificateAlternatives ::=
CHOICE {
cert Certificate,
typedCert [0] IMPLICIT TypedCert,
typedFlatCert [1] 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 11 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 CertificateAlternatives 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 ::= {
tcgDiceEvidenceStatementES, ...
}
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.
We would like to specifically thank Mike StJohns for his work on an
earlier version of this draft.
Ounsworth, et al. Expires 11 April 2024 [Page 20]
Internet-Draft Remote Attestation with CSRs October 2023
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 11 April 2024 [Page 21]