Use of Remote Attestation with Certification Signing Requests

4.1. Interaction with an HSM

This specification is applicable both in cases where a 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, 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. Encoding Strategy

To support a number of different use cases for the transmission of Evidence and certificate chains in a CSR the structure shown in Figure 3 is used.¶

On a high-level, the structure is composed as follows: A PKCS#10 attribute or a CRMF extension contains one EvidenceBundle structure. The EvidenceBundle contains one or more EvidenceStatement structures as well as one or more CertificateChoices which enable to carry various format of certificates.¶

Note: Since an extension must only be included once in a certificate see Section 4.2 of [RFC5280], it is RECOMMENDED to include the PKCS#10 attribute or the CRMF extension only once in a CSR.¶

A conformant implementation of an entity processing the CSR structures MUST be prepared to use certificates found in the EvidenceBundle structure to build a certification path to validate any EvidenceStatement. The following use cases are supported, as described in the sub-sections below.¶

5.1. Object Identifiers

This document references id-pkix and id-aa, both defined in [RFC5911] and [RFC5912].¶

This document defines the arc depicted in Figure 7.¶

-- 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 Evidence bundle of type EvidenceBundle containing one or more Evidence statements of a type EvidenceStatement along with optional certificates for certification path building. This structure enables different Evidence statements to share a certification path without duplicating it in the attribute.¶

EVIDENCE-STATEMENT ::= TYPE-IDENTIFIER

EvidenceStatementSet EVIDENCE-STATEMENT ::= {
   ... -- None defined in this document --
}

The expression illustrated in Figure 8 maps ASN.1 Types for Evidence Statements to the OIDs that identify them. These mappings are used to construct or parse EvidenceStatements. Evidence Statements are typically defined in other IETF standards, other standards bodies, or vendor proprietary formats along with corresponding OIDs that identify them.¶

This list is left unconstrained in this document. However, implementers can populate it with the formats that they wish to support.¶

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

In Figure 9, type is an OID that indicates the format of the value of stmt.¶

Based on the responsibilities of the different roles in the RATS architecture, Relying Parties need to relay Evidence to Verifiers for evaluation and obtain an Attestation Result in return. Ideally, the Relying Party should select a Verifier based on the received Evidence without requiring the Relying Party to inspect the Evidence itself. This "routing" decision is simple when there is only a single Verifier configured for use by a Relying Party but gets more complex when there are different Verifiers available and each of them capable of parsing only certain Evidence formats.¶

In some cases, the EvidenceStatement.type OID will be sufficient information for the Relying Party to correctly route it to an appropriate Verifier, however since the type OID only identifies the general data format, it is possible that multiple Verifiers are registered against the same type OID in which case the Relying Party will either require additional parsing of the evidence statement, or the Attester will be required to provide additional information.¶

To simplify the task for the Relying Party an optional field, the hint, is available in the EvidenceStatement structure, as shown in Figure 9. An Attester MAY include the hint to the EvidenceStatement and it MAY be processed by the Relying Party. The Relying Party MAY decide not to trust the information embedded in the hint or policy MAY override any information provided by the Attester via this hint.¶

When the Attester populates the hint, it MUST contain a fully qualified domain name (FQDN) which uniquely identifies a Verifier. The problem of mapping hint FQDNs to Verifiers, and the problem of FQDN collision is out of scope for this specification; it is assumed that Attester and Verifier makers can manage this appropriately on their own FQDN trees, however if this becomes problematic then a public registry may be needed.¶

In a typical usage scenario, the Relying Party is pre-configured with a list of trusted Verifiers and the corresponding hint values can be used to look up appropriate Verifier. Tricking an Relying Party into interacting with an unknown and untrusted Verifier must be avoided.¶

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 and the corresponding hint identifies the Verifier as "tpmverifier.example.com".¶

EvidenceBundle ::= SEQUENCE {
   evidences SEQUENCE SIZE (1..MAX) OF EvidenceStatement,
   certs SEQUENCE SIZE (1..MAX) OF CertificateChoices OPTIONAL
      -- CertificateChoices MUST only contain certificate or other,
      -- see Section 10.2.2 of [RFC5652]
}

