PKIX Evidence for Remote Attestation of Hardware Security Modules

2.1. Remote audit of a Hardware Security Module (HSM)

There are situations where it is necessary to verify the current running state of an HSM as part of operational or auditing procedures. For example, there are devices that are certified to work in an environment only if certain versions of the firmware are loaded or only if user keys are protected with specific policies.¶

The Evidence format offered by this specification allows a platform to report its firmware level along with other collected claims necessary in critical deployments.¶

2.2. Key import and HSM clustering

Consider that an HSM is being added to a logical HSM cluster. Part of the onboarding process could involve the newly-added HSM providing proof of its running state, for example that it is a genuine device from the same manufacturer as the existing clustered HSMs, firmware patch level, FIPS mode, etc. It could also be required to provide attestation of any system-level keys required for secure establishment of cluster communication. In this scenario, the Verifier and Relying Party will be the other HSMs in the cluster deciding whether or not to admit the new HSM.¶

A related scenario is when performing a key export-import across HSMs. If the key is being imported with certain properties, for example an environment running in FIPS mode at FIPS Level 3, and the key is set to certain protection properties such as Non-Exportable and Dual-Control, then the HSM might wish to verify that the key was previously stored under the same properties. This specification provides an Evidence format with sufficient details to support this type of implementation across HSM vendors.¶

These scenarios motivate the design requirements to have an ASN.1 based Evidence format and a data model that more closely matches typical HSM architecture since, as shown in both scenarios, an HSM is acting as Verifier and Relying Party.¶

2.3. Attesting subject of a certificate issuance

Prior to a Certification Authority (CA) issuing a certificate on behalf of a subject, a number of procedures are required to verify that the subject of the certificate is associated with the key that is certified. In some cases, such as issuing a code signing certificate [CNSA2.0] [CSBR], a CA must ensure that the subject key is located in a Hardware Security Module (HSM).¶

The Evidence format offered by this specification is designed to carry the information necessary for a CA to assess the location of the subject key along a number of commonly-required attributes. More specifically, a CA could determine which HSM was used to generate the subject key, whether this device adheres to certain jurisdiction policies (such as FIPS mode) and the constraints applied to the key (such as whether is it extractable).¶

For relatively simple HSM devices, storage properties such as "extractable" may always be false for all keys since the devices are not capable of key export and so the attestation could be essentially a hard-coded template asserting these immutable attributes. However, more complex HSM devices require a more complex evidence format that encompasses the mutability of these attributes.¶

Also, a client requesting a key attestation might wish to scope-down the content of the produced Evidence as the HSM contains much more information than that which is relevant to the transaction. The inability to scope-down the generated Evidence could, in some scenarios, constitute a privacy violation.¶

3.1. Claims and measurements in PKIX Evidence

[RFC9334] states that Evidence is made up of claims and that a claim is "a piece of asserted information, often in the form of a name/value pair". The RATS Architecture also mentions the concept of "measurements" that "can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc., and how they are hardened."¶

Some HSMs have a large amount of memory and can therefore contain a substantial amount of elements that can be observed independently by the Attestation Service. Each of those elements, in turn, can contain a number of measurable attributes.¶

A certain level of complexity arises as multiple elements of the same class can be observed while generating Evidence. In that case, the "name" of the claim must also include the "address" of the element.¶

To that end, in this specification, the claims are organized as tuples of "entity", "attribute" and "value":¶

• the entity represents the encapsulation of an element as a set of attributes;¶

• the attribute represents one property of the entity, which can be repeated to other entities of the same class; and,¶

• the value is the actual measurement performed by the Attestation Service.¶

Therefore, each entity is a collection of claims, where the "name/value" pair represents one attribute and its measured value for an entity.¶

The grouping of claims into entities facilitates the comprehension of a large addressable space into elements recognizable by the user. More importantly, it curtails the produced Evidence to portions of the Target Environment that relate to the needs of the Verifier. See Section 10.4.¶

3.2. Attestation Key Certificate Chain

The data format in this specification represents PKIX evidence and requires third-party endorsement in order to establish trust. Part of this endorsement is a trust anchor that chains to the HSM's attestation key (AK) which signs the evidence. In practice the trust anchor will usually be a manufacturing CA belonging to the device vendor which proves that the device is genuine and not counterfeit. The trust anchor can also belong to the device operator as would be the case when the AK certificate is replaced as part of onboarding the device into a new operational network.¶

