Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Mike Ounsworth , Hannes Tschofenig | ||
| Last updated | 2023-08-28 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| 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-00
Network Working Group M. Ounsworth
Internet-Draft Entrust
Intended status: Standards Track H. Tschofenig
Expires: 25 February 2024 Siemens
24 August 2023
Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-00
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 securtiy model or trusted platform module, and
the protection capabilities provided by the hardware module.
Including this evidence along with the certificate request can help
to improve the assessment of the security posture for the private
key, and suitability 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). Producing, conveying, and appraising such
believable claims is enabled via remote attestation procedures where
the device holding the private key takes on the role of an attester
and produces evidence that is made available to remote parties in a
cryptographically secured way. This document describes two new
extensions to encode evidence produced by an attester for inclusion
in PKCS#10 or CRMF certificate signing requests: an ASN.1 Attribute
or Extension definition to convey a cryptographically-signed evidence
statement to a Registration Authority or to a Certification
Authority, and an ASN.1 Attribute or Extension to carry any
certificates necessary for validating the cryptographically-signed
evidence statement.
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/.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 1]
Internet-Draft Remote Attestation with CSRs August 2023
Source for this draft and an issue tracker can be found at
https://github.com/lamps-wg/csr-attestation.
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 25 February 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
4. ASN.1 Elements . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Object Identifiers . . . . . . . . . . . . . . . . . . . 5
4.2. Evidence Attribute and Extension . . . . . . . . . . . . 6
4.3. EvidenceStatement . . . . . . . . . . . . . . . . . . . . 6
4.4. EvidenceCerts . . . . . . . . . . . . . . . . . . . . . . 7
4.5. CertificateChoice . . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5.1. Object Identifier Allocations . . . . . . . . . . . . . . 9
Ounsworth & Tschofenig Expires 25 February 2024 [Page 2]
Internet-Draft Remote Attestation with CSRs August 2023
5.1.1. Module Registration - SMI Security for PKIX Module
Identifer . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. Publishing evidence in an X.509 extension . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
A.1. TPM V2.0 Evidence in CSR . . . . . . . . . . . . . . . . 13
A.2. Platform Security Architecture Attestation Token in
CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 16
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
At the time that it is requesting a certificate from a Certification
Authority (CA), a PKI end entity may wish to provide evidence of the
security properties of the environment in which the private key is
stored. This evidence is to be verified by a relying party such as
the Registration Authority or the Certificate Authority as part of
validating an incoming certificate request against a given
certificate policy. This specification provides a newly defined
evidence attribute for carrying evidence in Certificate Requests
(CSR) in either PKCS#10 [RFC2986] or Certificate Request Message
Format (CRMF) [RFC4211].
As outlined in the RATS Architecture [RFC9334], an Attester
(typically a device) produces a signed collection of evidence about
its running environment. The term "attestation" is intentionally not
defined in RFC 9334, but it is often taken to mean the overall
process of producing and verifying evidence. A Relying Party may
consult that evidence, or an attestation result produced by a
verifier who has checked the evidence, in making policy decisions
about the trustworthiness of the target environment being attested.
Section 3 overviews 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
tries to be technology-agnostic with regards to the transport of the
produced signed claims.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 3]
Internet-Draft Remote Attestation with CSRs August 2023
This document is focused on the transport of evidence inside a CSR
and makes minimal assumptions about content or format of the
transported evidence. We also enable conveyance of a set of
certificates used for validation of evidence. These certificates
typically contain one or more certificate chains 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 creates two ATTRIBUTE/Attribute definitions. The first
Attribute may be used to carry a set of certificates or public keys
that may be necessary to validate evidence. The second Attribute
carries a structure that may be used to carry evidence.
A CSR may contain one or more evidence, for example evidence
asserting the storage properties of the private key as well evidence
asserting the firmware version and other general properties of the
device, or evidence signed by certificate chains on different
cryptographic algorithms.
With these attributes, an RA or CA has additional information about
whether to issue a certificate and what information to populate into
the certificate. The scope of this document is, however, limited to
the transport of evidence via a CSR. The exact format of the
evidence being carried 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 RFC 9334 related to remote
attestation. Readers of this document are assumed to be familiar
with the following terms: evidence, claim, attestation result,
attester, verifier, and relying party.
3. Architecture
Figure 1 shows the high-level communication pattern of the RATS
passport model where the attester transmits the evidence in the CSR
to the RA and the CA. The verifier processes the received evidence
and computes an attestation result, which is then processed by the
RA/CA prior to the certificate issuance.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 4]
Internet-Draft Remote Attestation with CSRs August 2023
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
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 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 certification request
messages.
4. ASN.1 Elements
4.1. Object Identifiers
We reference id-pkix and id-aa, both defined in [RFC5912].
We define:
Ounsworth & Tschofenig Expires 25 February 2024 [Page 5]
Internet-Draft Remote Attestation with CSRs August 2023
-- 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 statements of a type
"EvidenceStatement".
id-aa-evidenceStatement OBJECT IDENTIFIER ::= { id-aa (TBDAA2) }
-- For PKCS#10
attr-evidence ATTRIBUTE ::= {
TYPE EvidenceStatement
IDENTIFIED BY id-aa-evidenceStatement
}
-- For CRMF
ext-evidence EXTENSION ::= {
TYPE EvidenceStatement
IDENTIFIED BY id-aa-evidenceStatement
}
A CSR MAY contain one or more instance of EvidenceAttribute.
The Extension version is intended only for use within CRMF CSRs and
is NOT RECOMMENDED for use 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.
4.3. EvidenceStatement
An EvidenceStatement is a simple type-value pair identified by an OID
type and containing a value stmt.
encoded as a sequence, of which the type of the "value" field is
controlled by the value of the "type" field, similar to an Attribute
definition.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 6]
Internet-Draft Remote Attestation with CSRs August 2023
EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER
EvidenceStatementSet EVIDENCE-STATEMENT ::= {
... -- Empty for now --
}
EvidenceStatement {EVIDENCE-STATEMENT:EvidenceStatementSet} ::= SEQUENCE {
type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
stmt EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type})
}
id-aa-evidenceStatement OBJECT IDENTIFIER ::= { id-aa aa-evidenceStatement(TBDAA2) }
-- For PKCS#10
attr-evidence ATTRIBUTE ::= {
TYPE EvidenceStatement
IDENTIFIED BY id-aa-evidenceStatement
}
-- For CRMF
ext-evidence EXTENSION ::= {
TYPE EvidenceStatement
IDENTIFIED BY id-aa-evidenceStatement
}
4.4. EvidenceCerts
The "EvidenceCertsAttribute" contains a set of certificates that may
be needed to validate the contents of an evidence statement contained
in an evidenceAttribute. The set of certificates should contain the
object that contains the public key needed to directly validate the
EvidenceAttribute. The remaining elements should chain that data
back to an agreed upon trust anchor used for attestation. No order
is implied, it is the Verifier's responsibility to perform the
appropriate certification path construction.
A CSR MUST contain at zero or one EvidenceCertsAttribute. In the
case where the CSR contains multiple instances of EvidenceAttribute
representing multiple evidence statements, all necessary certificates
MUST be contained in the same instance of EvidenceCertsAttribute.
EvidenceCertsAttribute MAY be omitted if there are no certificates to
convey, for example if they are already known to the verifier, or if
they are contained in the evidence statement.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 7]
Internet-Draft Remote Attestation with CSRs August 2023
id-aa-evidenceChainCerts OBJECT IDENTIFIER ::= { id-aa (TBDAA1) }
-- For PKCS#10
attr-evidenceCerts ATTRIBUTE ::= {
TYPE SEQUENCE OF CertificateChoice
COUNTS MAX 1
IDENTIFIED BY id-aa-evidenceChainCerts
}
-- For CRMF
ext-evidenceCerts EXTENSION ::= {
TYPE SEQUENCE OF CertificateChoice
COUNTS MAX 1
IDENTIFIED BY id-aa-evidenceChainCerts
}
The Extension version is intended only for use within CRMF CSRs and
is NOT RECOMMENDED for use 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.
4.5. 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]).
Ounsworth & Tschofenig Expires 25 February 2024 [Page 8]
Internet-Draft Remote Attestation with CSRs August 2023
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.
TypedFlatCert ::= SEQUENCE {
certType OBJECT IDENTIFIER,
certBody OCTET STRING
}
5. IANA Considerations
The 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 Identifer
* 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 TBDAA2
- Description: id-aa-evidenceStatement
Ounsworth & Tschofenig Expires 25 February 2024 [Page 9]
Internet-Draft Remote Attestation with CSRs August 2023
- References: This Document
* Attest Certificate Chain
- Decimal: IANA Assigned - Replace TBDAA1
- Description: id-aa-evidenceChainCerts
- 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
* 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
The evidence communicated in the attributes and structures defined in
this document are meant to be used in a PKCS#10 or Certificate
Signing Request (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.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 10]
Internet-Draft Remote Attestation with CSRs August 2023
This document defines the transport of evidence of different formats
in a CSR. Some of these evidence formats are based on standards
while others are proprietary formats. A verifier will need to
understand these formats for matching the received values against
policies.
Policies drive the processing of evidence at the verifier: the
Verifier's Appraisal Policy for Evidence will often be specified by
the manufacturer of a hardware security module or specified by a
regulatory body such as the CA Browser Forum Code-Signing Baseline
Requirements [CSBR] which specifies certain properties, such as non-
exportability, which must be enabled for storing publicly-trusted
code-signing keys.
The relying party is ultimately responsible for making a decision of
what attestation-related information in the CSR it will accept. The
presence of the attributes defined in this specification provide the
relying party with additional assurance about 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 the 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
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
Ounsworth & Tschofenig Expires 25 February 2024 [Page 11]
Internet-Draft Remote Attestation with CSRs August 2023
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>.
[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>.
[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>.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 12]
Internet-Draft Remote Attestation with CSRs August 2023
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.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-12, 5 July 2023,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-12>.
[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>.
[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 in CSRs. The first example conveys Arm Platform Security
Architecture tokens, which provides claims about the used hardware
and software platform, into the CSR. The second example embeds the
TPM v2.0 evidence in 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.
Ounsworth & Tschofenig Expires 25 February 2024 [Page 13]
Internet-Draft Remote Attestation with CSRs August 2023
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
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
Ounsworth & Tschofenig Expires 25 February 2024 [Page 14]
Internet-Draft Remote Attestation with CSRs August 2023
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 2: CSR with TPM V2.0
A.2. Platform Security Architecture Attestation Token in CSR
The example shown in Figure 3 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.
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:
Ounsworth & Tschofenig Expires 25 February 2024 [Page 15]
Internet-Draft Remote Attestation with CSRs August 2023
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:
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 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
Ounsworth & Tschofenig Expires 25 February 2024 [Page 16]
Internet-Draft Remote Attestation with CSRs August 2023
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
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{}, id-pkix
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) }
;
-- Branch for attestation statement types
id-ata OBJECT IDENTIFIER ::= { id-pkix ata(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})
}
Ounsworth & Tschofenig Expires 25 February 2024 [Page 17]
Internet-Draft Remote Attestation with CSRs August 2023
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 {EVIDENCE-STATEMENT:EvidenceStatementSet} ::= SEQUENCE {
type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
stmt EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type})
}
id-aa-evidenceStatement OBJECT IDENTIFIER ::= { id-aa aa-evidenceStatement(TBDAA2) }
-- For PKCS#10
attr-evidence ATTRIBUTE ::= {
TYPE EvidenceStatement
IDENTIFIED BY id-aa-evidenceStatement
}
-- For CRMF
ext-evidence EXTENSION ::= {
TYPE EvidenceStatement
IDENTIFIED BY id-aa-evidenceStatement
}
id-aa-evidenceChainCerts OBJECT IDENTIFIER ::= { id-aa aa-evidenceChainCerts(TBDAA1) }
-- For PKCS#10
attr-evidenceCerts ATTRIBUTE ::= {
TYPE SEQUENCE OF CertificateChoice
COUNTS MAX 1
IDENTIFIED BY id-aa-evidenceChainCerts
}
-- For CRMF
ext-evidenceCerts EXTENSION ::= {
TYPE SEQUENCE OF CertificateChoice
COUNTS MAX 1
IDENTIFIED BY id-aa-evidenceChainCerts
Ounsworth & Tschofenig Expires 25 February 2024 [Page 18]
Internet-Draft Remote Attestation with CSRs August 2023
}
END
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.
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
Ounsworth & Tschofenig Expires 25 February 2024 [Page 19]