4.1.Model for Evidence and Endorsements in CSR

To support a number of different use cases for the transmission ofEvidence, Endorsements and certificate chains needed to validate them in a CSR the structureshown inFigure 3 is used.¶

On a high-level, the structure is composed as follows:A PKCS#10 attribute or a CRMF extension contains oneEvidenceBundle structure. The EvidenceBundle contains one or moreEvidenceStatement structures as well as one or moreCertificateChoices which enable to carry various format ofcertificates. For the purpose of conveyance within these structures,Evidence and Endorsements are considered interchangeable since they are both signed data objects with a certificate chain that needs to be validated by a Verifier, so for theremainder of this document, the term "Evidence" will be used to refer to both types of RATS conceptual messages.¶

Note: Since an extension must only be included once in a certificateseeSection 4.2 of [RFC5280], this PKCS#10 attributeor the CRMF extensionMUST only be included once in a CSR.¶

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

4.2.Model for Attestation Result in CSR

Figure 7 illustrates the information model for transmittingAttestation Results as a PKCS#10 attribute or a CRMF extension. Thisstructure includes a single AttestationResultBundle, which in turn comprisesone or more AttestationResult structures.¶

A Relying Party receiving a CSR containing an Attestation ResultMUST use the Type informationto parse the content. The Attestation Result encodingMUST provide information for the RelyingParty to determine the Verifier, who created and protected the Attestation Result against modifications.¶

5.1.Object Identifiers

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

5.2.Evidence Attribute and Extension

By definition, attributes within a PKCS#10 CSR aretyped as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION.This attribute definition contains oneEvidence bundle of typeEvidenceBundle containingone or more Evidence statements of a typeEvidenceStatement along withoptional certificates for certification path building.This structure enables different Evidence statements to share acertification path without duplicating it in the attribute.¶

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

The expression illustrated inFigure 8 maps ASN.1 Typesfor Evidence Statements to the OIDsthat identify them. These mappings are used to constructor parse EvidenceStatements. Evidence Statements are typicallydefined 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 canpopulate it with the formats that they wish to support.¶

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

InFigure 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 obtainan Attestation Result in return. Ideally, the Relying Party should select a Verifierbased on the received Evidence without requiring the Relying Party to inspect theEvidence itself. This "routing" decision is simple when there is only a singleVerifier configured for use by a Relying Party but gets more complex when thereare different Verifiers available and each of them capable of parsing only certainEvidence formats.¶

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

To simplify the task for the Relying Party to select an appropriate Verifieran optional field, the hint, is available in the EvidenceStatement structure,as shown inFigure 9. An AttesterMAY include the hint tothe EvidenceStatement and itMAY be processed by the Relying Party. TheRelying PartyMAY decide not to trust the information embedded in the hintor policyMAY override any information provided by the Attester via this hint.¶

When the Attester populates the hint, itMUST contain a server name whichuniquely identifies a Verifier. Server names are ASCII strings thatcontain a hostname and optional port, where the port is implied to be"443" if missing. The names use the format of the authority portionof a URI as defined in Section 3.2 of[RFC3986]. The namesMUST NOTinclude a "userinfo" portion of an authority. For example, a validserver name might be "verifier.example.com" or"verifier.example.com:8443", but not "verifier@example.com".¶

Relying PartiesSHOULD NOT connect to a host name provided in the hint,especially if the verifier has no previous trust relationship with thathost name, instead thisSHOULD be used only as a lookup string fordetermining between a list of Verifiers that the Relying Party ispre-configured to use.¶

In a typical usage scenario, the Relying Party is pre-configured witha list of trusted Verifiers and the corresponding hint values can be used to lookup appropriate Verifier. The Relying Party is also configured with a trustanchor for each Verifier, which allows the Verifier to validate the signatureprotecting the Attestation Result. Tricking a Relying Party into interactingwith an unknown and untrusted Verifier must be avoided.¶

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. CertificateChoicesMUST only contain certificate or other. CertificateChoicesMUST NOT contain extendedCertificate, v1AttrCert, or v2AttrCert. Note that for non-ASN.1 certificate formats, the CertificateChoicesMUST useother [3] with anOtherCertificateFormat.Type ofOCTET STRING, and then can carry any binary data.¶