The AK certificate that signs the evidence MUST have the Extended Key Usage id-kp-attest, as defined in [I-D.jpfiset-lamps-attestationkey-eku], set.¶

Note that the data format specified in Section 5 allows for zero, one, or multiple 'SignatureBlock's, so a single evidence statement could be un-protected, or could be endorsed by multiple AK chains leading to different trust anchors. See Section 6 for a discussion of handling multiple SignatureBlocks.¶

4.1. Entity

An entity is a logical construct that refers to a portion of the Target Environment's state. It is addressable via an identifier such as a UUID or a handle (as expressed in [PKCS11]). In general, an entity refers to a component recognized by users of the HSM, such as a key or the platform itself.¶

An entity is composed of a type, the entity type, and a set of attributes. The entity type describes the class of the entity while its attributes define its state.¶

An entity MUST be reported at most once in a claim description. The claim description can have multiple entities of the same type (for example reporting multiple keys), but each entity MUST relate to different portions of the Target Environment.¶

It is possible for two entities to be quite similar such as in a situation where a key is imported twice in a HSM. In this case, the two related entities could have similar attributes. However, they are treated as different entities as they are addressed differently.¶

The number of entities reported in a claim description, and their respective type, is left to the implementer. For a simple device where there is only one key, the list of reported entities could be fixed. For larger and more complex devices, the list of reported entities should be tailored to the demands of the Presenter.¶

In particular, note that the nonce attribute contained with the Transaction entity is optional, and therefore it is possible that an extremely simple device that holds one static key could have its key attestation object generated at manufacture time and injected statically into the device and act as a kind of certificate, instead of being generated on-demand. This model would essentially off-board the Target Environment to be part of the manufacturing infrastructure.¶

4.2. Entity Type

An entity is defined by its type. This specification defines three entity types:¶

• Platform : This entity holds attributes relating to the state of the platform, or device, where the Attester is located. Entities of this type hold attributes that are global in nature within the Target Environment.¶

• Key : The entities of this type represent a cryptographic key protected within the Target Environment and hold attributes relating to that key.¶

• Transaction : This entity is logical in nature since it is associated with attributes that are not found in the Target Environment. The attributes found in this entity relate to the current request for Evidence such as a nonce to support freshness.¶

Although this document defines a short list of entity types, this list is extensible to allow implementers to report on entities found in their implementation and not covered by this specification. By using an Object Identifier (OID) for specifying entity types and attribute types, this format is inherently extensible; implementers of this specification MAY define new custom or proprietary entity types and place them alongside the standardized entities, or define new attribute types and place them inside standardized entities.¶

Verifiers SHOULD ignore and skip over unrecognized entity or attribute types and continue processing normally. In other words, if a given Evidence would have been acceptable without the unrecognized entities or attributes, then it SHOULD still be acceptable with them.¶

4.3. Attribute and Attribute Type

Each attribute found in an entity is composed of the attribute type and value. Each attribute describes a portion of the state of the associated entity. For example, a platform entity could have an attribute which indicates the firmware version currently running. Another example is a key entity with an attribute that reports whether the key is extractable or not.¶

A value provided by an attribute is to be interpreted within the context of its entity and in relation to the attribute type.¶

It is RECOMMENDED that an attribute type be defined for a specific entity type, to reduce confusion when it comes to interpretation of the value. In other words, an attribute type SHOULD NOT be used by multiple entity types. For example, if a concept of "revision" is applicable to a platform and a key, the attribute for one entity type (platform revision) should have a different identifier than the one for the other entity type (key revision).¶

The nature of the value (boolean, integer, string, bytes) is dependent on the attribute type.¶

This specification defines a limited set of attribute types. However, the list is extensible through the IANA registration process or private OID allocation, enabling implementers to report additional attributes not covered by this specification.¶

The number of attributes reported within an entity, and their respective type, is left to the implementer. For a simple device, the reported list of attributes for an entity might be fixed. However, for larger and more complex devices, the list of reported attributes should be tailored to the demands of the Presenter.¶

Some attributes MAY be repeated within an entity while others MUST NOT. For example, for a platform entity, there can only be one "firmware version" attribute. Therefore, the associated attribute MUST NOT be repeated as it may lead to confusion. However, an attribute relating to a "ak-spki" MAY be repeated, each attribute describing a different attesting key. Therefore, the definition of an attribute specifies whether or not multiple copies of that attribute are allowed.¶