The CertificateChoices structure defined in [RFC6268] allows for carrying certificates in the default X.509 [RFC5280] format, or in other non-X.509 certificate formats. CertificateChoices MUST only contain certificate or other. CertificateChoices MUST NOT contain extendedCertificate, v1AttrCert, or v2AttrCert. Note that for non-ASN.1 certificate formats, the CertificateChoices MUST use other [3] with an OtherCertificateFormat.Type of OCTET STRING, and then can carry any binary data.¶

id-aa-evidence OBJECT IDENTIFIER ::= { id-aa 59 }

-- For PKCS#10
attr-evidence ATTRIBUTE ::= {
  TYPE EvidenceBundle
  COUNTS MAX 1
  IDENTIFIED BY id-aa-evidence
}

-- For CRMF
ext-evidence EXTENSION ::= {
  SYNTAX EvidenceBundle
  IDENTIFIED BY id-aa-evidence
}

The Extension variant illustrated in Figure 10 is intended only for use within CRMF CSRs and is NOT RECOMMENDED to be used within X.509 certificates due to the privacy implications of publishing Evidence about the end entity's hardware environment. See Section 7.2 for more discussion.¶

The certs field contains a set of certificates that is intended to validate the contents of an Evidence statement contained in evidences, if required. For each Evidnece statement the set of certificates should contain the certificate that contains the public key needed to directly validate the Evidence statement. Additional certificates may be provided, for example, to chain the Evidence signer key back to an agreed upon trust anchor. No specific order of the certificates in certs SHOULD be expected because the certificates needed for different Evidence statements may be contained in certs.¶

This specification places no restriction on mixing certificate types within the certs field. For example a non-X.509 Evidence signer certificate MAY chain to a trust anchor via a chain of X.509 certificates. It is up to the Attester and its Verifier to agree on supported certificate formats.¶

By the nature of the PKIX ASN.1 classes [RFC5912], there are multiple ways to convey multiple Evidence statements: by including multiple copies of attr-evidence or ext-evidence, multiple values within the attribute or extension, and finally, by including multiple EvidenceStatement structures within an EvidenceBundle. The latter is the preferred way to carry multiple Evidence statements. Implementations MUST NOT place multiple copies of attr-evidence into a PKCS#10 CSR due to the COUNTS MAX 1 declaration. In a CRMF CSR, implementers SHOULD NOT place multiple copies of ext-evidence.¶

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 - This was early-allocated as 59 so that we could generate the sample data.¶

  • 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 an out-of-band communication channel. 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 an 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 extension 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". Often, the correct layer at which to address this is either in certificate profiles, a Certificate Practice Statement (CPS), or in the protocol or application that carries the CSR to the RA/CA where a flag can be added indicating whether the RA/CA should consider the evidence to be public or private.¶

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

7.4. Additional security considerations

In addition to the security considerations listed here, implementers should be familiar with the security considerations of the specifications on this this depends: PKCS#10 [RFC2986], CRMF [RFC4211], as well as general security concepts relating to evidence and remote attestation; many of these concepts are discussed in Section 6 of [RFC9334], Section 7 of [RFC9334], Section 9 of [RFC9334], Section 11 of [RFC9334], and Section 12 of [RFC9334]. Implementers should also be aware of any security considerations relating to the specific evidence format being carried within the CSR.¶

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-tpm-certify IDENTIFIED BY tcg-attest-tpm-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 ::= { tcg 20 }

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

Tcg-csr-tpm-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 {
      EvidenceBundle {
        Evidences {
          EvidenceStatement {
            type: tcg-attest-tpm-certify,
            stmt: <TcgAttestTpmCertify_data>
            hint: "tpmverifier.example.com"
          }
        },
        certs {
          akCertificate,
          caCertificate
        }
      }
    }
  }
}

