Use of Remote Attestation with Certification Signing Requests

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

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

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

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

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

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

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

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

EvidenceStatements ::= SEQUENCE SIZE (1..MAX) OF EvidenceStatement

EvidenceStatement ::= SEQUENCE {
   type   EVIDENCE-STATEMENT.&id({EvidenceStatementSet}),
   stmt   EVIDENCE-STATEMENT.&Type({EvidenceStatementSet}{@type}),
   hint   UTF8String OPTIONAL
}

The type is on OID indicating the format of the data contained in stmt.¶

The Attester MAY populate the hint with the name of a Verifier software package which will be capable of parsing the data contained in EvidenceStatement.stmt; this is to help the Relying Party select the correct Verifier without requiring the Relying Party to perform any parsing of the data in EvidenceStatement.stmt. The type OID, which identifies the format of the data found in the evidence statement, will sometimes be sufficient for a Relying Party to select the correct Verifier (software) to invoke, however in some cases the Relying Party may have more than one Verifier capable of parsing a given type OID -- for example if the OID indicates a wrapper format such as DICE ConceptualMessageWrapper which will contain further proprietary data. A design goal of this specification is that Relying Parties be able to select the correct Verifier (software) without needing to perform any parsing of the EvidenceStatement.stmt data. To help with this, the Attester MAY populate the hint with the name of a software package that will be capable of parsing this data. The hint SHOULD contain a value which is unique to this Verifier, such as a fully qualified domain name (FQDN), a uniform resource name (URN) [RFC8141] or a registered value corresponding to this evidence format. 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.¶

Usage of the hint field can be seen in the TPM2_attest example in Appendix A.2 where the type OID indicates the OID id-TcgAttestCertify, while the hint indicates the the Verifier software "tpmverifier.example.com" should be invoked for parsing it.¶

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

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              Certificate,
                           -- Using the Certificate ASN.1
                           -- structure as defined in RFC 5280.
      typedCert     [0] TypedCert,
      typedFlatCert [1] 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.¶

TypedFlatCert ::= SEQUENCE {
    certType OBJECT IDENTIFIER,
    certBody OCTET STRING
}

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

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

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

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

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

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

This is a complete and canonical example that can be used to test parsers implemented against this specification. Readers who wish the sample data may skip to Appendix A.2.6; the following sections explain the TPM-specific data structures needed to fully parse the contents of the evidence statement.¶

tcg OBJECT IDENTIFIER ::= { 2 23 133 }

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

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

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

Tcg-csr-certify ::= SEQUENCE {
  tpmSAttest       OCTET STRING,
  signature        OCTET STRING,
  tpmTPublic       OCTET STRING OPTIONAL
}

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

     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;

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

     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;

     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;

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

     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;

CSR {
  attributes {
    id-aa-evidence {
      EvidenceBundles {
        EvidenceBundle {
          EvidenceStatements {
            EvidenceStatement {
              type: tcg-attest-tpm-certify,
              stmt: <TcgAttestTpmCertify_data>
              hint: "tpmverifier.example.com"
            }
          },
          certs {
            akCertificate,
            caCertificate
          }
        }
      }
    }
  }
}

