Skip to main content

Use of Remote Attestation with Certificate Signing Requests
draft-ietf-lamps-csr-attestation-08

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-04-30 (Latest revision 2024-03-01)
Replaces draft-ounsworth-csr-attestation, draft-stjohns-csr-attest
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-08
Network Working Group                                       M. Ounsworth
Internet-Draft                                                   Entrust
Intended status: Standards Track                           H. Tschofenig
Expires: 2 September 2024                                        Siemens
                                                             H. Birkholz
                                                          Fraunhofer SIT
                                                            1 March 2024

      Use of Remote Attestation with Certificate Signing Requests
                  draft-ietf-lamps-csr-attestation-08

Abstract

   A PKI end entity 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 defines a new PKCS#10 attribute attr-evidence and CRMF
   extension ext-evidence that allows placing any Evidence data, in any
   pre-existing format, along with any certificates needed to validate
   it, into a PKCS#10 or CRMF CSR.

   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 2 September 2024                [Page 1]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 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 . . . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Interaction with an HSM . . . . . . . . . . . . . . . . .   7
     4.2.  Implementation Strategies . . . . . . . . . . . . . . . .   8
   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 2 September 2024                [Page 2]
Internet-Draft        Remote Attestation with CSRs            March 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.  Extending EvidenceStatementSet  . . . . . . . . . . . . .  23
     A.2.  TPM V2.0 Evidence in CSR  . . . . . . . . . . . . . . . .  24
       A.2.1.  TCG Key Attestation Certify . . . . . . . . . . . . .  24
       A.2.2.  TCG OIDs  . . . . . . . . . . . . . . . . . . . . . .  24
       A.2.3.  TPM2 AttestationStatement . . . . . . . . . . . . . .  24
       A.2.4.  Introduction to TPM2 concepts . . . . . . . . . . . .  25
       A.2.5.  TCG Objects and Key Attestation . . . . . . . . . . .  25
       A.2.6.  Example Structures  . . . . . . . . . . . . . . . . .  29
     A.3.  PSA Attestation Token in CSR  . . . . . . . . . . . . . .  29
   Appendix B.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  30
     B.1.  TCG DICE ConceptualMessageWrapper in CSR  . . . . . . . .  33
   Appendix C.  Acknowledgments  . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

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".

Ounsworth, et al.       Expires 2 September 2024                [Page 3]
Internet-Draft        Remote Attestation with CSRs            March 2024

   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
   "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.

Ounsworth, et al.       Expires 2 September 2024                [Page 4]
Internet-Draft        Remote Attestation with CSRs            March 2024

   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.

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.

Ounsworth, et al.       Expires 2 September 2024                [Page 5]
Internet-Draft        Remote Attestation with CSRs            March 2024

   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.  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

Ounsworth, et al.       Expires 2 September 2024                [Page 6]
Internet-Draft        Remote Attestation with CSRs            March 2024

   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.

   Cases where the CSR is generated internally to the attesting
   environment are straightforward: the HSM generates and embeds the
   Evidence and the corresponding certification paths 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)        |
                           |----------------->|
                           |                  |
                           |<-----------------|
                           |                  |

Ounsworth, et al.       Expires 2 September 2024                [Page 7]
Internet-Draft        Remote Attestation with CSRs            March 2024

        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 certification paths) the structure
   shown in Figure 3 is used.

   On a high-level, the structure can be explained as follows: A PKCS#10
   attribute or a CRMF extension contains one or more EvidenceBundle
   structures.  Each EvidenceBundle contains one or more
   EvidenceStatement structures as well as one or more
   CertificateAlternatives which enable to carry various format of
   certificates.

    +--------------------+
    |  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
   certification paths, i.e. the Verifier is assumed to be in possession
   of the certification paths already or there is no certification paths
   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.