-----BEGIN CERTIFICATE REQUEST-----
MIINmzCCDIUCAQAwdTELMAkGA1UEBhMCWloxETAPBgNVBAgMCFByb3ZpbmNlMREw
DwYDVQQHDAhMb2NhbGl0eTETMBEGA1UECgwKaWV0Zi1sYW1wczEXMBUGA1UECwwO
aWV0Zi1sYW1wcy1jc3IxEjAQBgNVBAMMCXRlc3Qta2V5MTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAN/RvsGNf32W6tIAU4QZgFPs98rPv4ed7QnB9aK/
+x8u+1qhiTNpNC2me0FsQEDvToROGhkxtiift2RKPaVR2hyF05tthjNDnfDaMqvk
NN24rmzTuVZE3Oz86zSWE+Lk3ZfWHROVb5ZTME/VOZdYMAvwyi2fRHa/1cK9F/61
WwIpY4qMlLsabSsSmyd8RJ+/g3exfCeCYJ73Cu90F0wNtYOTxVN5o4ELvJdElT99
QaC38TFvJ+yW94wQua2/4Lt6cx0I+NVDFHLMELwFydVdZspqFdEGp4X+i59hjD4A
FDPOyJJJiF84Zo7+Qf1tIbUCbFV+Rmvob7uCiOs8O3ZEL4kCAwEAAaCCCuEwggrd
BgsqhkiG9w0BCRACOzGCCswwggrIMIIC2jCCAtYGBWeBBRQBMIICsgSBkf9UQ0eA
FwAiAAs7ZAoM+pOXvuDS3cZXWSGXpKzEfn3C/aWh2zIlNmdIvQAEAP9VqgAAAAB9
6ovmAAAANwAAAAABIBUBEwAVSCIAIgALRsPuEbWtPA+cXiHVz6zdm6DfOYX8urrR
WvLWAoEkW8MAIgALVNyWWGbUmLvXnu/dEowodTbdqKJlrhaYITil2pXo7ooEggEA
hnwVHoLE43BfVyozOqnx9VfsdS7U4ZOP4pS04vrfGCLegjXEHjxcMyU3DcJtd7sv
jw5/IxnLXLD/WXAe1H5XbOreOgYVejzMO16DPWBV2m7LOUvvwSsIRhHJaL5wUxfu
LZoWY6Up7Q+gFtDvoHfRrKsbeMRoOWwQulUok0PhZw0R4ZQyFrc4/rBr9kS9Vpmt
A+3IMuZ/qujraPqbC/zn1OE20+AtiKU6L9kJUtlejf8RchWn4ffi4ugK4u7RvMQS
/lGn+5G1IfVQY55iMKdlHa9nyzknQQBYopF2JP+sntC2Zf65IasWyE7NWOsQSbyr
6/OSLggeNf5gU8SrRfzaAgSCARYAAQALAAYAcgAAABAAEAgAAAAAAAEA39G+wY1/
fZbq0gBThBmAU+z3ys+/h53tCcH1or/7Hy77WqGJM2k0LaZ7QWxAQO9OhE4aGTG2
KJ+3ZEo9pVHaHIXTm22GM0Od8Noyq+Q03biubNO5VkTc7PzrNJYT4uTdl9YdE5Vv
llMwT9U5l1gwC/DKLZ9Edr/Vwr0X/rVbAiljioyUuxptKxKbJ3xEn7+Dd7F8J4Jg
nvcK73QXTA21g5PFU3mjgQu8l0SVP31BoLfxMW8n7Jb3jBC5rb/gu3pzHQj41UMU
cswQvAXJ1V1mymoV0Qanhf6Ln2GMPgAUM87IkkmIXzhmjv5B/W0htQJsVX5Ga+hv
u4KI6zw7dkQviQwXdHBtdmVyaWZpZXIuZXhhbXBsZS5jb20wggfmMIIEaTCCA1Gg
AwIBAgIUfX4oc7u4KUbyz61VtQN5g2A2QMQwDQYJKoZIhvcNAQELBQAwdzELMAkG
A1UEBhMCWloxETAPBgNVBAgMCFByb3ZpbmNlMREwDwYDVQQHDAhMb2NhbGl0eTET
MBEGA1UECgwKaWV0Zi1sYW1wczEXMBUGA1UECwwOaWV0Zi1sYW1wcy1jc3IxFDAS
BgNVBAMMC3Rlc3Qtcm9vdENBMB4XDTI0MTAyMTIwMTcxMloXDTI0MTEyMDIwMTcx
MlowczELMAkGA1UEBhMCWloxETAPBgNVBAgMCFByb3ZpbmNlMREwDwYDVQQHDAhM
b2NhbGl0eTETMBEGA1UECgwKaWV0Zi1sYW1wczEXMBUGA1UECwwOaWV0Zi1sYW1w
cy1jc3IxEDAOBgNVBAMMB3Rlc3QtYWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDXjF+XF1wsywJx5e5MT1Q1TD8deZqxkQYGZM9TpW+rvFjnRdSDP88M
iLOPYcRIJQ+efHvo81o6IL7n0U0TSmaP63gaMCkOLr2BgNpBHGkfSbN2b16usBrQ
cYQF+o9NU5Itt/s7knvlhNiObOeWRBgtNPXeikyHycYjcZgoGd/UDvPRiRJ0pSru
SBDeS1x0uoTsvep0JSRBUiKh8d7D0H3UCmZZzVPzVBS1Z/Vl3a3HOjUgoAvXIBzu
kh/5BKdQSh5hfRnXi5v6lJGroWFWvsHVF2PLoOC2oaIrLZ3UVa05K4wVT/wKbi0O
cReufE9rK6CvmHEAUXi1cs+jynZfYaFDAgMBAAGjgfAwge0wgZ4GA1UdIwSBljCB
k6F7pHkwdzELMAkGA1UEBhMCWloxETAPBgNVBAgMCFByb3ZpbmNlMREwDwYDVQQH
DAhMb2NhbGl0eTETMBEGA1UECgwKaWV0Zi1sYW1wczEXMBUGA1UECwwOaWV0Zi1s
YW1wcy1jc3IxFDASBgNVBAMMC3Rlc3Qtcm9vdENBghR5pP+xxKsc67pLOqPiIZSU
4fgpzDAMBgNVHRMBAf8EAjAAMAsGA1UdDwQEAwIHgDAQBgNVHSUECTAHBgVngQUI
AzAdBgNVHQ4EFgQUH4QfxvcmPg9x21uQW5cfGyfxbMcwDQYJKoZIhvcNAQELBQAD
ggEBAC3Zz6B+u1H+72CG0j/s6lRPX/YP/DPjh5IIt9HdOJaWc5lsbCvgHSED7N/+
voCfCRf7IU2Oh5+2q9+9N5ARinXPmrsPZNyLR8vWkb27/hl9OTi0Ly7DtJMtUJTR
zq53dZc7kdTDNYpPnbIbanSOW3lSL5E173C8wyTsp/vQKteYTfmsDKw9hXHIU2eS
eUpZmKcHShXlbDEEbTuYLJMDASKmMCmPjIgJrSX/18wEoAgo2BVjjzwfhoc2SLnQ
dikvN6oa6Ee0zYRiImXpM7cuErC88jOr0quURA1U8fsQd8hYGRUk/6oPMXzIfZKs
z/yzAUQ570+mkdd2iFVlqTCQ9eUwggN1MIICXQIUeaT/scSrHOu6Szqj4iGUlOH4
KcwwDQYJKoZIhvcNAQELBQAwdzELMAkGA1UEBhMCWloxETAPBgNVBAgMCFByb3Zp
bmNlMREwDwYDVQQHDAhMb2NhbGl0eTETMBEGA1UECgwKaWV0Zi1sYW1wczEXMBUG
A1UECwwOaWV0Zi1sYW1wcy1jc3IxFDASBgNVBAMMC3Rlc3Qtcm9vdENBMB4XDTI0
MTAyMTIwMTcwOFoXDTI0MTEyMDIwMTcwOFowdzELMAkGA1UEBhMCWloxETAPBgNV
BAgMCFByb3ZpbmNlMREwDwYDVQQHDAhMb2NhbGl0eTETMBEGA1UECgwKaWV0Zi1s
YW1wczEXMBUGA1UECwwOaWV0Zi1sYW1wcy1jc3IxFDASBgNVBAMMC3Rlc3Qtcm9v
dENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxPODF6ujxbdDWuXn
zlqzYIO4rpQKolKfKbOFUCB6SjdA5XzArLTSYKD3ZXhqm7unFkmHC2HtqArq5jgv
cQ2fzJeNGbcuyJYSwa9WJjJ5qY6gXEY+G7sFgZ5ZeEWGQ+zjrnuJh/PtlhJ2/R7w
tdC82DAULaxnFjOS6Xm6pUB8RaZEtZ6HwfPUXYgeK9IRG2CbEs8jkoBQTrSKpdpC
0myJrrS0PoTFClDpq61je7uQgU6b9IAOfXi1oX5NdYcfqxcPch4wqbkldKsjC/i7
xMcem8hnb3WUvAmbsLP1I0Fx8nb0ug/T2ED5U9tPBXbKgeD72aU2L9GNs+ypE9Az
bTB6cwIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQBFBMAGsP1xKq4R4bzbWnQ4K2H+
rYNi8UEQzxN6BiANi9+8hbLHfx6gFZlz+QxwVyH6oQnNrsVVDVjEYH4/yvy7NdOx
VitFfqOYwyaNeK5oXx1l5otOaObtwzB7RVQNSlipzEVW4RPsJmx/8F7yNLtdgooP
U0QzUSqDcoKK36E4O3s85xfyNlEdJ2vJcJ/ZZx5QQlnhNTf5bWlr3U9x6DebeAqs
+wvvepdaNzulHBXaKIqAgSx9N+Y22vj+vw8GO4L8HndDPMhdE/Ct1h1yygm65j6h
aCmQRUTKzj49q6W4NHG7iPea+7bgMq7G4LRo9DSFEfMWOkQeVUSPPiTsaAahMAsG
CSqGSIb3DQEBCwOCAQEA1aPYnm8suCRwMTC7kOdOjvVP2+2pHxsI5vnLfffFgsaN
yoOz97t6bAmQXPQCEcjCQZqAynuJQITBbf5OowrNCOL8YRLaFu2zUS8H+XJUIU0I
YSs3H8UyfeYo5VDKJClU/OcSzGgGm6J9JDQiHUuEFrqbpE19aSztpXrEH9YYP87A
NyW9vxpLse2rpE4akcp+V+C958KJEoYQc9EfjvM3LqLmzp7pvyUalv21BbOweK8V
IYVK7djq+LCmYwJwdKrOYWmrDyH8P+me8nPtk9BdcvW+sj2qu/opZmYEL4KAqAvi
BW5TzPFUgQhmMalis/J4WY3Q0tvOMXRQQZCmO2N4Pg==
-----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.¶