If a Verifier encounters, within a single entity, multiple copies of an attribute specified as "Multiple Allowed: No", it MUST reject the evidence as malformed.¶

If a Verifier encounters, within the context of an entity, a repeated attribute for a type where multiple attributes are allowed, it MUST treat each one as an independent attribute and MUST NOT consider later ones to overwrite the previous one.¶

5.1. Platform Entity

A platform entity reports information about the device where the Evidence is generated and is composed of a set of attributes that are global to the Target Environment. It is associated with the type identifier id-pkix-evidence-entity-platform.¶

A platform entity, if provided, MUST be included only once within the reported entities. If a Verifier encounters multiple entities of type id-pkix-evidence-entity-platform, it MUST reject the Evidence as malformed.¶

The following table lists the attributes for a platform entity (platform attributes) defined within this specification. In cases where the attribute is borrowed from another specification, the "Reference" column refers to the specification where the semantics for the attribute value can be found. Attributes defined in this specification have further details below.¶

Each attribute defined in the table above is described in the following sub-sections.¶

5.2. Key Entity

A key entity is associated with the type id-pkix-evidence-entity-key. Each instance of a key entity represents a different addressable key found in the Target Environment. There can be multiple key entities found in a claim description, but each reported key entity MUST describe a different key. Two key entities may represent the same underlying cryptographic key (keys with the exact same value) but they must be different portions of the Target Environment's state.¶

A key entity is composed of a set of attributes relating to the cryptographic key. At minimum, a key entity MUST report the attribute "identifier" to uniquely identify this cryptographic key from any others found in the same Target Environment.¶

A Verifier that encounters a claim description with multiple key entities referring to the same addressable key MUST reject the Evidence.¶

The following table lists the attributes for a key entity defined within this specification. The "Reference" column refers to the specification where the semantics for the attribute value can be found.¶

An attestation key might be visible to a client of the device and be reported along with other cryptographic keys. Therefore, it is acceptable to include a key entity providing claims about an attestation key like any other cryptographic key. An implementation MAY reject the generation of PKIX Evidence if it relates to an attestation key.¶

<CODE STARTS>

PkixEvidenceKeyCapabilities ::= SEQUENCE OF OBJECT IDENTIFIER

<CODE ENDS>

5.3. Transaction Entity

A transaction entity is associated with the type id-pkix-evidence-entity-transaction. This is a logical entity and does not relate to an element found in the Target Environment. Instead, it groups together attributes that relate to the request of generating the Evidence.¶

For example, it is possible to include a "nonce" as part of the request to produce Evidence. This nonce is repeated as part of the Evidence to prove the freshness of the claims. This "nonce" is not related to any element in the Target Environment and the transaction entity is used to gather those values into attributes.¶

A transaction entity, if provided, MUST be included only once within the reported entities. If a Verifier encounters multiple entities of type id-pkix-evidence-entity-transaction, it MUST reject the Evidence.¶

The following table lists the attributes for a transaction entity defined within this specification. The "Reference" column refers to the specification where the semantics for the attribute value can be found.¶

5.4. Additional Entity and Attribute Types

It is expected that HSM vendors will register additional Entity and Attribute types by assigning OIDs from their own proprietary OID arcs to hold data describing additional proprietary key properties.¶

When new entity and attribute types are used, documentation similar to the one produced in this specification SHOULD be distributed to explain the meaning of the types and the frequency that values can be provided.¶

See Section 7.3, Section 7.4 and Section 10.1 for handling of unrecognized custom types.¶

5.5. Encoding

A PkixEvidence is to be DER encoded [X.690].¶

If a textual representation is required, then the DER encoding MAY be subsequently encoded into Standard Base64 as defined in [RFC4648].¶

PEM-like representations are also allowed where a MIME-compliant Base64 transformation of the DER encoding is used, provided that the header label is "EVIDENCE". For example:¶

-----BEGIN EVIDENCE-----
(...)
-----END EVIDENCE-----

7.1. Request Attributes with Specified Values

This section deals with the request attributes specified in this document where a value should be provided by a Presenter. In other words, this section defines all request attributes that should set in the structure ReportedAttribute. Request attributes not covered in this sub-section should not have a specified value (left empty).¶

Since this section is non-normative, implementers may deviate from those recommendations.¶

7.2. Reporting of Attestation Keys

There is a provision for the Attester to report the Attestation Key(s) used during the generation of the evidence. To this end, the transaction attribute "ak-spki" is used.¶