Ounsworth, et al.       Expires 2 September 2024                [Page 8]
Internet-Draft        Remote Attestation with CSRs            March 2024

     +--------------------+
     |  EvidenceBundle    |
     +--------------------+
     | EvidenceStatement  |
     +--------------------+

     Figure 4: Use Case 1: Single Attester without Certification Path.

   A single Attester, which shares Evidence together with a
   certification path.  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 Certification Path.

   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 certification path.  As
   a result, multiple EvidenceBundle structures, each carrying an
   EvidenceStatement and the corresponding CertificateAlternative
   structure with the certification path 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.

Ounsworth, et al.       Expires 2 September 2024                [Page 9]
Internet-Draft        Remote Attestation with CSRs            March 2024

   In the last scenario, we also assume a Composite Device with
   additional processing capabilities of the Leader Attester, which
   parses the certification path 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.

   Implementation strategy (4a)

                    +-------------------------+
                    |  EvidenceBundle (1)     |\
     Certification  +-------------------------+ \ Provided by
     Path +         | 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          |
    |    Certification Path>       |
    | }                            |
    +------------------------------+

     Figure 7: Use Case 4: Multiple Attesters in Composite Device (with
                               Optimization).

   In implementation strategy (4a) we assume that each Attester is
   provisioned with a unique end-entity certificate.  Hence, the
   certification path will at least differ with respect to the end-
   entity certificates.  The Lead Attester will therefore create
   multiple EvidenceBundle structures, each will carry an

Ounsworth, et al.       Expires 2 September 2024               [Page 10]
Internet-Draft        Remote Attestation with CSRs            March 2024

   EvidenceStatement followed by a certification path in the
   CertificateAlternative structures containing most likely only the
   end-entity certificate.  The shared certification path 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
   certification path if the Verifier requires each EvidenceStatement to
   be accompanied with a complete certification path.

   Implementation strategy (4b), as an alternative, requires the Lead
   Attester to merge all certification paths 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 certification path.  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 certification
   path 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 2 September 2024               [Page 11]
Internet-Draft        Remote Attestation with CSRs            March 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 certification path.
   This structure allows for grouping Evidence statements that share a
   certification path.

   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 2 September 2024               [Page 12]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 13]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 14]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 15]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 16]
Internet-Draft        Remote Attestation with CSRs            March 2024

6.4.2.  Initial Registry Contents

   The initial registry contents is shown in the table below.  It lists
   one entry for the Conceptual Message Wrapper (CMW)
   [I-D.ietf-rats-msg-wrap].

     +==========+=================+==============+===================+
     | OID      | Description     | Reference(s) | Change Controller |
     +==========+=================+==============+===================+
     | 2 23 133 | Conceptual      | [TCGDICE1.1] | TCG               |
     | 5 4 9    | Message Wrapper |              |                   |
     +----------+-----------------+--------------+-------------------+

         Table 1: Initial Contents of the Attestation Evidence OID
                                  Registry

   EDNOTE: This is currently under debate with our contacts at TCG about
   which OID they want used for the initial 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 8).

   Figure 8 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 2 September 2024               [Page 17]
Internet-Draft        Remote Attestation with CSRs            March 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 8: Interaction between Attesting and Target Environment

   Figure 8 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 2 September 2024               [Page 18]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 19]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 20]