EvidenceBundle
   +
   |
   + Evidences
   |
   +---->  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 Example in ASN.1

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

=============== NOTE: '\' line wrapping per RFC 8792 ================

CsrAttestationDiceExample DEFINITIONS IMPLICIT TAGS ::= BEGIN

IMPORTS

tcg-dice-conceptual-message-wrapper FROM TcgDiceAttestation
DiceConceptualMessageWrapper FROM TcgDiceAttestation
tcg-dice-TcbInfo FROM TcgDiceAttestation
DiceTcbInfo FROM TcgDiceAttestation
EvidenceStatementSet FROM CsrAttestation
;

tcgDiceCmwEvidenceStatementES EVIDENCE-STATEMENT ::= {
  DiceConceptualMessageWrapper IDENTIFIED BY tcg-dice-conceptual-\
                                                    message-wrapper }

tcgDiceTcbInfoEvidenceStatementES EVIDENCE-STATEMENT ::= {
  DiceTcbInfo IDENTIFIED BY tcg-dice-TcbInfo }
-- where ConceptualMessageWrapper, tcg-dice-conceptual-message-\
                           wrapper, DiceTcbInfo, and tcg-dice-TcbInfo
-- are defined in DICE-Attestation-Architecture-Version-1.1-Revision\
                                                     -18_6Jan2024.pdf