A Presenter invokes this provision by submitting an attestation request with a transaction attribute of type "ak-spki" with a non-specified value (left empty).¶

In this case, the Attester adds a transaction attribute of type "ak-spki" for each Attestation Key used to sign the evidence. The value of this attribute is an octet string (bytes) which is the encoding of the Subject Public Key Information (SPKI) associated with the Attestation Key. Details on SPKIs and their encoding can be found in X.509 certificates ([RFC5280]).¶

This reporting effectively binds the signature blocks to the content (see Section 10.3).¶

7.3. Processing an Attestation Request

This sub-section deals with the rules that should be considered when an Attester (the HSM) processes a request to generate Evidence. This section is non-normative and implementers MAY choose to not follow these recommendations.¶

These recommendations apply to any attestation request schemes and are not restricted solely to the request interface proposed here.¶

An Attester SHOULD fail an attestation request if it contains an unrecognized entity type. This is to ensure that all the semantics expected by the Presenter are fully understood by the Attester.¶

An Attester MUST fail an attestation request if it contains a request attribute of an unrecognized type with a specified a value (not empty). This represents a situation where the Presenter is selecting specific information that is not understood by the Attester.¶

An Attester SHOULD ignore unrecognized attribute types in an attestation request. In this situation, the Attester SHOULD NOT include the attribute as part of the response. This guidance is to increase the likelihood of interoperability between tools of various vendors.¶

An Attester MUST NOT include entities and attributes in the generated evidence if these entities and attributes were not specified as part of the request. This is to give the Presenter the control on what information is disclosed by the Attester.¶

An Attester MUST fail an attestation request if the Presenter does not have the appropriate access rights to the entities included in the request.¶

7.4. Verification by Presenter

This sub-section deals with the rules that should be considered when a Presenter receives PKIX evidence from the Attester (the HSM) prior to distribution. This section is non-normative and implementers MAY choose to not follow these recommendations.¶

These recommendations apply to any PKIX evidence and are not restricted solely to evidence generated from the proposed request interface.¶

A Presenter MUST review the evidence produced by an Attester for fitness prior to distribution.¶

A Presenter MUST NOT disclose evidence if it contains information it cannot parse. This restriction applies to entity types and attributes type. This is to ensure that the information provided by the Attester can be evaluated by the Presenter.¶

A Presenter MUST NOT disclose evidence if it contains entities others than the ones that were requested of the Attester. This is to ensure that only the selected entities are exposed to the Verifier.¶

A Presenter MUST NOT disclose evidence if it contains an entity with an attribute that was not requested of the Attester. This is to ensure that only the selected information is disclosed to the Verifier.¶

Further privacy concerns are discussed in Section 10.4.¶

10.1. Policies relating to Verifier and Relying Party

The generation of PKIX evidence by an HSM is to provide sufficient information to a Verifier and a Relying Party to appraise the Target Environment (the HSM) and make decisions based on this appraisal.¶

The Appraisal Policy associated with the Verifier influences the generation of the Attestation Results. Those results, in turn, are consumed by the Relying Party to make decisions about the HSM, which might be based on a set of rules and policies. Therefore, the interpretation of PKIX evidence may greatly influence the outcome of some decisions.¶

A Verifier MAY reject a PKIX evidence if it lacks required attributes per the Verifier's appraisal policy. For example, if a Relying Party mandates a FIPS-certified device, it SHOULD reject evidence lacking sufficient information to verify the device's FIPS certification status.¶

If a Verifier encounters an attribute with an unrecognized attribute type, it MAY ignore it and treat it as extraneous information. By ignoring an attribute, the Verifier may accept PKIX evidence that would be deemed malformed to a Verifier with different policies. However, this approach fosters a higher likelihood of achieving interoperability.¶

10.2. Simple to Implement

The nature of attestation requires the Attestation Service to be implemented in an extremely privileged position within the HSM so that it can collect measurements of both the hardware environment and the user keys being attested. For many HSM architectures, this will place the Attestation Service inside the "security kernel" and potentially subject to FIPS 140-3 or Common Criteria validation and change control. For both security and compliance reasons there is incentive for the generation and parsing logic to be simple and easy to implement correctly. Additionally, when the data formats contained in this specification are parsed within an HSM boundary -- that would be parsing a request entity, or parsing an attestation produced by a different HSM -- implementers SHOULD opt for simple logic that rejects any data that does not match the expected format, instead of attempting to be flexible.¶