Thecerts field contains a set of certificates thatis intended to validate the contents of an Evidence statementcontained inevidences, if required. For each Evidence statement, the set of certificatesSHOULD containthe certificate that contains the public key needed to directly validate theEvidence statement, unless the signing key is expected to be known to the Verifier or is embedded within the statement. Additional certificatesMAY be provided, for example, to chain theEvidence signer key back to an agreed upon trust anchor. No specific order of the certificates incertsSHOULD be expected because certificates contained incerts may be needed to validate different Evidence statements.¶

This specification places no restriction on mixing certificate types within thecerts field. For example a non-X.509 Evidence signer certificateMAY 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.¶

id-aa-evidence OBJECT IDENTIFIER ::= { id-aa 59 }-- For PKCS#10attr-evidence ATTRIBUTE ::= {  TYPE EvidenceBundle  COUNTS MAX 1  IDENTIFIED BY id-aa-evidence}-- For CRMFext-evidence EXTENSION ::= {  SYNTAX EvidenceBundle  IDENTIFIED BY id-aa-evidence}

The Extension variant illustrated inFigure 10 is intended only for use within CRMF CSRs and isNOT RECOMMENDED to be used within X.509 certificates due to the privacy implications of publishing Evidence about the end entity's hardware environment. SeeSection 9.3 for more discussion.¶

By the nature of the PKIX ASN.1 classes[RFC5912], there are multiple ways to convey multiple Evidence statements: by including multiple copies ofattr-evidence orext-evidence, multiple values within the attribute or extension, and finally, by including multipleEvidenceStatement structures within anEvidenceBundle. The latter is the preferred way to carry multiple Evidence statements. ImplementationsMUST NOT place multiple copies ofattr-evidence into a PKCS#10 CSR due to theCOUNTS MAX 1 declaration. In a CRMF CSR, implementersSHOULD NOT place multiple copies ofext-evidence.¶

6.1.Object Identifiers