EvidenceStatementSet EVIDENCE-STATEMENT ::= {
  tcgDiceEvidenceStatementES,
  tcgDiceTcbInfoEvidenceStatementES
  ...
}
END

TcgDiceAttestation DEFINITIONS AUTOMATIC TAGS ::= BEGIN

EXPORTS ALL;

tcg OBJECT IDENTIFIER ::= { 2 23 133 }
tcg-dice OBJECT IDENTIFIER ::= { tcg platformClass(5) dice(4) }
tcg-dice-TcbInfo OBJECT IDENTIFIER ::= { tcg-dice tcbinfo(1) }
tcg-dice-endorsement-manifest-uri OBJECT IDENTIFIER ::= { tcg-dice \
                                                    manifest-uri(3) }
tcg-dice-Ueid OBJECT IDENTIFIER ::= { tcg-dice ueid(4) }
tcg-dice-MultiTcbInfo OBJECT IDENTIFIER ::= {tcg-dice multitcbinfo(5\
                                                                  ) }
tcg-dice-UCCS-evidence OBJECT IDENTIFIER ::= {tcg-dice uccs-evidence\
                                                                (6) }
tcg-dice-manifest-evidence OBJECT IDENTIFIER ::= {tcg-dice manifest-\
                                                       evidience(7) }