In particular, the Attestation Service SHOULD generate the PKIX evidence from scratch and avoid copying any content from the request. The Attestation Service MUST generate PKIX evidence only from attributes and values that are observed by the service.¶

10.3. Detached Signatures

The construction of the evidence structure (PkixEvidence) includes a collection of signature blocks that are not explicitly bound to the content. This approach was influenced by the following motivations:¶

• Multiple simultaneous signature blocks are desired to support hybrid environments where multiple keys using different cryptographic algorithms are required to support appraisal policies.¶

• Provide the ability to add counter-signatures without having to define an envelop scheme.¶

The concept of counter-signatures is important for environments where a number of heterogeneous devices are deployed. In those environments, it is possible for a trusted actor, intermediary between the Attester and the Verifier, to validate the original signature(s) and apply its own afterwards.¶

The ability to add signature blocks to the evidence after the original generation by the Attester leads to the unfortunate situation where signature blocks can also be removed without leaving any trace. Therefore, the signature blocks can be deemed as "detachable" or "stapled".¶

Manipulation of the evidence after it was generated can lead to undesired outcomes at the Verifier.¶

Therefore, Verifiers MUST be designed to accept evidence based on their appraisal policies, regardless of the presence or absence of certain signature(s). Consequently, Verifiers MUST NOT make any inferences based on a missing signature, as the signature could have been removed in transit.¶

This specification provides the transaction attribute "ak-spki" to effectively bind the content with the signature blocks that were generated by the Attester. When this attribute is provided, it reports the SPKI of one of the attestation keys used by the Attester to produce the evidence. This attribute is repeated for each of the attestation keys used by the Attester.¶

10.4. Privacy

Some HSMs have the capacity of supporting cryptographic keys controlled by separate entities referred to as "tenants", and when the HSM is used in that mode it is referred to as a multi-tenant configuration.¶

For example, an enterprise-grade HSM in a large multi-tenant cloud service could host TLS keys fronting multiple un-related web domains. Providing evidence for attesting attributes of any one of the keys would involve a Presenter that could potentially access any of the hosted keys. In such a case, privacy violations could occur if the Presenter was to disclose information that does not relate to the subject key.¶

Implementers SHOULD be careful to avoid over-disclosure of information, for example by authenticating the Presenter as described in Section 10.5 and only returning results for keys and environments for which it is authorized. In absence of an existing mechanism for authenticating and authorizing administrative connections to the HSM, the attestation request MAY be authenticated by embedding the TbsPkixEvidence of the request inside a PkixEvidence signed with a certificate belonging to the Presenter.¶

Furthermore, enterprise and cloud-services grade HSMs SHOULD support the full set of attestation request functionality described in Section 7 so that Presenters can fine-tune the content of a PKIX evidence such that it is appropriate for the intended Verifier.¶

10.5. Authenticating and Authorizing the Presenter

The Presenter represents a privileged role within the architecture of this specification as it gets to learn about the existence of user keys and their protection properties, as well as details of the platform. The Presenter is in the position of deciding how much information to disclose to the Verifier, and to request a suitably redacted evidence from the HSM.¶

For personal cryptographic tokens it might be appropriate for the attestation request interface to be un-authenticated. However, for enterprise and cloud-services grade HSMs the Presenter SHOULD be authenticated using the HSM's native authentication mechanism. The details are HSM-specific and are thus left up to the implementer. However, it is RECOMMENDED to implement an authorization framework similar to the following.¶

A Presenter SHOULD be allowed to request evidence for any user keys which it is allowed to use. For example, a TLS application that is correctly authenticated to the HSM in order to use its TLS keys SHOULD be able to request evidence of those same keys without needing to perform any additional authentication or requiring any additional roles or permissions. HSMs that wish to allow a Presenter to request evidence of keys which is not allowed to use, for example for the purposes of displaying HSM status information on an administrative console or UI, SHOULD have a "Attestation Requester" role or permission and SHOULD enforce the HSM's native access controls such that the Presenter can only retrieve evidence for keys for which it has read access.¶

In the absence of an existing mechanism for authenticating and authorizing administrative connections to the HSM, the attestation request MAY be authenticated by embedding the TbsPkixEvidence of the request inside a PkixEvidence signed with a certificate belonging to the Presenter.¶

10.6. Proof-of-Possession of User Keys