Internet-Draft        Remote Attestation with CSRs            March 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 2 September 2024               [Page 21]
Internet-Draft        Remote Attestation with CSRs            March 2024

   [I-D.bft-rats-kat]
              Brossard, M., Fossati, T., and H. Tschofenig, "An EAT-
              based Key Attestation Token", Work in Progress, Internet-
              Draft, draft-bft-rats-kat-02, 10 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-bft-rats-kat-
              02>.

   [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-04, 27
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-ietf-rats-msg-wrap-04>.

   [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-22, 21 February 2024,
              <https://datatracker.ietf.org/doc/html/draft-tschofenig-
              rats-psa-token-22>.

   [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>.

Ounsworth, et al.       Expires 2 September 2024               [Page 22]
Internet-Draft        Remote Attestation with CSRs            March 2024

   [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>.

   [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.  Extending EvidenceStatementSet

   As defined in Section 5.2, EvidenceStatementSet acts as a way to
   provide an ASN.1 compiler or runtime parser with a list of OBJECT
   IDENTIFIERs that are known to represent EvidenceStatements -- and are
   expected to appear in an EvidenceStatement.type field, along with the
   ASN.1 type that should be used to parse the data in the associated
   EvidenceStatement.stmt field.  Essentially this is a mapping of OIDs
   to data structures.  Implementers are expected to populate it with
   mappings for the Evidence types that their application will be
   handling.

   This specification aims to be agnostic about the type of data being
   carried, and therefore does not specify any mandatory-to-implement
   Evidence types.

   As an example of how to populate EvidenceStatementSet, implementing
   the TPM 2.0 and PSA Evidence types given below would result in the
   following EvidenceStatementSet definition:

Ounsworth, et al.       Expires 2 September 2024               [Page 23]
Internet-Draft        Remote Attestation with CSRs            March 2024

   EvidenceStatementSet EVIDENCE-STATEMENT ::= {
     --- TPM 2.0
     { Tcg-attest-certify IDENTIFIED BY tcg-attest-certify },
     ...,

     --- PSA
     { OCTET STRING IDENTIFIED BY { 1 3 6 1 5 5 7 1 99 } }
   }

A.2.  TPM V2.0 Evidence in CSR

   This section describes TPM2 key attestation for use in a CSR.

A.2.1.  TCG Key Attestation Certify

   There are several ways in TPM2 to provide proof of a key's
   properties. (i.e., key attestation).  This description uses the
   simplest and most generally expected to used which is the
   TPM2_Certify and the TPM2_ReadPublic commands.

A.2.2.  TCG OIDs

   The OIDs in this section are defined by TCG TCG has a registered arc
   of 2.23.133

   id-tcg OBJECT IDENTIFIER ::= { 2 23 133 }

   id-tcg-kp-AIKCertificate OBJECT IDENTIFIER ::= { id-tcg 8 3 }

   id-tcg-attest OBJECT IDENTIFIER ::= { id-tcg TBD }

   id-tcg-attest-certify OBJECT IDENTIFIER ::= { id-tcg-attest 1 }

A.2.3.  TPM2 AttestationStatement

   The EvidenceStatement structure contains a sequence of two fields: a
   type and a stmt.  The 'type' field contains the OID of the Evidence
   format and it is set to tcg-attest-certify.  The content of the
   structure shown below is placed into the stmt, which is a
   concatenation of existing TPM2 structures.  These structures will be
   explained in the rest of this section.

   Tcg-attest-certify ::= SEQUENCE {
     tcg-attest-certify-tpm2b_attest       TPM2B_ATTEST,
     tcg-attest-certify-tpmt_signature     TPMT_SIGNATURE,
     tcg-attest-certify-tpm2b_public   [0] TPM2B_PUBLIC OPTIONAL,
     tcg-kp-AIKCertificate             [1] OCTET STRING OPTIONAL
   }

Ounsworth, et al.       Expires 2 September 2024               [Page 24]
Internet-Draft        Remote Attestation with CSRs            March 2024

   The tcg-kp-AIKCertificate field contains the AIK Certificate in RFC
   5280 format.

A.2.4.  Introduction to TPM2 concepts

   The definitions in the following sections are defined by the TPM2 and
   various TCG defined specification including the TPM2 set of
   specifications.  Those familiar with TPM2 concepts may skip to
   Appendix A.2.3 which defines an ASN.1 structure specific for bundling
   a TPM attestation into an EvidenceStatement, and Appendix A.2.6 which
   provides the example.  For those unfamiliar with TPM2 concepts this
   section provides only the minimum information to understand TPM2
   Attestation in CSR and is not a complete description of the
   technology in general.

A.2.5.  TCG Objects and Key Attestation

   This provides a brief explanation of the relevant TPM2 commands and
   data structures needed to understand TPM2 Attestation used in this
   RFC.  NOTE: The TPM2 specification used in this explanation is
   version 1.59, section number cited are based on that version.  Note
   also that the TPM2 specification comprises four documents: Part 1:
   Architecture; Part 2: Structures; Part 3: Commands; Part 4:
   Supporting Routines.

   Note about convention: All structures starting with TPM2B_ are:

   *  a structure that is a sized buffer where the size of the buffer is
      contained in a 16-bit, unsigned value.

   *  The first parameter is the size in octets of the second parameter.
      The second parameter may be any type.

   A full explanation of the TPM structures is outside the scope of this
   document.  As a simplification references to TPM2B_ structures will
   simply use the enclosed TPMT_ structure by the same name following
   the '_'.

A.2.5.1.  TPM2 Object Names

   All TPM2 Objects (e.g., keys are key objects which is the focus of
   this specification).  A TPM2 object name is persistent across the
   object's life cycle whether the TPM2 object is transient or
   persistent.

   A TPM2 Object name is a concatenation of a hash algorithm identifier
   and a hash of the TPM2 Object's TPMT_PUBLIC.

Ounsworth, et al.       Expires 2 September 2024               [Page 25]
Internet-Draft        Remote Attestation with CSRs            March 2024

        Name ≔ nameAlg || HnameAlg (handle→publicArea)
        nameAlg is a TCG defined 16 bit algorithm identifier

   publicArea is the TPMT_PUBLIC structure for that TPM2 Object.

   The size of the Name field can be derived by examining the nameAlg
   value, which defines the hashing algorithm and the resulting size.

   The Name field is returned in the TPM2B_ATTEST data field.

        typedef struct {
             TPM_GENERATED magic;
             TPMI_ST_ATTEST type;
             TPM2B_NAME qualifiedSigner;
             TPM2B_DATA extraData;
             TPMS_CLOCK_INFO clockInfo;
             UINT64 firmwareVersion;
             TPMU_ATTEST attested;
        } TPMS_ATTEST;

   where for a key object the attested field is

        typedef struct {
             TPM2B_NAME name;
             TPM2B_NAME qualifiedName;
        } TPMS_CERTIFY_INFO;

A.2.5.2.  TPM2 Public Structure

   Any TPM2 Object has an associated TPM2 Public structure defined as
   TPMT_PUBLIC.  This is defined below as a 'C' structure.  While there
   are many types of TPM2 Objects each with its own specific TPMT_PUBLIC
   structure (handled by the use of 'unions') this document will
   specifically define TPMT_PUBLIC for a TPM2 key object.

        typedef struct {
             TPMI_ALG_PUBLIC type;
             TPMI_ALG_HASH nameAlg;
             TPMA_OBJECT objectAttributes;
             TPM2B_DIGEST authPolicy;
             TPMU_PUBLIC_PARMS parameters;
             TPMU_PUBLIC_ID unique;
        } TPMT_PUBLIC;

   Where: * type and nameAlg are 16 bit TCG defined algorithms. *
   objectAttributes is a 32 bit field defining properties of the object,
   as shown below

Ounsworth, et al.       Expires 2 September 2024               [Page 26]
Internet-Draft        Remote Attestation with CSRs            March 2024

        typedef struct TPMA_OBJECT {
             unsigned Reserved_bit_at_0 : 1;
             unsigned fixedTPM : 1;
             unsigned stClear : 1;
             unsigned Reserved_bit_at_3 : 1;
             unsigned fixedParent : 1;
             unsigned sensitiveDataOrigin : 1;
             unsigned userWithAuth : 1;
             unsigned adminWithPolicy : 1;
             unsigned Reserved_bits_at_8 : 2;
             unsigned noDA : 1;
             unsigned encryptedDuplication : 1;
             unsigned Reserved_bits_at_12 : 4;
             unsigned restricted : 1;
             unsigned decrypt : 1;
             unsigned sign : 1;
             unsigned x509sign : 1;
             unsigned Reserved_bits_at_20 : 12;
        } TPMA_OBJECT;

   *  authPolicy is the Policy Digest needed to authorize use of the
      object.

   *  Parameters are the object type specific public information about
      the key.

      -  For key objects, this would be the key's public parameters.

   *  unique is the identifier for parameters

   The size of the TPMT_PUBLIC is provided by the following structure:

        typedef struct {
             UINT16     size;
             TPMT_PUBLIC publicArea;
        } TPM2B_PUBLIC;

A.2.5.3.  TPM2 Signatures

   TPM2 signatures use a union where the first field (16 bits)
   identifies the signature scheme.  The example below shows an RSA
   signature where TPMT_SIGNATURE->sigAlg will indicate to use
   TPMS_SIGNATURE_RSA as the signature.

Ounsworth, et al.       Expires 2 September 2024               [Page 27]
Internet-Draft        Remote Attestation with CSRs            March 2024

        typedef struct {
             TPMI_ALG_SIG_SCHEME sigAlg;
             TPMU_SIGNATURE signature;
        } TPMT_SIGNATURE;

        typedef struct {
             TPMI_ALG_HASH hash;
             TPM2B_PUBLIC_KEY_RSA sig;
        } TPMS_SIGNATURE_RSA;

A.2.5.4.  Attestation Key

   The uniquely identifying TPM2 key is the Endorsement Key (the EK).
   As this is a privacy sensitive key, the EK is not directly used to
   attest to any TPM2 asset.  Instead, the EK is used by an Attestation
   CA to create an Attestation Key (the AK).  The AK is assumed trusted
   by the Verifier and is assume to be loaded in the TPM during the
   execution of the process described in the subsequent sections.  The
   description of how to create the AK is outside the scope of this
   document.

A.2.5.5.  Attester Processing

   The only signed component is the TPM2B_ATTEST structure, which
   returns only the (key's) Name and the signature computed over the
   Name but no detailed information about the key.  As the Name is
   comprised of public information, the Name can be calculated by the
   Verifier but only if the Verify knows all the public information
   about the Key.

   The Attester's processing steps are as follows:

   Using the TPM2 command TPM2_Certify obtain the TPM2B_ATTEST and
   TPMT_SIGNATURE structures from the TPM2.  The signing key for
   TPMT_SIGNATURE is an Attention Key (or AK), which is assumed to be
   available to the TPM2 upfront.  More details are provided in
   Appendix A.2.5.4

   The TPM2 command TPM2_Certify takes the following input:

   *  TPM2 handle for Key (the key to be attested to)

   *  TPM2 handle for the AK (see Appendix A.2.5.4)

   It produces the following output:

   *  TPM2B_ATTEST in binary format

Ounsworth, et al.       Expires 2 September 2024               [Page 28]
Internet-Draft        Remote Attestation with CSRs            March 2024

   *  TPMT_SIGNATURE in binary format

   Then, using the TPM2 command TPM2_ReadPublic obtain the Keys
   TPM2B_PUBLIC structure.  While the Key's public information can be
   obtained by the Verifier in a number ways, such as storing it from
   when the Key was created, this may be impractical in many situations.
   As TPM2 provided a command to obtain this information, this
   specification will include it in the TPM2 Attestation CSR extension.

   The TPM2 command TPM2_ReadPublic takes the following input:

   *  TPM2 handle for Key (the key to be attested to)

   It produces the following output:

   *  TPM2B_PUBLIC in binary format

A.2.5.6.  Verifier Processing

   The Verifier has to perform the following steps once it receives the
   Evidence:

   *  Verify the TPM2B_ATTEST using the TPMT_SIGNATURE.

   *  Use the Key's "expected" Name from the provided TPM2B_PUBLIC
      structure.  If Key's "expected" Name equals
      TPM2B_ATTEST->attestationData then returned TPM2B_PUBLIC is the
      verified.

A.2.6.  Example Structures

   TODO -- a full CSR would be great.

A.3.  PSA Attestation Token in CSR

   The Platform Security Architecture (PSA) Attestation Token is defined
   in [I-D.tschofenig-rats-psa-token] and specifies claims to be
   included in an Entity Attestation Token (EAT).  [I-D.bft-rats-kat]
   defines key attestation based on the EAT format.  In this section the
   platform attestation offered by [I-D.tschofenig-rats-psa-token] is
   combined with key attestation by binding the key attestation token
   (KAT) to the platform attestation token (PAT) with the help of the
   nonce.  For details see [I-D.bft-rats-kat].  The resulting KAT-PAT
   bundle is, according to Section 5.1 of [I-D.bft-rats-kat], combined
   in a CMW collection [I-D.ietf-rats-msg-wrap].

   The encoding of this KAT-PAT bundle is shown in the example below.

Ounsworth, et al.       Expires 2 September 2024               [Page 29]
Internet-Draft        Remote Attestation with CSRs            March 2024

   EvidenceBundles
    +
    |
    +-> EvidenceBundle
         +
         |
         +->  EvidenceStatement
               +
               |
               +-> type: OID for CMW Collection
               |         1 3 6 1 5 5 7 1 TBD
               |
               +-> stmt: KAT/PAT CMW Collection

   The value in EvidenceStatement->stmt is based on the KAT/PAT example
   from Section 6 of [I-D.bft-rats-kat] and the result of CBOR encoding
   the CMW collection shown below (with line-breaks added for
   readability purposes):

   {
     "kat":
       h'd28443A10126A058C0A30A5820B91B03129222973C214E42BF31D68
         72A3EF2DBDDA401FBD1F725D48D6BF9C8171909C4A40102200121
         5820F0FFFA7BA35E76E44CA1F5446D327C8382A5A40E5F29745DF
         948346C7C88A5D32258207CB4C4873CBB6F097562F61D5280768C
         D2CFE35FBA97E997280DBAAAE3AF92FE08A101A40102200121582
         0D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD890C7FA27C9
         E354089BBE13225820F95E1D4B851A2CC80FFF87D8E23F22AFB72
         5D535E515D020731E79A3B4E47120584056F50D131FA83979AE06
         4E76E70DC75C070B6D991AEC08ADF9F41CAB7F1B7E2C47F67DACA
         8BB49E3119B7BAE77AEC6C89162713E0CC6D0E7327831E67F3284
         1A',
     "pat":
       h'd28443A10126A05824A10A58205CA3750DAF829C30C20797EDDB794
         9B1FD028C5408F2DD8650AD732327E3FB645840F9F41CAB7F1B7E
         2C47F67DACA8BB49E3119B7BAE77AEC6C89162713E0CC6D0E7327
         831E67F32841A56F50D131FA83979AE064E76E70DC75C070B6D99
         1AEC08AD'
   }

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

Ounsworth, et al.       Expires 2 September 2024               [Page 30]
Internet-Draft        Remote Attestation with CSRs            March 2024

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) }
  ;

-- 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

Ounsworth, et al.       Expires 2 September 2024               [Page 31]
Internet-Draft        Remote Attestation with CSRs            March 2024

}

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
}

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

Ounsworth, et al.       Expires 2 September 2024               [Page 32]
Internet-Draft        Remote Attestation with CSRs            March 2024

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 Richardson, Tomofumi Okubo, Olivier Couillard, John
   Gray, Eric Amador, Johnson Darren, Herman Slatman, Tiru Reddy, Corey
   Bonnell, 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.

   We would also like to specifically thank Monty Wiseman for providing
   the appendix showing how to carry a TPM 2.0 Attestation.

   Finally, we would like to thank Andreas Kretschmer and Thomas Fossati
   for their feedback based on 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

Ounsworth, et al.       Expires 2 September 2024               [Page 33]
Internet-Draft        Remote Attestation with CSRs            March 2024

   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 2 September 2024               [Page 34]