tcg-dice-MultiTcbInfoComp OBJECT IDENTIFIER ::= {tcg-dice \
                                                multitcbinfocomp(8) }
tcg-dice-conceptual-message-wrapper OBJECT IDENTIFIER ::= { tcg-\
                                                        dice cmw(9) }
tcg-dice-TcbFreshness OBJECT IDENTIFIER ::= { tcg-dice tcb-freshness\
                                                               (11) }

DiceConceptualMessageWrapper ::= SEQUENCE {
  cmw OCTET STRING
}

DiceTcbInfo ::= SEQUENCE {
  vendor [0] IMPLICIT UTF8String OPTIONAL,
  model [1] IMPLICIT UTF8String OPTIONAL,
  version [2] IMPLICIT UTF8String OPTIONAL,
  svn [3] IMPLICIT INTEGER OPTIONAL,
  layer [4] IMPLICIT INTEGER OPTIONAL,
  index [5] IMPLICIT INTEGER OPTIONAL,
  fwids [6] IMPLICIT FWIDLIST OPTIONAL,
  flags [7] IMPLICIT OperationalFlags OPTIONAL,
  vendorInfo [8] IMPLICIT OCTET STRING OPTIONAL,
  type [9] IMPLICIT OCTET STRING OPTIONAL,
  flagsMask [10]IMPLICIT OperationalFlagsMask OPTIONAL,
  integrityRegisters [11] IMPLICIT IrList OPTIONAL
}

FWIDLIST ::= SEQUENCE SIZE (1..MAX) OF FWID
  FWID ::= SEQUENCE {
  hashAlg OBJECT IDENTIFIER,
  digest OCTET STRING
}

OperationalFlags ::= BIT STRING {
  notConfigured (0),
  notSecure (1),
  recovery (2),
  debug (3),
  notReplayProtected (4),
  notIntegrityProtected (5),
  notRuntimeMeasured (6),
  notImmutable (7),
  notTcb (8),
  fixedWidth (31)
}

OperationalFlagsMask ::= BIT STRING {
  notConfigured (0),
  notSecure (1),
  recovery (2),
  debug (3),
  notReplayProtected (4),
  notIntegrityProtected (5),
  notRuntimeMeasured (6),
  notImmutable (7),
  notTcb (8),
  fixedWidth (31)
}

IrList ::= SEQUENCE SIZE (1..MAX) OF IntegrityRegister

IntegrityRegister ::= SEQUENCE {
  registerName IA5String OPTIONAL,
  registerNum INTEGER OPTIONAL,
  hashAlg OBJECT IDENTIFIER,
  digest OCTET STRING
}

