Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-05
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 , Henk Birkholz | ||
| Last updated | 2024-02-13 (Latest revision 2024-02-12) | ||
| Replaces | draft-ounsworth-csr-attestation, draft-stjohns-csr-attest | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
ARTART IETF Last Call review
(of
-29)
by Sean Turner
Ready w/nits
GENART IETF Last Call Review due 2026-09-16
Incomplete
SECDIR IETF Last Call Review due 2026-09-16
Incomplete
|
||
| 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-05
Network Working Group M. Ounsworth
Internet-Draft Entrust
Intended status: Standards Track H. Tschofenig
Expires: 16 August 2024 Siemens
H. Birkholz
Fraunhofer SIT
13 February 2024
Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-05
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 16 August 2024 [Page 1]
Internet-Draft Remote Attestation with CSRs February 2024
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 16 August 2024.
Copyright Notice
Copyright (c) 2024 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 . . . . . . . . . . . . . . . . . 5
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Information Model . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Interaction with an HSM . . . . . . . . . . . . . . . . . 6
4.2. Implementation Strategies . . . . . . . . . . . . . . . . 7
5. ASN.1 Elements . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Object Identifiers . . . . . . . . . . . . . . . . . . . 11
5.2. Evidence Attribute and Extension . . . . . . . . . . . . 12
5.3. CertificateAlternatives . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6.1. Module Registration - SMI Security for PKIX Module
Identifier . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Object Identifier Registrations - SMI Security for S/MIME
Attributes . . . . . . . . . . . . . . . . . . . . . . . 15
Ounsworth, et al. Expires 16 August 2024 [Page 2]
Internet-Draft Remote Attestation with CSRs February 2024
6.3. "SMI Security for PKIX Evidence Statement Formats"
Registry . . . . . . . . . . . . . . . . . . . . . . . . 15
6.4. Attestation Evidence OID Registry . . . . . . . . . . . . 16
6.4.1. Registration Template . . . . . . . . . . . . . . . . 16
6.4.2. Initial Registry Contents . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Publishing evidence in an X.509 extension . . . . . . . . 20
7.3. Type OID and verifier hint . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23
A.1. TPM V2.0 Evidence in CSR . . . . . . . . . . . . . . . . 23
A.2. Platform Security Architecture Attestation Token in
CSR . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 26
B.1. TCG DICE ConceptualMessageWrapper in CSR . . . . . . . . 28
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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. Regulatory
bodies are beginning to require proof-of-hardware residency for
certain classifications of cryptographic keys. At the time of
writing, the most notable example is the Code-Signing Baseline
Requirements [CSBR] document maintained by the CA/Browser Forum,
which requires compliant CAs to "ensure that a Subscriber’s Private
Key is generated, stored, and used in a secure environment that has
controls to prevent theft or misuse".
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 which provides an elegant and automatable
mechanism for meeting requirements such as those in the CA/B Forum's
[CSBR].
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
Ounsworth, et al. Expires 16 August 2024 [Page 3]
Internet-Draft Remote Attestation with CSRs February 2024
"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
(2) the conveyance of sets of certificates used for validation of
Evidence. The certificates typically contain one or more
certification paths rooted in a device manufacture trust anchor and
the leaf certificate being on the device in question; the latter is
the Attestation Key that signs the Evidence statement.
This document specifies a CSR Attribute (or Extension for Certificate
Request Message Format (CRMF) CSRs) for carrying Evidence. Evidence
can be placed into an EvidenceStatement along with an OID to identify
its type and optionally a hint to the Relying Party about how to
verify it. A set of EvidenceStatements may be grouped together along
with the set of CertificateAlternatives needed to validate them to
form a EvidenceBundle. One or more EvidenceBundles may be placed
into the id-aa-evidence CSR Attribute (or CRFM Extension).
A CSR may contain one or more Evidence payloads, for example Evidence
asserting the storage properties of a private key as well Evidence
asserting firmware version and other general properties of the
device, or Evidence signed using different cryptographic algorithms.
With these attributes, additional information information is
available to an RA or CA which may be used to decide whether to issue
a certificate and what certificate profile to apply. The scope of
this document is, however, limited to the conveyance of Evidence
within CSR. The exact format of the Evidence being conveyed is
defined in various standard and proprietary specifications.
Ounsworth, et al. Expires 16 August 2024 [Page 4]
Internet-Draft Remote Attestation with CSRs February 2024
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.
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
Ounsworth, et al. Expires 16 August 2024 [Page 5]
Internet-Draft Remote Attestation with CSRs February 2024
library provided by the device manufacturer. For example, security
concerns may require parsers of Evidence formats to be logically or
physically separated from the core CA functionality. The interface
by which the Relying Party passes Evidence to the Verifier and
receives back Attestation Results may be proprietary or standardized,
but in any case is out-of-scope for this document.
.-------------.
| | Compare Evidence
| Verifier | against
| | policy
'--------+----'
^ |
Evidence | | Attestation
| | Result
| v
.------------. .----|----------.
| +-------------->|----' | Compare Attestation
| Attester | Evidence | Relying | Result against
| (/w HSM) | 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
identifiers by utilizing attestation technology, which are discussed
in Section 11 of RFC 9334. Finally, the keying material used by the
Attester needs to be protected against unauthorized access, and
against signing arbitrary content that originated from outside the
device. This aspect is described in Section 12 of RFC 9334. Most of
these aspects are, however, outside the scope of this specification
but relevant for use with a given attestation technology. The focus
of this specification is on the transport of Evidence from the
Attester to the Relying Party via existing CSR messages.
4. Information Model
4.1. Interaction with an HSM
This specification is intended to be applicable both in cases where
the CSR is constructed internally or externally to the attesting
environment, from the point of view of the calling application.
Ounsworth, et al. Expires 16 August 2024 [Page 6]
Internet-Draft Remote Attestation with CSRs February 2024
Cases where the CSR is generated internally to the attesting
environment are straightforward: the HSM generates and embeds the
Evidence and the corresponding certificate chains when constructing
the CSR.
Cases where the CSR is generated externally may require extra round-
trips of communication between the CSR generator and the attesting
environment, first to obtain the necessary Evidence about the subject
key, and then to use the subject key to sign the CSR. For example,
consider a CSR generated by a popular crypto library about a subject
key stored on a PKCS#11 [PKCS11] device.
As an example, assuming that the HSM is, or contains, the attesting
environment, and some cryptographic library is assembling a CSR by
interacting with the HSM over some network protocol, then the
interaction would conceptually be:
+---------+ +-----+
| Crypto | | HSM |
| Library | | |
+---------+ +-----+
| |
| getEvidence() |
|----------------->|
| |
|<-----------------|
+---------------------+ | |
| CSR = assembleCSR() |-| |
+---------------------+ | |
| |
| sign(CSR) |
|----------------->|
| |
|<-----------------|
| |
Figure 2: Example interaction between CSR generator and HSM.
4.2. Implementation Strategies
To support a number of different use cases for the transmission of
Evidence in a CSR (together with certificate chains) the structure
shown in Figure 3 is used.
Ounsworth, et al. Expires 16 August 2024 [Page 7]
Internet-Draft Remote Attestation with CSRs February 2024
On a high-level, the structure can be explained as follows: A PKCS#10
attribute or a CRMF extension contains one or more EvidenceBundle
structures. Each EvidenceBundle contains one or more
EvidenceStatement structures as well as one or more
CertificateAlternatives which enable to carry various format of
certificates.
+--------------------+
| PKCS#10 or CRMF |
| Attribute or |
| Extension |
+--------+-----------+
|
| (1 or more) +-------------------------+
| +-------------+ CertificateAlternatives |
| | +-------------------------+
| | | Certificate OR |
| | | TypedCert OR |
| | | TypedFlatCert |
(1 or | | +-------------------------+
more) | | (1 or
+--------+---------+-+ more) +-------------------+
| EvidenceBundle +-----------+ EvidenceStatement |
+--------------------+ +-------------------+
| Type |
| Statement |
+-------------------+
Figure 3: Information Model for CSR Evidence Conveyance.
The following use cases are supported:
Single Attester, which only distributes Evidence without any
certificate chains, i.e. the Verifier is assumed to be in possession
of the certificate chain already or there is no certificate chain
because the Verifier directly trusts the Attester key. As a result a
single EvidenceBundle is included in a CSR that contains a single
EvidenceStatement without the CertificateAlternatives structure.
Figure 4 shows this use case.
+--------------------+
| EvidenceBundle |
+--------------------+
| EvidenceStatement |
+--------------------+
Figure 4: Use Case 1: Single Attester without Certificate Chain.
Ounsworth, et al. Expires 16 August 2024 [Page 8]
Internet-Draft Remote Attestation with CSRs February 2024
A single Attester, which shares Evidence together with a certificate
chain. The CSR conveys a single EvidenceBundle with a single
EvidenceStatement and a single CertificateAlternatives structure.
Figure 5 shows this use case.
+-------------------------+
| EvidenceBundle |
+-------------------------+
| EvidenceStatement |
| CertificateAlternatives |
+-------------------------+
Figure 5: Use Case 2: Single Attester with Certificate Chain.
In a Composite Device, which contains multiple Attesters, a
collection of Evidence statements is obtained. Imagine that each
Attester returns its Evidence together with a certificate chain. As
a result, multiple EvidenceBundle structures, each carrying an
EvidenceStatement and the corresponding CertificateAlternative
structure with the certificate chain as provided by each Attester,
are included in the CSR. This may result in certificates being
duplicated across multiple EvidenceBundles. This approach does not
require any processing capabilities by a lead Attester since the
information is merely forwarded. Figure 6 shows this use case.
+-------------------------+
| EvidenceBundle (1) |\
+-------------------------+ \ Provided by
| EvidenceStatement | / Attester 1
| CertificateAlternatives |/
+-------------------------+
| EvidenceBundle (2) |\
+-------------------------+ \ Provided by
| EvidenceStatement | / Attester 2
| CertificateAlternatives |/
+-------------------------+
Figure 6: Use Case 3: Multiple Attesters in Composite Device.
In the last scenario, we also assume a Composite Device with
additional processing capabilities of the Leader Attester, which
parses the certificate chains provided by all Attesters in the device
and removes redundant certificate information. The benefit of this
approach is the reduced transmission overhead. There are several
implementation strategies and we show two in Figure 7.
Ounsworth, et al. Expires 16 August 2024 [Page 9]
Internet-Draft Remote Attestation with CSRs February 2024
Implementation strategy (4a)
+-------------------------+
| EvidenceBundle (1) |\
Certificate +-------------------------+ \ Provided by
Chain + | EvidenceStatement | / Attester 1
End-Entity -->| CertificateAlternatives |/
Certificate +-------------------------+
....
+-------------------------+
| EvidenceBundle (n) |\
+-------------------------+ \ Provided by
End-Entity | EvidenceStatement | / Attester n
Certificate-->| CertificateAlternatives |/
+-------------------------+
Implementation strategy (4b)
+------------------------------+
| EvidenceBundle |
+------------------------------+
| EvidenceStatement (1) |
| ... |
| EvidenceStatement (n) |
| CertificateAlternatives { |
| End Entity Certificate (1) |
| ... |
| End Entity Certificate (n) |
| <Remainder of the |
| Certificate Chain> |
| } |
+------------------------------+
Figure 7: Use Case 4: Multiple Attesters in Composite Device (with
Optimization).
Ounsworth, et al. Expires 16 August 2024 [Page 10]
Internet-Draft Remote Attestation with CSRs February 2024
In implementation strategy (4a) we assume that each Attester is
provisioned with a unique end-entity certificate. Hence, the
certificate chains will at least differ with respect to the end-
entity certificates. The Lead Attester will therefore create
multiple EvidenceBundle structures, each will carry an
EvidenceStatement followed by a certificate chain in the
CertificateAlternative structures containing most likely only the
end-entity certificate. The shared certificate chain is carried in
the first entry of the EvidenceBundle sequence to allow path
validation to take place immediately after processing the first
structure. This implementation strategy may place extra burden on
the Relying Party to parse EvidenceBundles and reconstruct
certificate chains if the Verifier requires each EvidenceStatement to
be accompanied with a complete certificate chain.
Implementation strategy (4b), as an alternative, requires the Lead
Attester to merge all certificate chains into a single EvidenceBundle
containing a single de-duplicated sequence of CertificateAlternatives
structures. This means that each EvidenceBundle is self-contained
and any EvidenceStatement can be verified using only the sequence of
CertificateAlternatives in its bundle, but Verifiers will have to do
proper certification path building since the sequence of
CertificateAlternatives is now a cert bag and not a cert chain. This
implementation strategy may place extra burden on the Attester in
order to allow the Relying Party to treat the Evidence and
Certificates as opaque content. It also may place extra burden on
the Verifier since this implementation strategy requires it to be
able to perform X.509 path building over a bag of certificates that
may be out of order or contain extraneous certificates.
Note: This specification does not mandate optimizing certificate
chains since there is a trade-off between the Attester implementation
complexity and the transmission overhead.
5. ASN.1 Elements
5.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) }
Ounsworth, et al. Expires 16 August 2024 [Page 11]
Internet-Draft Remote Attestation with CSRs February 2024
5.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.
EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER
EvidenceStatementSet EVIDENCE-STATEMENT ::= {
... -- None defined in this document --
}
This is a mapping and ASN.1 Types for Evidence Statements to the OIDs
that identify them. These mappings are are used to construct or
parse EvidenceStatements. These would typically be Evidence
Statement formats defined in other IETF standards, defined by other
standards bodies, or vendor proprietary formats along with the OIDs
that identify them.
This list is left empty in this document. However, implementers
should populate it with the formats that they wish to support.
EvidenceHint ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
uri [2] IA5String,
text [3] UTF8String
}
EvidenceStatements ::= SEQUENCE SIZE (1..MAX) OF EvidenceStatement
EvidenceStatement ::= SEQUENCE {
type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
stmt EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}),
hint EvidenceHint OPTIONAL
}
The type is on OID indicating the format of the data contained in
stmt.
The hint is intended for an Attester to indicate to the Relying Party
(RP) which Verifier should be invoked to parse this statement. In
many cases, the type OID will already uniquely indicate which
Verifier to invoke; for example because the OID indicates a
Ounsworth, et al. Expires 16 August 2024 [Page 12]
Internet-Draft Remote Attestation with CSRs February 2024
proprietary Evidence format for which the RP has corresponding
proprietary Verifier. However, in some cases it may still be
ambiguous, or the type may indicate another layer of conceptual
message wrapping in which case it is helpful to the RP to bring this
hint outside of the statement. It is assumed that the RP must be
pre-configured with a list of trusted Verifiers and that the contents
of this hint can be used to look up the correct Verifier. Under no
circumstances must the RP be tricked into contacting an unknown and
untrusted Verifier since the returned Attestation Result must not be
relied on. The format and contents of the hint are out of scope of
this document.
EvidenceBundles ::= SEQUENCE SIZE (1..MAX) OF EvidenceBundle
EvidenceBundle ::= SEQUENCE
{
evidence EvidenceStatements,
certs SEQUENCE SIZE (1..MAX) OF CertificateAlternatives OPTIONAL
}
id-aa-evidence OBJECT IDENTIFIER ::= { id-aa TBDAA }
-- For PKCS#10
attr-evidence ATTRIBUTE ::= {
TYPE EvidenceBundles
IDENTIFIED BY id-aa-evidence
}
-- For CRMF
ext-evidence EXTENSION ::= {
SYNTAX EvidenceBundles
IDENTIFIED BY id-aa-evidence
}
The Extension variant is intended only for use within CRMF CSRs and
MUST NOT be used within X.509 certificates due to the privacy
implications of publishing Evidence about the end entity's hardware
environment. See Section 7 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.
Ounsworth, et al. Expires 16 August 2024 [Page 13]
Internet-Draft Remote Attestation with CSRs February 2024
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.
5.3. CertificateAlternatives
This is an ASN.1 CHOICE construct used to represent an encoding of a
broad variety of certificate types.
CertificateAlternatives ::=
CHOICE {
cert [0] Certificate,
typedCert [1] TypedCert,
typedFlatCert [2] 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 characteristics of a
certificate, but is not encoded as an X.509 certificate. The
certType Field (below) indicates how to interpret the certBody field.
While it is possible to carry any type of data in this structure,
it's intended the content field include data for at least one public
key formatted as a SubjectPublicKeyInfo (see [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 ::= {
... -- None defined in this document --
}
"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 16 August 2024 [Page 14]
Internet-Draft Remote Attestation with CSRs February 2024
TypedFlatCert ::= SEQUENCE {
certType OBJECT IDENTIFIER,
certBody OCTET STRING
}
6. IANA Considerations
IANA is requested to open two new registries, allocate a value from
the "SMI Security for PKIX Module Identifier" registry for the
included ASN.1 module, and allocate values from "SMI Security for S/
MIME Attributes" to identify two Attributes defined within.
6.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
6.2. Object Identifier Registrations - SMI Security for S/MIME
Attributes
* Evidence Statement
- Decimal: IANA Assigned - Replace *TBDAA*
- Description: id-aa-evidence
- References: This Document
6.3. "SMI Security for PKIX Evidence Statement Formats" Registry
IANA is asked to create a registry for Evidence Statement Formats
within the SMI-numbers registry, allocating an assignment from id-
pkix ("SMI Security for PKIX" Registry) for the purpose.
* Decimal: IANA Assigned - *replace TBD1*
* Description: id-ata
* References: This document
* Initial contents: None
* Registration Regime: Specification Required. Document must
specify an EVIDENCE-STATEMENT definition to which this Object
Identifier shall be bound.
Ounsworth, et al. Expires 16 August 2024 [Page 15]
Internet-Draft Remote Attestation with CSRs February 2024
Columns:
* Decimal: The subcomponent under id-ata
* Description: Begins with id-ata
* References: RFC or other document
6.4. Attestation Evidence OID Registry
IANA is asked to create a registry that helps developers to find OID/
Evidence mappings.
Registration requests are evaluated using the criteria described in
the registration template below after a three-week review period on
the [[TBD]] mailing list, with the advice of one or more Designated
Experts [RFC8126]. However, to allow for the allocation of values
prior to publication, the Designated Experts may approve registration
once they are satisfied that such a specification will be published.
Registration requests sent to the mailing list for review should use
an appropriate subject (e.g., "Request to register attestation
evidence: example").
IANA must only accept registry updates from the Designated Experts
and should direct all requests for registration to the review mailing
list.
6.4.1. Registration Template
The registry has the following columns:
* OID: The OID number, which has already been allocated. IANA does
not allocate OID numbers for use with this registry.
* Description: Brief description of the use of the Evidence and the
registration of the OID.
* Reference(s): Reference to the document or documents that register
the OID for use with a specific attestation technology, preferably
including URIs that can be used to retrieve copies of the
documents. An indication of the relevant sections may also be
included but is not required.
* Change Controller: For Standards Track RFCs, list the "IESG". For
others, give the name of the responsible party. In most cases the
third party requesting registration in this registry will also be
the party that registered the OID.
Ounsworth, et al. Expires 16 August 2024 [Page 16]
Internet-Draft Remote Attestation with CSRs February 2024
6.4.2. Initial Registry Contents
The initial registry contents is shown in the table below. It lists
two entries, one for DICE-based Evidence and the second for the
Conceptual Message Wrapper (CMW) [I-D.ietf-rats-msg-wrap].
| OID | Description | Reference(s) | Change Controller |
|------------------|----------------------------|----------------|-------------------|
| 2 23 133 5 4 10 | DICE Evidence | {{TCGDICE1.1}} | TCG |
| 2 23 133 5 4 9 | Conceptual Message Wrapper | {{TCGDICE1.1}} | TCG |
Figure 8: Initial Contents of the Attestation Evidence OID Registry
The current registry values can be retrieved from the IANA online
website.
7. Security Considerations
A PKCS#10 or CRMF Certification Request message typically consists of
a distinguished name, a public key, and optionally a set of
attributes, collectively signed by the entity requesting
certification. In general usage, the private key used to sign the
CSR MUST be different from the Attesting Key utilized to sign
Evidence about the Target Environment, though exceptions MAY be made
where CSRs and Evidence are involved in bootstrapping the Attesting
Key. To demonstrate that the private key applied to sign the CSR is
generated, and stored in a secure environment that has controls to
prevent theft or misuse (including being non-exportable / non-
recoverable), the Attesting Environment has to collect claims about
this secure environment (or Target Environment, as shown in
Figure 9).
Figure 9 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 16 August 2024 [Page 17]
Internet-Draft Remote Attestation with CSRs February 2024
^
|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 9: Interaction between Attesting and Target Environment
Figure 9 places the CSR library outside the Attester, which is a
valid architecture for certificate enrollment. The CSR library may
also be located inside the trusted computing base. Regardless of the
placement of the CSR library, an Attesting Environment MUST be able
to collect claims about the Target Environment such that statements
about the storage of the keying material can be made. For the
Verifier, the provided Evidence must allow an assessment to be made
whether the key used to sign the CSR is stored in a secure location
and cannot be exported.
Ounsworth, et al. Expires 16 August 2024 [Page 18]
Internet-Draft Remote Attestation with CSRs February 2024
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.
7.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 that nonce to be provided by the Relying Party in
some protocol step prior to Evidence and CSR generation, and the use
of timestamps requires synchronized clocks which cannot be guaranteed
in all operating environments. Epochs also require (unidirectional)
communication prior to Evidence and CSR generation. This document
only specifies how to carry existing Evidence formats inside a CSR,
and so issues of synchronizing freshness data is left to be handled,
for example, via certificate management protocols. Developers,
operators, and designers of protocols, which embed Evidence-carrying-
CSRs, MUST consider what notion of freshness is appropriate and
available in-context; thus the issue of freshness is left up to the
discretion of protocol designers and implementers.
Ounsworth, et al. Expires 16 August 2024 [Page 19]
Internet-Draft Remote Attestation with CSRs February 2024
In the case of Hardware Security Modules (HSM), the definition of
"fresh" is somewhat ambiguous in the context of CSRs, especially
considering that non-automated certificate enrollments are often
asynchronous, and considering the common practice of re-using the
same CSR for multiple certificate renewals across the lifetime of a
key. "Freshness" typically implies both asserting that the data was
generated at a certain point-in-time, as well as providing non-
replayability. Certain use cases may have special properties
impacting the freshness requirements. For example, HSMs are
typically designed to not allow downgrade of private key storage
properties; for example if a given key was asserted at time T to have
been generated inside the hardware boundary and to be non-exportable,
then it can be assumed that those properties of that key will
continue to hold into the future.
7.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.3. Type OID and verifier hint
The EvidenceStatement includes both a type OID and a free form hint
field with which the Attester can provide information to the Relying
Party about which Verifier to invoke to parse a given piece of
Evidence. Care should be taken when processing these data since at
the time they are used, they are not yet verified. In fact, they are
protected by the CSR signature but not by the signature from the
Attester and so could be maliciously replaced in some cases. The
authors' intent is that the type OID and hint will allow an RP to
select between Verifier with which it has pre-established trust
relationships, such as Verifier libraries that have been compiled in
to the RP application. As an example, the hint may take the form of
an FQDN to uniquely identify a Verifier implementation, but the RP
MUST NOT blindly make network calls to unknown domain names and trust
the results. Implementers should also be cautious around type OID or
hint values that cause a short-circuit in the verification logic,
Ounsworth, et al. Expires 16 August 2024 [Page 20]
Internet-Draft Remote Attestation with CSRs February 2024
such as None, Null, Debug, empty CMW contents, or similar values that
could cause the Evidence to appear to be valid when in fact it was
not properly checked.
8. References
8.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>.
[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>.
8.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>.
Ounsworth, et al. Expires 16 August 2024 [Page 21]
Internet-Draft Remote Attestation with CSRs February 2024
[I-D.ietf-rats-msg-wrap]
Birkholz, H., Smith, N., Fossati, T., and H. Tschofenig,
"RATS Conceptual Messages Wrapper (CMW)", Work in
Progress, Internet-Draft, draft-ietf-rats-msg-wrap-03, 29
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-03>.
[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-20, 18 December 2023,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-20>.
[PKCS11] OASIS, "PKCS #11 Cryptographic Token Interface Base
Specification Version 2.40", April 2015,
<http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/
pkcs11-base-v2.40-os.html>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[TCGDICE1.1]
Trusted Computing Group, "DICE Attestation Architecture",
January 2024, <https://trustedcomputinggroup.org/wp-
content/uploads/DICE-Attestation-Architecture-Version-1.1-
Revision-18_pub.pdf>.
Ounsworth, et al. Expires 16 August 2024 [Page 22]
Internet-Draft Remote Attestation with CSRs February 2024
[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.
At the time of writing, the authors are not aware of registered OIDs
for these evidence formats, and so we leave the OIDs as TBD1 / TBD2.
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
digitally signed with an attestation key known to the hardware.
Note: The information conveyed in the value field of the
EvidenceStatement structure may contain more information than the
signed TPM Quote structure defined in the TPM v2.0 specification
[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
Ounsworth, et al. Expires 16 August 2024 [Page 23]
Internet-Draft Remote Attestation with CSRs February 2024
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
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 10: CSR with TPM V2.0
A.2. Platform Security Architecture Attestation Token in CSR
The example shown in Figure 11 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 16 August 2024 [Page 24]
Internet-Draft Remote Attestation with CSRs February 2024
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 16 August 2024 [Page 25]
Internet-Draft Remote Attestation with CSRs February 2024
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 11: 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 16 August 2024 [Page 26]
Internet-Draft Remote Attestation with CSRs February 2024
-- Branch for attestation statement types
id-ata OBJECT IDENTIFIER ::= { id-pkix (TBD1) }
CertificateAlternatives ::=
CHOICE {
cert [0] Certificate,
typedCert [1] TypedCert,
typedFlatCert [2] TypedFlatCert,
...
}
TYPED-CERT ::= TYPE-IDENTIFIER
TypedCert ::= SEQUENCE {
certType TYPED-CERT.&id({TypedCertSet}),
content TYPED-CERT.&Type ({TypedCertSet}{@certType})
}
TypedCertSet TYPED-CERT ::= {
... -- None defined in this document --
}
TypedFlatCert ::= SEQUENCE {
certType OBJECT IDENTIFIER,
certBody OCTET STRING
}
EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER
EvidenceStatementSet EVIDENCE-STATEMENT ::= {
... -- None defined in this document --
}
EvidenceHint ::= CHOICE {
rfc822Name [0] IA5String,
dNSName [1] IA5String,
uri [2] IA5String,
text [3] UTF8String
}
EvidenceStatements ::= SEQUENCE SIZE (1..MAX) OF EvidenceStatement
EvidenceStatement ::= SEQUENCE {
type EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
stmt EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}),
hint EvidenceHint OPTIONAL
}
Ounsworth, et al. Expires 16 August 2024 [Page 27]
Internet-Draft Remote Attestation with CSRs February 2024
id-aa-evidence OBJECT IDENTIFIER ::= { id-aa TBDAA }
-- For PKCS#10
attr-evidence ATTRIBUTE ::= {
TYPE EvidenceBundles
IDENTIFIED BY id-aa-evidence
}
-- For CRMF
ext-evidence EXTENSION ::= {
SYNTAX EvidenceBundles
IDENTIFIED BY id-aa-evidence
}
EvidenceBundles ::= SEQUENCE SIZE (1..MAX) OF EvidenceBundle
EvidenceBundle ::= SEQUENCE
{
evidence EvidenceStatements,
certs SEQUENCE SIZE (1..MAX) 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, ...
}
Ounsworth, et al. Expires 16 August 2024 [Page 28]
Internet-Draft Remote Attestation with CSRs February 2024
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, Monty
Wiseman, Ned Smith.
We would like to specifically thank Mike StJohns for his work on an
earlier version of this draft.
Finally, we would like to thank Andreas Kretschmer for his feedback
based on his implementation experience, and Daniel Migault and Russ
Housley for their review comments.
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 16 August 2024 [Page 29]