This document defines the OID depicted inFigure 11 as an additional CSR Attribute (PKCS#10) or Extension (CRMF) to carry Attestation Results in a CSR.¶

-- OID for Attestation Result typesid-aa-ar OBJECT IDENTIFIER ::= { id-aa (TBD2) }

6.2.Attestation Result Attribute and Extension

By definition, attributes within a PKCS#10 CSR aretyped as ATTRIBUTE and within a CRMF CSR are typed as EXTENSION.This attribute definition contains one AttestationResultBundle structure.¶

ATTESTATION-RESULT ::= TYPE-IDENTIFIERAttestationResultSet ATTESTATION-RESULT ::= {   ... -- None defined in this document --}

The expression illustrated inFigure 12maps ASN.1 Types for Attestation Result to the OIDs that identify them. Thesemappings are used to construct or parse AttestationResults. Attestation Resultsare defined in other IETF standards (see[I-D.ietf-rats-ar4si]),other standards bodies, or vendor proprietary formats along with correspondingOIDs that identify them.¶

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

AttestationResult ::= SEQUENCE {   type   ATTESTATION-RESULT.&id({AttestationResultSet}),   stmt   ATTESTATION-RESULT.&Type({AttestationResultSet}{@type}),}

InFigure 13, type is an OID that indicates the format of thevalue of stmt.¶

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

-- For PKCS#10attr-ar ATTRIBUTE ::= {  TYPE AttestationResultBundle  COUNTS MAX 1  IDENTIFIED BY id-aa-ar}-- For CRMFext-ar EXTENSION ::= {  SYNTAX AttestationResultBundle  IDENTIFIED BY id-aa-ar}

7.1.Is the CSR constructed inside or outside the Attester?

This specification is applicable both in cases where a CSRis constructed internally or externally to the Attesting Environment, from thepoint of view of the calling application. This section is particularlyapplicable to the background check model.¶

Cases where the CSR is generated internally to the Attesting Environmentare straightforward: the hardware security module (HSM) generates and embedsthe Evidence and the corresponding certification paths when constructing the CSR.¶

Cases where the CSR is generated externally might require extra communicationbetween the CSR generator and the Attesting Environment, first to obtainthe necessary Evidence about the subject key, and then to usethe subject key to sign the CSR; for example, a CSR generated bya 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 andsome cryptographic library is assembling a CSR by interacting with the HSM over somenetwork protocol, then the interaction would conceptually be:¶

7.2.Separation of RA and CA roles with respect to Attestation Results

As described inSection 3, CSRsMAY contain either Evidence or Attestation Results (AR),and also the registration authority (RA) and certification authority (CA)MAY be conceptualized asa single Relying Party entity, or as separate entities. There are some implications here worth discussion.¶

In many cases, the Evidence contained within a CSR is intended to be consumed by the RA and notto be placed into the issued certificate.In some RA / CA architectures, itMAY be appropriate for the RA to "consume" the Evidenceand remove it from the CSR, re-signing the CSR with an RA signing key. A CRMF CSR also allows the RAto indicate that it verified the CSR without the need to re-signing the CSR.¶

In any case where the RA and CA roles are separated, and Evidence is evaluated and consumed by the RA,the RA does at least implicitly produce Attestation Results as defined in the RATS Architecture[RFC9334].For example, the decision to reject the Evidence and fail back to the client, or to accept the Evidence andforward a request to the CA could be viewed as a boolean Attestation Result.Similarly, if acceptance or rejection of the Evidence controls the presence or absence of a certain policy OIDor other extension in the issued certificate, this could also be viewed as an Attestation Result.¶

Alternatively, the RAMAY place explicit Attestation Results into its request to the CA; either for consumptionby the CA or for inclusion in the issued certificate.The exact mechanisms for doing this are out-of-scope for this document, but are areas for implementationconsideration and potential future standardization work.¶

8.1.Module Registration - SMI Security for PKIX Module Identifier

IANA is asked to register the following within the registry id-modSMI Security for PKIX Module Identifier (1.3.6.1.5.5.7.0).¶

• Decimal: IANA Assigned -Replace TBDMOD¶

• Description: CSR-ATTESTATION-2023 - id-mod-pkix-attest-01¶

• References: This Document¶

8.2.Object Identifier Registrations - SMI Security for S/MIME Attributes

IANA is asked to register the following within the registry id-aaSMI Security for S/MIME Attributes (1.2.840.113549.1.9.16.2).¶

• Evidence Statement¶

• Decimal: IANA Assigned - This was early-allocated as59 so that we could generate the sample data.¶

• Description: id-aa-evidence¶

• References: This Document¶

• Attestation Result¶

• Decimal: IANA Assigned - -Replace TBD2¶

• Description: id-aa-ar¶

• References: This Document¶

8.3.Attestation Evidence OID Registry

IANA is asked to create a registry that helps developers to findOID/Evidence mappings that may be encountered in the wild, as well asa link to their specification document.This registry should follow the rules for"Specification Required" as laid out in[RFC5226].¶

Each row corresponds to an OID and ASN.1 type that could appear in aEvidenceStatement orAttestationResult, with references for where to find the full specification.¶

Registration requests should be formatted as perthe registration template below, and receive a three-week review period onthespasm mailing list, with the advice of one or more DesignatedExperts[RFC8126]. However, to allow for the allocation of valuesprior to publication, the Designated Experts may approve registrationonce they are satisfied that such a specification will be published.¶

Registration requests sent to the mailing list for review should usean appropriate subject (e.g., "Request to register attestationevidence: example").¶

IANA must only accept registry updates from the Designated Expertsand should direct all requests for registration to the review mailinglist.¶

9.1.Background Check Model Security Considerations

A PKCS#10 or CRMF certification request typically consists of adistinguished name, a public key, and optionally a set of attributes,collectively signed by the entity requesting certification.In general, because an Attestation Key is intended solely for signing Evidence, the private key used to sign a CSRSHOULD be distinct from theAttestation Key used to sign Evidence about the Target Environment. ExceptionsMAY be allowed when CSRs and Evidence are both part of the processof bootstrapping the Attestation Key.¶

To demonstrate that the privatekey applied to sign the CSR is generated, and stored in a secureenvironment that has controls to prevent theft or misuse (includingbeing non-exportable / non-recoverable), the Attesting Environmenthas to collect claims about this secure environment (or TargetEnvironment, as shown inFigure 16).¶

Figure 16 shows the interaction inside an Attester. TheAttesting Environment, which is provisioned with an Attestation Key,retrieves claims about the Target Environment. The TargetEnvironment offers key generation, storage and usage, which itmakes available to services. The Attesting Environment collectsthese claims about the Target Environment and signs them andexports Evidence for use in remote attestation via a CSR.¶

Figure 16 places the CSR library outside the Attester, whichis a valid architecture for certificate enrollment.The CSR library may also be locatedinside the trusted computing base. Regardless of the placementof the CSR library, an Attesting EnvironmentMUST be able to collectclaims about the Target Environment such that statements aboutthe storage of the keying material can be made.For the Verifier, the provided Evidence must allowan assessment to be made whether the key used to sign the CSRis stored in a secure location and cannot be exported.¶

Evidence communicated in the attributes and structures definedin this document are meant to be used in a CSR. It is up tothe Verifier and to the Relying Party (PKI RA/CA) to place as much oras little trust in this information as dictated by policies.¶

This document defines the transport of Evidence of different formatsin a CSR. Some of these encoding formats are based on standardswhile others are proprietary formats. A Verifier will need to understandthese formats for matching the received claim values against policies.¶

Policies drive the processing of Evidence at the Verifier: the Verifier'sAppraisal Policy for Evidence will often be based on specifications by the manufacturerof a hardware security module, a regulatory agency, or specified by anoversight body, such as the CA Browser Forum. The Code-Signing BaselineRequirements[CSBR] documentis an example of such a policy that hasbeen published by the CA Browser Forum and specifies certain properties,such as non-exportability, which must be enabled for storingpublicly-trusted code-signing keys. Otherpolicies influence the decision making at the Relying Party whenevaluating the Attestation Result. The Relying Party is ultimatelyresponsible for making a decision of what information in the AttestationResult it will accept. The presence of the attributes defined in thisspecification provide the Relying Party with additional assurance aboutan Attester. Policies used at the Verifier and the Relying Party areimplementation dependent and out of scope for this document. Whether torequire the use of Evidence in a CSR is out-of-scope for this document.¶

9.2.Freshness for the Background Check Model

Evidence generated by an Attester generally needs to be fresh in order to providevalue to the Verifier since the configuration on the device may changeover time.Section 10 of [RFC9334] discusses different approaches forproviding freshness, including a nonce-based approach, the use of timestampsand an epoch-based technique. The use of nonces requires that nonce to be provided bythe Relying Party in some protocol step prior to Evidence and CSR generation,and the use of timestamps requires synchronized clocks which cannot beguaranteed in all operating environments. Epochs also require an out-of-bandcommunication channel.This document leaves the exchange of nonces and other freshness data tocertificate management protocols, see[I-D.ietf-lamps-attestation-freshness].Developers, operators, and designers of protocols, which embedEvidence-carrying-CSRs,MUST consider what notion of freshness isappropriate and available in-context; thus the issue of freshness isleft up to the discretion of protocol designers and implementers.¶

In the case of hardware security modules (HSM), thesemantics of "freshness" are somewhat ambiguous in the contextof CSRs, especially considering that non-automated certificate enrollmentsare often asynchronous, and considering the common practice of re-using thesame CSR for multiple certificate renewals across the lifetime of a key."Freshness" typically implies both asserting that the data was generatedat a certain point-in-time, as well as providing non-replayability.Certain use cases may have special properties impacting the freshnessrequirements. For example, HSMs are typically designed to not allow downgradeof private key storage properties; for example if a given key was asserted attime T to have been generated inside the hardware boundary and to benon-exportable, then it can be assumed that those properties of that keywill continue to hold into the future.¶

Note: Freshness is also a concern for remote attestation in the passport model; however, the protocol between the Attester and the Verifier lies outside the scope of this specification.¶

9.3.Publishing Evidence in an X.509 Extension

This document specifies an Extension for carrying Evidence in a PKCS#10 or CRMF certificate signing request (CSR), but it is intentionallyNOT RECOMMENDED for a CA to copy the attr-evidence for PKCS#10 or ext-evidence extension for CRMF 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.¶

9.4.Type OID and Verifier Hint

TheEvidenceStatement includes both atype OID and ahint 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 thetype OID andhint will allow an RP to select between Verifier with which it has pre-established trust relationships. The RPMUST NOT blindly make network calls to unknown domain names and trust the results.Implementers should also be cautious aroundtype OID orhint values that cause a short-circuit in the verification logic, such asNone,Null, or similar values that could cause the Evidence to appear to be valid when in fact it was not properly checked.¶

9.5.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 remote attestation; many of these concepts are discussed inSection 6 of [RFC9334],Section 7 of [RFC9334],Section 9 of [RFC9334],Section 11 of [RFC9334], andSection 12 of [RFC9334]. Implementers should also be aware of any security considerations relating to the specific Evidence and Attestation Result formats being carried within the CSR.¶

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

[RFC3986]

Berners-Lee, T.,Fielding, R., andL. Masinter,"Uniform Resource Identifier (URI): Generic Syntax",STD 66,RFC 3986,DOI 10.17487/RFC3986,January 2005,<https://www.rfc-editor.org/rfc/rfc3986>.

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

[RFC5280]

Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, R., andW. Polk,"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile",RFC 5280,DOI 10.17487/RFC5280,May 2008,<https://www.rfc-editor.org/rfc/rfc5280>.

[RFC5911]

Hoffman, P. andJ. Schaad,"New ASN.1 Modules for Cryptographic Message Syntax (CMS) and S/MIME",RFC 5911,DOI 10.17487/RFC5911,June 2010,<https://www.rfc-editor.org/rfc/rfc5911>.

[RFC5912]

Hoffman, P. andJ. 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>.

[RFC6268]

Schaad, J. andS. Turner,"Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)",RFC 6268,DOI 10.17487/RFC6268,July 2011,<https://www.rfc-editor.org/rfc/rfc6268>.

[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., andW. Pan,"Remote ATtestation procedureS (RATS) Architecture",RFC 9334,DOI 10.17487/RFC9334,January 2023,<https://www.rfc-editor.org/rfc/rfc9334>.

10.2.Informative References

[CSBR]

CA/Browser Forum,"Baseline Requirements for Code-Signing Certificates, v.3.7",February 2024,<https://cabforum.org/uploads/Baseline-Requirements-for-the-Issuance-and-Management-of-Code-Signing.v3.7.pdf>.

[I-D.bft-rats-kat]

Brossard, M.,Fossati, T.,Tschofenig, H., andH. Birkholz,"An EAT-based Key Attestation Token",Work in Progress,Internet-Draft, draft-bft-rats-kat-05,21 November 2024,<https://datatracker.ietf.org/doc/html/draft-bft-rats-kat-05>.

[I-D.ffm-rats-cca-token]

Frost, S.,Fossati, T., andG. Mandyam,"Arm's Confidential Compute Architecture Reference Attestation Token",Work in Progress,Internet-Draft, draft-ffm-rats-cca-token-02,2 September 2025,<https://datatracker.ietf.org/doc/html/draft-ffm-rats-cca-token-02>.

[I-D.ietf-lamps-attestation-freshness]

Tschofenig, H. andH. Brockhaus,"Nonce-based Freshness for Remote Attestation in Certificate Signing Requests (CSRs) for the Certification Management Protocol (CMP) and for Enrollment over Secure Transport (EST)",Work in Progress,Internet-Draft, draft-ietf-lamps-attestation-freshness-04,7 July 2025,<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-attestation-freshness-04>.

[I-D.ietf-rats-ar4si]

Voit, E.,Birkholz, H.,Hardjono, T.,Fossati, T., andV. Scarlata,"Attestation Results for Secure Interactions",Work in Progress,Internet-Draft, draft-ietf-rats-ar4si-09,15 August 2025,<https://datatracker.ietf.org/doc/html/draft-ietf-rats-ar4si-09>.

[I-D.ietf-rats-daa]

Birkholz, H.,Newton, C.,Chen, L.,Giannetsos, T., andD. Thaler,"Direct Anonymous Attestation for the Remote Attestation Procedures Architecture",Work in Progress,Internet-Draft, draft-ietf-rats-daa-08,3 September 2025,<https://datatracker.ietf.org/doc/html/draft-ietf-rats-daa-08>.

[I-D.ietf-rats-endorsements]

Thaler, D.,Birkholz, H., andT. Fossati,"RATS Endorsements",Work in Progress,Internet-Draft, draft-ietf-rats-endorsements-07,25 August 2025,<https://datatracker.ietf.org/doc/html/draft-ietf-rats-endorsements-07>.

[I-D.ietf-rats-msg-wrap]

Birkholz, H.,Smith, N.,Fossati, T.,Tschofenig, H., andD. Glaze,"RATS Conceptual Messages Wrapper (CMW)",Work in Progress,Internet-Draft, draft-ietf-rats-msg-wrap-18,29 September 2025,<https://datatracker.ietf.org/doc/html/draft-ietf-rats-msg-wrap-18>.

[I-D.tschofenig-rats-psa-token]

Tschofenig, H.,Frost, S.,Brossard, M.,Shaw, A. L., andT. Fossati,"Arm's Platform Security Architecture (PSA) Attestation Token",Work in Progress,Internet-Draft, draft-tschofenig-rats-psa-token-24,23 September 2024,<https://datatracker.ietf.org/doc/html/draft-tschofenig-rats-psa-token-24>.

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

[RFC5226]

Narten, T. andH. Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs",RFC 5226,DOI 10.17487/RFC5226,May 2008,<https://www.rfc-editor.org/rfc/rfc5226>.

[RFC7030]

Pritikin, M., Ed.,Yee, P., Ed., andD. 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., andT. 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>.

[RFC9683]

Fedorkow, G. C., Ed.,Voit, E., andJ. Fitzgerald-McKay,"Remote Integrity Verification of Network Devices Containing Trusted Platform Modules",RFC 9683,DOI 10.17487/RFC9683,December 2024,<https://www.rfc-editor.org/rfc/rfc9683>.

[SampleData]

"CSR Attestation Sample Data",n.d.,<https://github.com/lamps-wg/csr-attestation-examples>.

[TCGDICE1.2]

Trusted Computing Group,"DICE Attestation Architecture",April 2025,<https://trustedcomputinggroup.org/wp-content/uploads/DICE-Attestation-Architecture-v1.2_pub.pdf>.

[TCGRegistry]

Trusted Computing Group,"TCG OID Registry",October 2024,<https://trustedcomputinggroup.org/resource/tcg-oid-registry/>.

A.1.Extending EvidenceStatementSet

As defined inSection 5.2, EvidenceStatementSet acts as a way to provide an ASN.1 compiler orruntime parser with a list of OBJECT IDENTIFIERs that are known to represent EvidenceStatements-- and are expected to appear in an EvidenceStatement.type field, along withthe 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 itwith 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 thereforedoes not specify any mandatory-to-implement Evidence types.¶

As an example of how to populate EvidenceStatementSet, implementing the CMW and PSA Evidence types would result in the following EvidenceStatementSet definition:¶

EvidenceStatementSet EVIDENCE-STATEMENT ::= {  --- ConceptualMessageWrapper  { CMW IDENTIFIED BY id-pe-cmw },  ...,  --- PSA  { OCTET STRING IDENTIFIED BY { 1 3 6 1 5 5 7 1 99 } }}

A.2.PSA Attestation Token in CSR

The Platform Security Architecture (PSA) Attestation Token isdefined in[I-D.tschofenig-rats-psa-token] and specifiesclaims to be included in an Entity AttestationToken (EAT).[I-D.bft-rats-kat] defines key attestationbased on the EAT format. In this section the platformattestation offered by[I-D.tschofenig-rats-psa-token]is combined with key attestation by binding thekey 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 toSection 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 theKAT/PAT example fromSection 6 of [I-D.bft-rats-kat] andthe 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'}

A.3.Confidential Compute Architecture (CCA) Platform Token in CSR

The Confidential Compute Architecture (CCA) Platform Token is described in[I-D.ffm-rats-cca-token] and is also based on the EAT format. Although thefull CCA attestation is composed of Realm and Platform Evidence, for the purposesof this example only the Platform token is provided.¶

EvidenceBundle   +   |   + Evidences   |   +---->  EvidenceStatement        +        |        +-> type: OID for CCA Platform Attestation Toekn        |         1 3 6 1 5 5 7 1 TBD        |        +-> stmt: CCA Platform Token

Although the CCA Platform Token follows the EAT/CMW format, it is untagged.This is because the encoding can be discerned in the CSR based on the OID alone.The untagged token based on a sample claim set is provided below:¶

(long lines wrapped for readability)/ Sample Platform Claims Set in CDDL                          /{   / cca-platform-profile / 265:"tag:arm.com,2023:cca_platform#1.0.0"   / arm-platform-challenge, SHA-256 calculation of ‘RAK’ / 10:            h'c9cdc457ebe981d563b19b5a8e0e3cbef5b944d58e278c9c6779f            77beb65bbd5’   / arm-platform-lifecycle / 2395: h'3000' /secured/   / arm-platform-sw-components / 2399: [ {1:"ROTFMC", 2:h'903a36d3a            0a511ecac4548fee8601af54247c110ce220f680a0b274441729105’,            5:h'd4cf61e472d18c8e926ce0d44496674792587c88706e8a123b294            c000895d9ea’},      {1:"ROTFW", 2:h'59d4116525e974b5b62ffd7c4ffcbaa0b98e08263403aeb            6638797132d2af959’, 5:h'd4cf61e472d18c8e926ce0d4449667479            2587c88706e8a123b294c000895d9ea’} ]   /arm-platform-id/ 256: h’ 946338159d767f9f37098a00a60f133b6d57886f            c656f5f9eed13760b4893fa1’   /arm-platform-implementation-id/ 2396: h’0000000000000000000000000            000000000000000000000000000000000000001’}/ This is a full CWT-formatted token. The payload is a sample/ Platform Claim Set. The main structure                       // visible is that of the COSE_Sign1.                          /61( 18( [    h'a10126',  / protected headers  /    {}, / empty unprotected headers /    h’a419010978237461673a61726d2e636f6d2c323032333a6363615f706c746    66f726d23312e392e300a580020c9cdc457ebe981d563b19b5a8e0e3cbef5b9    44d58e278c9c6779f77beb65bbd519095b42300019095f82a30166524f54464    d4302580020903a36d3a0a511ecac4548fee8601af54247c110ce220f680a0b    27444172910505580020d4cf61e472d18c8e926ce0d44496674792587c88706    e8a123b294c000895d9eaae0165524f5446575800200259d4116525e974b5b6    2ffd7c4ffcbaa0b98e08263403aeb6638797132d2af95905580020d4cf61e47    2d18c8e926ce0d44496674792587c88706e8a123b294c000895d9ea19010078    20946338159d767f9f37098a00a60f133b6d57886fc656f5f9eed13760b4893    fa11a095c582000000000000000000000000000000000000000000000000000    00000000000001' /payload/    h'cbbfa929cb9b846cb5527d7ef9b7657256412a5f22a6e1a8d3a0c71145022    100db4b1b97913b1cd9d6e11c1fadbc0869882ba6644b9db09d221f198e3286    654b' /signature/] ) )/Untagged serialized token/h'8443a10126a0590141a419010978237461673a61726d2e636f6d2c323032333a6363615f706c74666f726d23312e392e300a580020c9cdc457ebe981d563b19b5a8e0e3cbef5b944d58e278c9c6779f77beb65bbd519095b42300019095f82a30166524f54464d4302580020903a36d3a0a511ecac4548fee8601af54247c110ce220f680a0b27444172910505580020d4cf61e472d18c8e926ce0d44496674792587c88706e8a123b294c000895d9eaae0165524f5446575800200259d4116525e974b5b62ffd7c4ffcbaa0b98e08263403aeb6638797132d2af95905580020d4cf61e472d18c8e926ce0d44496674792587c88706e8a123b294c000895d9ea1901007820946338159d767f9f37098a00a60f133b6d57886fc656f5f9eed13760b4893fa11a095c582000000000000000000000000000000000000000000000000000000000000000015840cbbfa929cb9b846cb5527d7ef9b7657256412a5f22a6e1a8d3a0c71145022100db4b1b97913b1cd9d6e11c1fadbc0869882ba6644b9db09d221f198e3286654b'