-----BEGIN CERTIFICATE REQUEST-----
MIIMmjCCC4QCAQAwcjELMAkGA1UEBhMCQVUxDDAKBgNVBAgMA1FMRDERMA8GA1UE
BwwIQnJpc2JhbmUxGzAZBgNVBAoMEmlldGYtMTE5LWhhY2thdGhvbjEWMBQGA1UE
CwwNaWV0Zi1jc3ItdGVzdDENMAsGA1UEAwwEa2V5MTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAM3AeVGnRgRMijvkuKreB+B6vWEi7QXRANIhvvkcHH3h
Jg0y//13XTQjUC0/pj5Hi66ILSxMru5j2aNZ7n5THEK2dMqrjjLokcfojdAoErK6
BmGHSCB8US41tb7qurneJzRCO0VGExpAKI1Ps05j0HHtYvwqHTlikWCpIOiDkNQt
gz7sgr3z3aE2OKqsXfYehnBIJbqdClOMz7C23V/XcjEi/WF0vGTboHYmLHNwkTr5
VrFhDqKFxQUx4+neqSJGeo30USno6Lr8hFAufxQzzoiFx571C4Wad+J1chCKORb/
5Kbu4O7wu9doOsFK+I2anUHFEJS5wowVfcWuyjcIZ/0CAwEAAaCCCeMwggnfBgsq
hkiG9w0BCRACOzGCCc4wggnKMIIJxjCCAtwwggLYBgVngQUUATCCArQEgZH/VENH
gBcAIgALgSWffuitIOAJ6HaGbtjgb5HYkvYKKPpxeBsZOS8nnxgABAD/VaoAAAAA
Nc8rIAAAAAcAAAAAASAZECMAFjY2ACIACwIYIzzfD3YNj+9DpDfm6cw/eyH2BuNJ
me/FQlkl1WnlACIAC66AuFfCBmj8QrwfqOSqNt/dUwtgVMSh+iaYiSJslGTiBIIB
ADLHaelFw/JTKhJbwi0tz5zkzJVyfo1nHER2s1YWZj/7GNcNZ5uvtcYgK65XIyMw
LjIA0AncNhOVAJhJm0uRkbjUmvtW5kGpDtepFqQj394N4XiXulGIXimwVKkc9lqS
kkRcfmzqomSaMmafVwXBAQ1NGrHV/PaX7IUlW5Hqo3Ja++sYro8y/hEQL3ILXdEG
lQEj/wB9NhiuVqW/SpT0iIs+E1MD2uJRICxCw21F352BGiAda0pmvr7nknJhv5kM
gWKInhonhLfLXlWVmvI+pf/z4QHXSWNZoibiihRcP7Eruq1X+VMx2T+Au2Q2O8zz
9omo9Ktyq/cZDUGsLcs5E0UEggEYARYAAQALAAYAcgAAABAAEAgAAAAAAAEAzcB5
UadGBEyKO+S4qt4H4Hq9YSLtBdEA0iG++RwcfeEmDTL//XddNCNQLT+mPkeLrogt
LEyu7mPZo1nuflMcQrZ0yquOMuiRx+iN0CgSsroGYYdIIHxRLjW1vuq6ud4nNEI7
RUYTGkAojU+zTmPQce1i/CodOWKRYKkg6IOQ1C2DPuyCvfPdoTY4qqxd9h6GcEgl
up0KU4zPsLbdX9dyMSL9YXS8ZNugdiYsc3CROvlWsWEOooXFBTHj6d6pIkZ6jfRR
KejouvyEUC5/FDPOiIXHnvULhZp34nVyEIo5Fv/kpu7g7vC712g6wUr4jZqdQcUQ
lLnCjBV9xa7KNwhn/QwXdHBtdmVyaWZpZXIuZXhhbXBsZS5jb20wggbiMIIDazCC
AlMCFD+SFCWsL2qqj29Qjboa1MYhl3spMA0GCSqGSIb3DQEBCwUAMHQxCzAJBgNV
BAYTAkFVMQwwCgYDVQQIDANRTEQxETAPBgNVBAcMCEJyaXNiYW5lMRswGQYDVQQK
DBJpZXRmLTExOS1oYWNrYXRob24xFjAUBgNVBAsMDWlldGYtY3NyLXRlc3QxDzAN
BgNVBAMMBnJvb3RDQTAeFw0yNDA1MDUwMDMyMjhaFw0yNDA2MDQwMDMyMjhaMHAx
CzAJBgNVBAYTAkFVMQwwCgYDVQQIDANRTEQxETAPBgNVBAcMCEJyaXNiYW5lMRsw
GQYDVQQKDBJpZXRmLTExOS1oYWNrYXRob24xFjAUBgNVBAsMDWlldGYtY3NyLXRl
c3QxCzAJBgNVBAMMAmFrMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA
rJwY3dhpjd5Mm4r8Gcjx6qympTD8J+ldfUVglCFXxVpmZmX7Bec6fPcARLBR4jte
/Y/UGszreRv8WQ2O6J85XMPiJvYeWQExVL3NU5izX7+DVqX0is3HARUfkyXgF8zL
2BkSgQcuYqAR2riG6YH+waE44qCVAi/k9nni25CtsHzyD6twWvvE3BdhzBt8j1eA
1qWgOvVebVmMuN53caNkeAMb6a+OIirsU/eCbP0mycDfwabHg1DNCVio3pgQWJeW
uNsYWcCNDZ0yYOKKGzN4tmu1se3NyZRPPU1H6SGlgqLPlJce1KDnLc9E1hBX8gCJ
Aw7kzR66MXSNW9j9rHnYOQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCSNgvEgZju
zRqBiwVfe7Jy3ZfNwacVinS38SlKdaZsfeh+qpR6YCyeumS2Is8Ei70OzSr8QuN5
NYQamDSnbjsJoCoWLk3O4S/JAXHXdKesBNGY8/wG3nxMSjzoaQ6UXOrsXWtgPKUg
0/3bWN8JYrQPp2Ieggi/pE0DRE0vvO2LfA3L19la7mVYv0SWk/vEj5rVrqOWAHYu
4TUC+9lm3k6QmGgf6MTC3tPgE3/Xi/tIKOlf0McdNfVNRA4tlhKb+jZaUC5AeNfp
d74RTjICwRjQct3yS+GdtShiXUdyu04kgkruQTf2RBZ+QxFaYS0cVqfiYRRE5CZO
oMnqMV0Ezwu/MIIDbzCCAlcCFAUfP4YmjszQY/Vtn/04g5htsJN7MA0GCSqGSIb3
DQEBCwUAMHQxCzAJBgNVBAYTAkFVMQwwCgYDVQQIDANRTEQxETAPBgNVBAcMCEJy
aXNiYW5lMRswGQYDVQQKDBJpZXRmLTExOS1oYWNrYXRob24xFjAUBgNVBAsMDWll
dGYtY3NyLXRlc3QxDzANBgNVBAMMBnJvb3RDQTAeFw0yNDA1MDUwMDMyMjBaFw0z
NDA1MDMwMDMyMjBaMHQxCzAJBgNVBAYTAkFVMQwwCgYDVQQIDANRTEQxETAPBgNV
BAcMCEJyaXNiYW5lMRswGQYDVQQKDBJpZXRmLTExOS1oYWNrYXRob24xFjAUBgNV
BAsMDWlldGYtY3NyLXRlc3QxDzANBgNVBAMMBnJvb3RDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAJ7JEtP/VDfRndsRmNqCs3iD/oLVSX2LSrkV2cb4
Cj9P5qwarxdBMuQocKyY/WZ3kL3iLXJfo3jzLQ90cMkoJ88swcY94I4d/SLE9E7s
X8+CTeyVfuvZ40dbrbxifNDRZWpdBCEt0J/kYtwEJMNqwGrPsYsZoQh3Ge9IMiPo
GiQSFHFiosl59xCf4Fp7HLAzASQTzRgAJg7T24djiV9G8lnR+pDKRKaMiwbhaUyv
rYV+9Ogs5QLmQRD3kutPNs/57imqb2JMypF2JdDZ8fOj1D8AIQJDxOQSpzqJq5Oo
d0OMPEsH9ZiliMOjzCKU2P5cnEeVoWzraiY7Is6z2/8/LQkCAwEAATANBgkqhkiG
9w0BAQsFAAOCAQEAjv0pbXilgnaD9xJLwn60uO/RQY4Npxclf5FiWIqeHQ12ssKE
sAqodmRzo8xz3/y+Zk5BYMfXDtB4SG/XIZ/Xuo1Jc7GYrUJg5oXYRxsejjdb0z6K
WzIe5l5hFkbSJnLfWNx/DcGyeOXDRfRTwOAuC4i2IMQBHOMCVq3btQXuKW8foEDF
u85w7fT0YbiXdgRyU6LROxy8odMDqgDqTh9PS2adqlF2N/A3NNV2bK5ae0zldniN
e8zqFpIKrNjGv81svpUCh+YgQK/LBU0W0Mi70nrp8uFWN88vv/Pl+CVX5zJIEHM6
Mzil8NgCaWeRXg0d9RHn8z0JwuEZXThJtpv7JTALBgkqhkiG9w0BAQsDggEBAF9Q
3g8tC87eaabivJ8kU10vA6EhAA3aSC7iqOqQxgrc80g5jn+y8mZUE8WhEeS+SN2W
ewSEr3L+LQdftCtWETKreJXVfqqwDh5UkmB5R7tds+HLrNUy9cVT4K/PvhS/yhMa
qLtl2DuXHfDtdRgn4O4vOAJqyHm3CKm2tIlr22vG3tRH1kRjnZLUvtsIN2uzLbC3
vQXFf0dKOw3U2bhVywyj6RF9bXObFTzUPArfHm+bSTtKmUJxBnApn8uBw4eLapAc
Aor2874rll5Ey3pSng9lCgKE2nn8Xuw3ZGys894nOJc15Uwr/QP2aKHnv/MzdXwU
mBFIOcV149HcobQM974=
-----END CERTIFICATE REQUEST-----

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

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

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