With asymmetric keys within a Public Key Infrastructure (PKI) it is common to require a key holder to prove that they are in control of the private key by using it. This is called "proof-of-possession (PoP)". This specification intentionally does not provide a mechanism for PoP of user keys and relies on the Presenter, Verifier, and Relying Party trusting the Attester to correctly report the cryptographic keys that it is holding.¶

It would be trivial to add a PoP Key Attribute that uses the attested user key to sign over, for example, the Transaction Entity. However, this approach leads to undesired consequences, as explained below.¶

First, a user key intended for TLS, as an example, SHOULD only be used with the TLS protocol. Introducing a signature oracle whereby the TLS application key is used to sign PKIX evidence could lead to cross-protocol attacks. In this example, an attacker could submit a "nonce" value which is in fact not random but is crafted in such a way as to appear as a valid message in some other protocol context or exploit some other weakness in the signature algorithm.¶

Second, the Presenter who has connected to the HSM to request PKIX evidence may have permissions to view the requested application keys but not permission to use them, as in the case where the Presenter is an administrative UI displaying HSM status information to an systems administrator or auditor.¶

Requiring the Attestation Service to use the attested application keys could, in some architectures, require the Attestation Service to resolve complex access control logic and handle complex error conditions for each requested key, which violates the "simple to implement" design principle outlined in Section 10.2. More discussion of authenticating the Presenter can be found in Section 10.5.¶

10.7. Timestamps and HSMs

It is common for HSMs to have an inaccurate system clock. Most clocks have a natural drift and must be corrected periodically. HSMs, like any other devices, are subject to these issues.¶

There are many situations where HSMs can not naturally correct their internal system clocks. For example, consider a HSM hosting a trust anchor and usually kept offline and booted up infrequently in a network without a reliable time management service. Another example is a smart card which boots up only when held against an NFC reader.¶

When a timestamp generated from a HSM is evaluated, the expected behavior of the system clock SHOULD be considered.¶

More specifically, the timestamp SHOULD NOT be relied on for establishing the freshness of the evidence generated by a HSM. Instead, Verifiers SHOULD rely on other provisions such as the "nonce" attribute of the "transaction" entity, introduced this specification.¶

Furthermore, the internal system clock of HSMs SHOULD NOT be relied on to enforce expiration policies.¶

11.1. Normative References

[FIPS140-3]

NIST, Information Technology Laboratory, "Security Requirements for Cryptographic Modules", FIPS 140-3, n.d., <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf>.

[I-D.jpfiset-lamps-attestationkey-eku]

Fiset, J., Ounsworth, M., Tschofenig, H., and M. Wiseman, "Extended Key Usage (EKU) for X.509 Certificates associated with Attestation Keys", Work in Progress, Internet-Draft, draft-jpfiset-lamps-attestationkey-eku-00, 5 August 2025, <https://datatracker.ietf.org/doc/html/draft-jpfiset-lamps-attestationkey-eku-00>.

[PKCS11]

Bong, D., Cox, T., and OASIS PKCS 11 TC, "PKCS #11 Specification Version 3.1", 11 August 2022, <https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/cs01/pkcs11-spec-v3.1-cs01.html>.

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

[RFC4648]

Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. 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>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

[RFC9711]

Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, <https://www.rfc-editor.org/rfc/rfc9711>.

[X.690]

ITU-T, "Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.690>.

[X680]

ITU-T, "Information technology — ASN.1: Specification of basic notation", n.d., <https://www.itu.int/rec/T-REC-X.680>.

[X690]

ITU-T, "Information technology — ASN.1 encoding rules: BER, CER, DER", n.d., <https://www.itu.int/rec/T-REC-X.690>.

11.2. Informative References

[CNSA2.0]

National Security Agency, "Commercial National Security Algorithm Suite 2.0", n.d., <https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF>.

[CSBR]

CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates Version 3.8.0", n.d., <https://cabforum.org/working-groups/code-signing/documents/>.

[I-D.fossati-tls-attestation]

Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-09, 30 April 2025, <https://datatracker.ietf.org/doc/html/draft-fossati-tls-attestation-09>.

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

Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-21, 5 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-21>.

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

Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. 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>.

[RFC2986]

Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/rfc/rfc2986>.

[RFC4211]

Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, <https://www.rfc-editor.org/rfc/rfc4211>.

[RFC6024]

Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <https://www.rfc-editor.org/rfc/rfc6024>.

[RFC9019]

Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A Firmware Update Architecture for Internet of Things", RFC 9019, DOI 10.17487/RFC9019, April 2021, <https://www.rfc-editor.org/rfc/rfc9019>.