EndorsementManifestURI ::= SEQUENCE {
  emUri UTF8String
}

TcgUeid ::= SEQUENCE {
  ueid OCTET STRING
}

DiceTcbInfoSeq ::= SEQUENCE SIZE (1..MAX) OF DiceTcbInfo

DiceTcbInfoComp ::= SEQUENCE SIZE (1..MAX) OF TcbInfoComp

TcbInfoComp ::= SEQUENCE {
  commonFields [0] IMPLICIT DiceTcbInfo,
  evidenceValues [1] IMPLICIT DiceTcbInfoSeq
}

UccsEvidence ::= SEQUENCE {
  uccs OCTET STRING
}

Manifest ::= SEQUENCE {
  format ManifestFormat,
  manifest OCTET STRING
}

ManifestFormat ::= ENUMERATED {
  swid-xml    (0),
  coswid-cbor (1),
  coswid-json (2),
  tagged-cbor (3)
}

DiceTcbFreshness ::= SEQUENCE {
  nonce OCTET STRING
}
END

B.2. TCG DICE TcbInfo Example 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 DiceTcbInfo, as defined in [TCGDICE1.1].¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

// SET of CSR Attributes
A0 82 00 8E
  // CSR attributes
  30 82 00 8A
    // OBJECT IDENTIFIER id-aa-evidence (1 2 840 113549 1 9 16 2 59)
    06 0B 2A 86 48 86 F7 0D 01 09 10 02 3B
      // SET -- This attribute
      31 79
        // EvidenceBundles ::= SEQUENCE SIZE (1..MAX) OF \
                                                       EvidenceBundle
        30 77
          // EvidenceBundle ::= SEQUENCE
          30 75
            // EvidenceStatements ::= SEQUENCE SIZE (1..MAX) OF \
                                                    EvidenceStatement
            30 73
              // EvidenceStatement ::= SEQUENCE
              30 71
                // type: OBJECT IDENTIFIER tcg-dice-TcbInfo (2.23.\
                                                           133.5.4.1)
                06 06 67 81 05 05 04 01
                // stmt: SEQUENCE
                30 4E
                  // CONTEXT_SPECIFIC | version (02)
                  // version = ABCDEF123456
                  82 0C 41 42 43 44 45 46 31 32 33 34 35 36
                  // CONTEXT_SPECIFIC | svn (03)
                  // svn = 4
                  83 01 04
                  // CONTEXT_SPECIFIC | CONSTRUCTED | fwids (06)
                  A6 2F
                  // SEQUENCE
                  30 2D
                    // OBJECT IDENTIFIER SHA256
                    06 09 60 86 48 01 65 03 04 02 01
                    // OCTET STRING
                    // fwid = 0x0000....00
                    04 20 00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00
                    00 00 00 00 00 00 00 00
                  // CONTEXT_SPECIFIC | vendorInfo (08)
                  // vendor info = 0x00000000
                  88 04 00 00 00 00
                  // CONTEXT_SPECIFIC | type (09)
                  // type = 0x00000000
                  89 04 00 00 00 00
                // hint: UTF8STRING "DiceTcbInfo.example.com"
                0C 17 44 69 63 65 54 63 62 49 6e 66 6f
                2e 65 78 61 6d 70 6c 65 2e 63 6f 6d

// BER only
A0 82 00 8E 30 82 00 8A 06 0B 2A 86 48 86 F7 0D
01 09 10 02 3B 30 7B 31 79 30 77 30 75 30 73 30
71 06 06 67 81 05 05 04 01 30 4E 82 0C 41 42 43
44 45 46 31 32 33 34 35 36 83 01 04 A6 2F 30 2D
06 09 60 86 48 01 65 03 04 02 01 04 20 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 88 04 00
00 00 00 89 04 00 00 00 00 0C 17 44 69 63 65 54
63 62 49 6e 66 6f 2e 65 78 61 6d 70 6c 65 2e 63
6f 6d