Realm evidence can be included in a CMW bundle, similar to the PSA token.In this case, the CSR is constructed as follows:¶

EvidenceBundle   +   |   + Evidences   |   +---->  EvidenceStatement        +        |        +-> type: OID for CMW Collection        |         1 3 6 1 5 5 7 1 TBD        |        +-> stmt: Realm Token/Platform Token CMW Collection or                         Realm Claim Set/Platform Token CMW Collection

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

CsrAttestationDiceExample DEFINITIONS IMPLICIT TAGS ::= BEGINIMPORTStcg-dice-conceptual-message-wrapper FROM TcgDiceAttestationDiceConceptualMessageWrapper FROM TcgDiceAttestationtcg-dice-TcbInfo FROM TcgDiceAttestationDiceTcbInfo FROM TcgDiceAttestationEvidenceStatementSet 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.pdfEvidenceStatementSet EVIDENCE-STATEMENT ::= {  tcgDiceEvidenceStatementES,  tcgDiceTcbInfoEvidenceStatementES  ...}ENDTcgDiceAttestation DEFINITIONS AUTOMATIC TAGS ::= BEGINEXPORTS 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 IntegrityRegisterIntegrityRegister ::= 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 DiceTcbInfoDiceTcbInfoComp ::= SEQUENCE SIZE (1..MAX) OF TcbInfoCompTcbInfoComp ::= 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.2].¶

// SET of CSR AttributesA0 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        // 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: IA5String "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 onlya0 82 00 8c 30 82 00 88 06 0b 2a 86 48 86 f7 0d01 09 10 02 3b 30 79 31 77 30 75 30 73 30 71 0606 67 81 05 05 04 01 30 4e 82 0c 41 42 43 44 4546 31 32 33 34 35 36 83 01 04 a6 2f 30 2d 06 0960 86 48 01 65 03 04 02 01 04 20 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 88 04 00 00 0000 89 04 00 00 00 00 16 17 44 69 63 65 54 63 6249 6e 66 6f 2e 65 78 61 6d 70 6c 65 2e 63 6f 6d