PKIX Key Attestation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 September 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

This specification is targeted at attesting to the storage of cryptographic key material -- symmetric keys or asymmetric private keys -- within a hardware cryptographic module such as a Hardware Security Module (HSM) or Trusted Platform Module (TPM). HSMs and TPMs are devices whose primary purpose is to hold cryptographic keys and support interfaces whereby they can be used to perform encrypt, decrypt, sign, MAC and other keyed cryptographic operations on provided data without the key material ever leaving the hardware module. Typically an HSM or TPM holds an uses cryptographic keys on behalf of an application such as a Certification Authority, a code signing service, a TLS server. However, also included in the scope of this draft are single-purpose cryptographic devices such as smartcards which may hold only a single application key for a single purpose such as authenticating to a near-field "tap" terminal. Within this specification we will generically refer to the attesting device as an "HSM", and to the cryptographic keys that it holds an operates on behalf of some other application as "application keys".¶

The goal of this specification is to provide a standardized format in which an HSM can attest that one or more application keys are contained within a hardware module, and attest to any additional attributes relating to the protection of this key material.¶

This requires providing evidence to the key protection properties of that key, referred to in this specification as "key attributes", as well as to the operational state of the hardware platform, referred to as "platform attributes". This specification also provides a format for requesting that a cryptographic module produce a key attestation about a specific application key, the application keys in a specific sub-environment of the HSM, or that the returned attestation contain a specific set of attributes. See Section 4 for the full information model.¶

As described below in Section 3 "Architecture and Conceptual Model", this specification uses a simplification of the Remote ATtestation procedureS (RATS) Architecture [RFC9334] by assuming that the attesting environment and the target environment are the same environment, and that this environment only produces evidence as this aligns with the target hardware platforms. As such, the attestation data format specified in Section 4 only contains evidence (referred to in this document as "attributes") and does not provide for any form of endorsement except for endorsement of the device's attestation signing key which is endorsed via an X.509 certificate chain rooted in a trust anchor belonging either to the device manufacturer or to the device operator, as described in Section 3.1.¶

Unlike other attestation data formats defined by the RATS working group, the format defined in this document is targeting devices designed to operate within Public Key Infrastructure (PKI) ecosystems; this motivates the following design choices:¶

• Attestation data structure defined in ASN.1 [X.680] and encoded in Distinguished Encoding Rules (DER) [X.690].¶

• Endorsement of attesting key uses an X.509 certificate chain [RFC5280].¶

• Key attributes are mostly just a mapping of the private key properties from PKCS#11 [PKCS11].¶

For these reasons, this attestation format is called "PKIX Key Attestation" and may be used, for example within a Certificate Signing Request (CSR) object; [I-D.ietf-lamps-csr-attestation] specifies how to carry evidence within PKCS#10 [RFC2986] or Certificate Request Message Format (CRMF) [RFC4211].¶

This document provides a vendor-agnostic format for attesting to the logical and physical protection properties of a cryptographic key and it envisions uses such as providing evidence to a Certification Authority that a key is being protected in accordance with the requested certificate profile, or that HSMs can perform key import and maintain the private key protection properties in a robust way even when migrating keys across HSMs from different vendors.¶

2. Terminology

The reader is assumed to be familiar with the vocabulary and concepts defined in [RFC9334].¶

The following terms are used in this document:¶

Root of Trust (RoT):

A set of software and/or hardware components that need to be trusted to act as a security foundation required for accomplishing the security goals of a system. In our case, the RoT is expected to offer the functionality for attesting to the state of the platform, and to attest the properties of the application key. More precisely, it has to attest the integrity of the application key (public as well as private key) and the confidentiality of the private part of the application key. This document makes a simplifying assumption that the RoT, the attesting environment holding the attestation key, and the target environment being measured and attested are all the same environment.¶

Attestation Key (AK):

Cryptographic key belonging to the RoT that is only used to sign attestation tokens.¶

Hardware Security Module (HSM):

a physical computing device that safeguards and manages secrets (most importantly cryptographic keys), and performs encryption, decryption, signing, MACing and other cryptographic operations with the managed cryptographic keys. HSMs can sometimes host user applications within a secure enclave environment within the HSM that are often used to extend the cryptographic functionality of the HSM. This specification takes a broad definition of what counts as an HSM to include smartcards, USB tokens, and similar devices which this specification refers to as "personal cryptographic tokens", as well as TPMs, in addition to the usual PCI card, rack-mount, and blade server form-factor of HSM which this specification refers to as "enterprise-grade" or "cloud-service grade" HSMs.¶

Key Attestation:

Evidence containing properties of the environment(s) in which the private keys are generated and stored. For example, a Relying Party may want to know whether a private key is stored in a hardware security module and cannot be exported in cleartext.¶

Usage Protocol:

A (security) protocol that requires demonstrating possession of the private component of the application key.¶

Attestation Token (AT):

A collection of claims that a RoT assembles (and signs) with the purpose of informing - in a verifiable way - relying parties about the identity and state of the platform. Essentially a type of Evidence as per the RATS architecture terminology [RFC9334].¶

Platform Attestation Entity:

An Entity containing attributes relating to the security state of the platform,. The process of generating a platform entity typically involves gathering data during measured boot.¶

Key Attestation Entity:

An Entity containing attributes relating to a specific application key protected by the HSM. The key attestation service is part of the root of trust (RoT).¶

Application Key:

The application key consists of a private and a public key. The private key is used by the usage protocol. The public key is included in the Key Attestation Token. The Key Attestation Entity makes claims about the protection of this key.¶

Trust Anchor:

As defined in [RFC6024] and [RFC9019], a Trust Anchor "represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The Trust Anchor may be a certificate, a raw public key, or other structure, as appropriate. It can be a non-root certificate when it is a certificate.¶

Presenter:

Party that proves possession of a private key to a recipient of a key attestation token. Typically this will be an application layer entity, such as a cryptographiclibrary constructing a Certificate Signing Request that must embed attestation evidence, or a TLS library attempting to perform attested TLS. The Presenter is not fulfilling any roles in the RATS architecture.¶

Recipient:

Party that receives the attestation evidence containing the proof-of-possession key information from the presenter. The Recipient is likely fulfilling the roles of Verifier and Relying Party in the RATS architecture, but the exact details of this arrangement is out-of-scope for this specification.¶

Key Attestation Service (KAS):

The module within the HSM that is responsible for parsing the PKIX Attestation Request, measuring the Platform and the Key attributes, constructing the PKIX Attestation object, and signing it with the AK. The KAS fulfills the role of Attester in the RATS architecture. Note that real HSMs may or may not implement the Attester as a single internal module, but this abstraction is used for the design and security analysis of this specification.¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Architecture and Conceptual Model

Key attestation is an extension to the attestation functionality described in [RFC9334]. In the general RATS Architecture, an attesting device consists of a hardware Root of Trust (RoT) which provides the basis for trust in the device, and then one or more layers of attestations where an attesting environment collects and signs measurements (evidence) about a target environment. Trust is established by chaining the cryptographic signatures on each layer of evidence up to the next layer of attester until the RoT is reached, and trust is established in the RoT via 3rd party endorsements. The target devices for this specification tend to operate on a different architecture and trust model: the devices consist of one single logical environment (combining the RATS roles of RoT, attesting environment, and target environment together into a single entity), and trust is established via product validations conducted by third-party testing labs against standardized security and functional requirements such as FIPS 140-3 or a given Common Criteria protection profile. A FIPS or CC certification provided by a testing lab would conceptually count as an endorsement of the hardware platform in the RATS architecture, but they are often not digitally-signed artifacts, and are often conveyed out of band, sometimes via a website or even via a paper certificate and so they are out of scope for the wire format specified in this document.¶

As such, the attestation data format defined in this document does not capture the full functionality of the RATS architecture. If a device producing evidence in the specified format requires to also carry nested attestation statements or endorsements, then it must be achieved by placing the attestation from this draft within another wrapper layer such as RATS Conceptual Message Wrapper (CMW) [I-D.ietf-rats-msg-wrap].¶

Figure 1 depicts a typical workflow where an external tool queries the HSM for the status of one or more cryptographic keys that it is protecting ("Application Keys"). The "Presenter" may be, for example, a command-line or graphical user interface which will display the evidence to an operator or auditor; a cryptographic library which will include the evidence in a CSR for transmission to a Certification Authority; a TLS library which will include the evidence in at attested TLS session [I-D.fossati-tls-attestation]; or similar applications, refered to as the "Usage Protocol".¶

This model does not assume any internal structure or logical separation within the HSM except for the existence of some kind of attestation service which may or may not be logically separate from the overall HSM Root of Trust, and that this attestation service measures the required evidence about both the hardware environment and the application keys that are being attested. In addition to emitting key attestation evidence, an HSM may also need to parse it, for example when running in an operational mode that only allows importing keys from other HSMs at a comparable security level (requires checking for specific claims) or within the same operational network (requires checking the trust anchor of the attestation key certificate chain). This implies that the attestation service needs to be part of the core HSM "kernel" and therefore would be subject to validations such as FIPS 140-3 or Common Criteria, which motivates a design requirement to keep the evidence data format as simple as possible and as close as possible to existing functionality and data models of existing HSM and TPM products. As such, the information model presented in Section 4 will feel familiar to implementers with experience with PKI and PKCS#11.¶

4. Information Model

This section describes the semantics of the key claims as part of the information model.¶

The envelop structure is:¶

PkixAttestation ::= SEQUENCE {
    tbs TbsPkixAttestation,
    signatures SEQUENCE SIZE (0..MAX) of SignatureBlock
}

TbsPkixAttestation ::= SEQUENCE {
    version INTEGER,
    reportedEntities SEQUENCE SIZE (1..MAX) OF ReportedEntity
}

SignatureBlock ::= SEQUENCE {
   certChain SEQUENCE of Certificate,
   signatureAlgorithm AlgorithmIdentifier,
   signatureValue OCTET STRING
}

A PkixAttestation message is composed of a protected section known as the To-Be-Signed or TBS. The integrity of the To-Be-Signed section is ensured with one or multiple cryptographic signatures over the content of the section. There is a provision to carry the X.509 certificates supporting the signature(s).¶

The TBS section is composed of a version number, to ensure future extensibility, and a sequence of reported entities.¶

For compliance with this specification, TbsPkixAttestation.version MUST be 1. This envelope format is not extensible; future specifications which make compatibility-breaking changes MUST increment the version number.¶

EDNOTE: do we want extension marks on the TbsAttestation object? I can see pros and cons to doing that.¶

SignatureBlock.certChain MUST contain at least one X.509 certificate as per [RFC5280]. While there might exist attesting environments which use out-of-band or non-X.509 mechanisms for communicating the AK public key to the Verifier, these SHALL be considered non-compliant with this specification.¶

The attribute format is intended to be generic, flexible, and extensible with a default set of attributes defined in this document. Attributes are grouped into entities; an entity can be either a key, a platform, or a request containing a set of claims that are requested to be filled by the attesting environment.¶

ReportedEntity ::= SEQUENCE {
    entityType         OBJECT IDENTIFIER,
    reportedAttributes SEQUENCE SIZE (1..MAX) OF ReportedAttribute
}

A reported entity is a unit of observation measured by the Attester (the HSM). In this specification, there are three types of entities defined: - Platform Entity : An entity that reports attributes about the platform, itself. A PKIX Attestation MAY contain only one Platform Entity. - Key Entity : An entity that represents a single cryptographic key found in a HSM ad its associated attributes. A PKIX Attestation MAY contain one or more Key Entities. - Transaction Entity : An entity reporting attributes observed from the request itself. A PKIX Attestation MAY contain only one Transaction Entity.¶

A reported entity is composed of an Object Identifier (OID), specifying the entity type, and a sequence of reported attributes associated with the entity.¶

Although this specification defines only three types of entities, implementations MAY define additional entity types by registering additional OIDs.¶

An Attester (HSM) which is requested to provide information about unrecognized entity types MUST fail the operation.¶

A Verifier which encounters an unrecognized entity type MAY ignore it.¶

id-pkix-attest                    OBJECT IDENTIFIER ::= { 1 2 3 999 }
id-pkix-attest-entity-type        OBJECT IDENTIFIER ::= { id-pkix-attest 0 }
id-pkix-attest-entity-transaction OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 0 }
id-pkix-attest-entity-platform    OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 1 }
id-pkix-attest-entity-key         OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 2 }
id-pkix-attest-entity-request     OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 3 }

TODO: do we need entity types for "platform policy" and "key policy" ?¶

A PKIX Attestation MUST NOT contain more than one platform entity since duplicate and conflicting platform claims across multiple platform entities can easily lead to security bugs. A parser MUST fail with an error if it encouters multiple platform entities.¶

A PKIX Attestation MUST NOT contain more than one transaction entity. A transaction entity contains attributes that are related to the request such as a "nonce". A parser MUST fail with an error if it encouters multiple transaction entities.¶

A PKIX Attestation MAY contain one or more application key entities. Each key entity SHOULD describe a unique application key. Multiple ReportedEntity objects of type entity-key that describe the same application key SHOULD be avoided since different or conflicting claims could lead to security issues on the part of the Verifier or Relying Party.¶

TODO: note that we need to be careful about whether it is allowed to include the AK(s) and other "platform-owned" keys in the set of keys you can attest, or only attesting application keys.¶

Each reported attribute is composed of an Object Identifier (OID), identifying the type of the attribute, and a value which must be one of the prescribed data types.¶

ReportedAttribute ::= SEQUENCE {
    attributeType      OBJECT IDENTIFIER,
    value              OPTIONAL AttributeValue
}

AttributeValue :== CHOICE {
   bytes       [0] IMPLICIT OCTET STRING
   utf8String  [1] IMPLICIT UTF8String,
   bool        [2] IMPLICIT BOOLEAN,
   time        [3] IMPLICIT GeneralizedTime,
   int         [4] IMPLICIT INTEGER,
   oid         [5] IMPLICIT OBJECT IDENTIFIER
}

An attribute type is generally associated with a single entity type. In the following sub-sections, defined attributes are grouped according to their related entity types.¶

There are circumstances where an attribute type can be repeated for a given entity while other attribute types are unique. For example, the hwmodel, uptime, and fipsboot attributes are not allowed to have multiple instances since these are global measurements of the platform. However, other attribute types such as usermods allow multiple instances as an HSM can have more than one user module loaded. The tables below list for each attribute type whether multiples are allowed. For attribute types that do not allow multiples, a parser MUST fail with an error if it encouters multiple instances. For attribute types that allow multiples, a parser MUST treat each one as an independent attribute and MUST NOT, for example, consider later ones to overwrite the previous one. Appraisal policies and profiles SHOULD be clear about how to handle multiples when requiring attribute types that allow multiples.¶

PKIX Attestation Requests are discussed in Section 7. In the tables in the sections that follow, the column "Request Contains a Value" specifies whether, when the given attribute appears in a request, whether it is to be a valued or un-valued request attribute as described in Section 7.¶

5. Signing Procedure

The SignatureBlock.signatureValue signs over the DER-encoded to-be-signed attestation data PkixAttestation.tbs and MUST be validated with the subject public key of the leaf X.509 certificate contained in the SignatureBlock.certChain.¶

6. Verification Procedure

The SignatureBlock.signatureValue signs over the DER-encoded to-be-signed attestation data PkixAttestation.tbs and MUST be validated with the subject public key of the leaf X.509 certificate contained in the SignatureBlock.certChain.¶

Note that a PkixAttestation MAY contain zero or more SignatureBlocks. A PkixAttestation with zero SignatureBlocks is unsigned, MUST be treated as un-protected and un-trusted, and any signature validation procedure MUST fail.¶

More than one SignatureBlocks MAY be used to convey a number of different semantics. For example, the HSM's Attesting Service might hold multiple Attestation Keys on different cryptographic algorithms in order to provide algorithm redundancy in the case that one algorithm becomes cryptographically broken. In this case a Verifier would be expected to validate all SignatureBlocks. Alternatively, the HSM's Attesting Service may hold multiple Attestion Keys (or multiple X.509 certificates for the same key) from multiple operational environments to which it belongs. In this case a Verifier would be expected to only validate the SignatureBlock corresponding to its own environment. Alternatively, multiple SignatureBlocks could be used to convey counter-signatures from external parties, in which case the Verifier will need to be equipped with environment-specific verification logic. Multiple of these cases, and potentially others, could be present in a single PkixAttestation object.¶

Note that each SignatureBlock is a fully detached signature over the tbs content with no binding between the signed content and the SignatureBlocks, or between SignatureBlocks, meaning that a third party can add a counter-signature of the evidence after the fact, or an attacker can remove a SignatureBlock without leaving any artifact. See {#sec-detached-sigs} for further discussion.¶

7. Attestation Requests

EDNOTE: MikeO: this is complex, but I'm not really sure how to define a request format in any simpler way. Ideas are welcome!¶

This section specifies a standardized format that a Presenter can use to request a PKIX Attestation about a specific key or set of keys, a specific environment, or containing specific attributes.¶

Hardware Security Modules range greatly in size and complexity from personal cryptographic tokens containing a single application key such as a smartcard acting as a personal ID card, up to clusters of enterprise-grade HSMs serving an entire cloud service.¶

The manufacturer of a HSM device with limited capabilities may implement a response to the attestation request which includes a fixed set of reported entities, each with a fixed set of reported attributes and parses an Attestion Request object only for the purposes of extracting the nonce.¶

On the other hand, an enterprise grade HSM with the capability to hold a large number of private keys is expected to be capable of parsing attestation requests such that a Presenter can request attestation of specific key(s) by their identifier, or request attestation of all keys with given key attributes within a given sub-environment of the HSM. A full implementation will also create a PKIX Attestation containing exactly the set of requested attributes so that the Presenter can fine-tune the information that it wishes to disclose to the Recipient.¶

A PKIX Attestation Request consists of a un-signed TbsPkixAttestation object containing a single ReportedEntity identified with id-pkix-attest-entity-request, called a request entity. A TbsPkixAttestation containing a request entity MUST NOT contain any other type of entities. Request entities MAY contain Attributes of any type; transaction, platform, key, or any additional attribute type. Any attribute contained in a request entity is called a request attribute. Request entities MUST NOT appear in PKIX Attestation response objects. The TbsPkixAttestation object of an attestation request MAY appear inside a signed PKIXAttestation for the purposes of authenticating and authorizing the requester, but the semantics of doing so are left to the implementer.¶

An Attester that supports Attestation Requests MUST, at the minimum, support extracting the value from a nonce attribute and echoing it into a nonce attribute within a TransactionEntity.¶

Some request attributes contain a value that the HSM uses as a filter or search parameter in constructing the PKIX Attestation; these are called valued requests attributes. Other requests attributes omit the optional value field so that they consist of only the attribute type OID and indicate that the HSM SHOULD collect and return the appropriate measurement; these are called un-valued request attributes. An Attester SHOULD return a PKIX Attestation containing exactly the set of attributes listed in the request, including both valued and un-valued request attributes but MAY omit requested attributes if it cannot be measured in the current device configuration. Note that an Attestation Request will contain all request attributes inside a single request entity, but the HSM MUST sort the attributes in the response PKIX Attestation into the appropriate entity types. For example, if the request contains the key purpose attribute (either valued or un-valued), then all returned key entities will contain the purpose attribute when this data is available for the given key. The tables in the following sections indicate whether an attribute of the given type MUST, MAY, or MUST NOT contain a value when included in a request entity.¶

Generally errors should be handled gracefully by simply omitting an unfulfillable request attribute from the response. An example would be if the hwserial attribute was requested but the devices does not have a serial number. However in some cases a fatal error MAY be returned, for example if attestation of a specific key is requested by key identifier or SubjectPublicKeyInfo but the HSM does not contain a matching key. HSMs SHOULD ignore request attributes with unrecognized type OIDs.¶

Generally, the Attester SHOULD NOT include additional attributes beyond those that were requested. This is to allow the Presenter to fine-tune the information that will be disclosed to the Recipient. Further privacy concerns are discussed in Section 11.3. However, in some contexts this MAY be appropriate, for example, a request containing only a key identifier attribute could be responded to with the full set of platform and key attributes that apply to that key. Discretion is left to implementers.¶

For both error handling and privacy reasons, the Presenter SHOULD check that the returned PKIX Attestation contains the expected attributes prior to forwarding it to the Recipient.¶

8. Appraisal Policies and Profiles

This section provides some sample profiles of appraisal policies that verifiers MAY apply when evaluating evidence. These appraisal profiles represent environment-specific requirements on the contents of the evidence and / or endorsement certificate chain.¶

9. ASN.1 Module

<CODE STARTS>

PKIX-Key-Attest-2025
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkik-key-attest-2025(TBDMOD) }


PkixAttestation ::= SEQUENCE {
    tbs TbsPkixAttestation,
    signatures SEQUENCE SIZE (0..MAX) of SignatureBlock
}

TbsPkixAttestation ::= SEQUENCE {
    version INTEGER,
    reportedEntities SEQUENCE SIZE (1..MAX) OF ReportedEntity
}

ReportedEntity ::= SEQUENCE {
    entityType         OBJECT IDENTIFIER,
    reportedAttributes SEQUENCE SIZE (1..MAX) OF ReportedAttribute
}

ReportedAttribute ::= SEQUENCE {
    attributeType      OBJECT IDENTIFIER,
    value              AttributeValue
}

AttributeValue :== CHOICE {
   bytes       [0] IMPLICIT OCTET STRING
   utf8String  [1] IMPLICIT UTF8String,
   bool        [2] IMPLICIT BOOLEAN,
   time        [3] IMPLICIT GeneralizedTime,
   int         [4] IMPLICIT INTEGER,
   oid         [5] IMPLICIT OBJECT IDENTIFIER
}

SignatureBlock ::= SEQUENCE {
   certChain SEQUENCE of Certificate,
   signatureAlgorithm AlgorithmIdentifier,
   signatureValue OCTET STRING
}

id-pkix-attest OBJECT IDENTIFIER ::= { 1 2 3 999 }

id-pkix-attest-entity-type        OBJECT IDENTIFIER ::= { id-pkix-attest 0 }
id-pkix-attest-entity-transaction OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 0 }
id-pkix-attest-entity-platform    OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 1 }
id-pkix-attest-entity-key         OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 2 }

id-pkix-attest-attribute-type OBJECT IDENTIFIER ::= { id-pkix-attest 1 }

id-pkix-attest-attribute-transaction       OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-type 0 }
id-pkix-attest-attribute-transaction-nonce OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-transaction 0 }

id-pkix-attest-attribute-platform            OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-type 1 }
id-pkix-attest-attribute-platform-vendor     OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 0 }
id-pkix-attest-attribute-platform-hwserial   OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 1 }
id-pkix-attest-attribute-platform-fipsboot   OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 2 }
id-pkix-attest-attribute-platform-desc       OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 3 }
id-pkix-attest-attribute-platform-time       OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 4 }
id-pkix-attest-attribute-platform-swversion  OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 5 }
id-pkix-attest-attribute-platform-oemid      OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 6 }
id-pkix-attest-attribute-platform-debugstat  OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 7 }
id-pkix-attest-attribute-platform-uptime     OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 8 }
id-pkix-attest-attribute-platform-bootcount  OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 9 }
id-pkix-attest-attribute-platform-usermods   OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 8 }
id-pkix-attest-attribute-platform-envid      OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 9 }
id-pkix-attest-attribute-platform-envdesc    OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 10 }
id-pkix-attest-attribute-platform-fipsver  OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 11 }
id-pkix-attest-attribute-platform-fipslevel  OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 12 }



id-pkix-attest-attribute-key                   OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-type 2 }
id-pkix-attest-attribute-key-identifier        OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 0 }
id-pkix-attest-attribute-key-spki              OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 1 }
id-pkix-attest-attribute-key-purpose           OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 2 }
id-pkix-attest-attribute-key-extractable       OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 3 }
id-pkix-attest-attribute-key-never-extractable OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 4 }
id-pkix-attest-attribute-key-local             OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 5 }
id-pkix-attest-attribute-key-expiry            OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 6 }
id-pkix-attest-attribute-key-protection        OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 7 }

<CODE ENDS>

10. IANA Considerations

Please replace "RFCthis" with the RFC number assigned to this document.¶

TODO: list out all the OIDs that need IANA registration.¶

11. Security Considerations

A Verifier MAY reject a PKIX Attestation if it lacks required attributes per their 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.¶

12. References

Appendix A. Samples

A reference implementation of this specification can be found at https://github.com/hannestschofenig/keyattestation¶

It produces the following sample attestation:¶

PkixAttestation:
 tbs=TbsPkixAttestation:
  version=2
  reportedEntities=SequenceOf:
   ReportedEntity:
    entityType=1.2.3.999.0.0
    reportedAttributes=SequenceOf:
     ReportedAttribute:
      attributeType=1.2.3.999.1.0.0
      value=AttributeValue:
       bytes=0102030405


   ReportedEntity:
    entityType=1.2.3.999.0.1
    reportedAttributes=SequenceOf:
     ReportedAttribute:
      attributeType=1.2.3.999.1.1.0
      value=AttributeValue:
       utf8String=HSM-123

     ReportedAttribute:
      attributeType=1.2.3.999.1.1.1
      value=AttributeValue:
       bool=True

     ReportedAttribute:
      attributeType=1.2.3.999.1.1.2
      value=AttributeValue:
       utf8String=Model ABC

     ReportedAttribute:
      attributeType=1.2.3.999.1.1.4
      value=AttributeValue:
       utf8String=3.1.9

     ReportedAttribute:
      attributeType=1.2.3.999.1.1.3
      value=AttributeValue:
       time=202502032234Z


   ReportedEntity:
    entityType=1.2.3.999.0.2
    reportedAttributes=SequenceOf:
     ReportedAttribute:
      attributeType=1.2.3.999.1.2.0
      value=AttributeValue:
       utf8String=26d765d8-1afd-4dfb-a290-cf867ddecfa1

     ReportedAttribute:
      attributeType=1.2.3.999.1.2.3
      value=AttributeValue:
       bool=False

     ReportedAttribute:
      attributeType=1.2.3.999.1.2.1
      value=AttributeValue:
       bytes=0x3059301306072a8648ce3d020106082a8648ce3d03010703420004422548f88fb782ffb5eca3744452c72a1e558fbd6f73be5e48e93232cc45c5b16c4cd10c4cb8d5b8a17139e94882c8992572993425f41419ab7e90a42a494272


   ReportedEntity:
    entityType=1.2.3.999.0.2
    reportedAttributes=SequenceOf:
     ReportedAttribute:
      attributeType=1.2.3.999.1.2.0
      value=AttributeValue:
       utf8String=49a96ace-e39a-4fd2-bec1-13165a99621c

     ReportedAttribute:
      attributeType=1.2.3.999.1.2.3
      value=AttributeValue:
       bool=True

     ReportedAttribute:
      attributeType=1.2.3.999.1.2.1
      value=AttributeValue:
       bytes=0x3059301306072a8648ce3d020106082a8648ce3d03010703420004422548f88fb782ffb5eca3744452c72a1e558fbd6f73be5e48e93232cc45c5b16c4cd10c4cb8d5b8a17139e94882c8992572993425f41419ab7e90a42a494272


   ReportedEntity:
    entityType=1.2.3.888.0
    reportedAttributes=SequenceOf:
     ReportedAttribute:
      attributeType=1.2.3.888.1
      value=AttributeValue:
       utf8String=partition 1




 signatures=SequenceOf:
  SignatureBlock:
   certChain=SequenceOf:
    Certificate:
     tbsCertificate=TBSCertificate:
      version=v3
      serialNumber=510501933685942792810365453374472870755160518925
      signature=AlgorithmIdentifier:
       algorithm=1.2.840.113549.1.1.11
       parameters=0x0500

      issuer=Name:
       rdnSequence=RDNSequence:
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.10
          value=0x0c0449455446
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.11
          value=0x0c0452415453
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.3
          value=0x0c06414b20525341


      validity=Validity:
       notBefore=Time:
        utcTime=250117171303Z

       notAfter=Time:
        generalTime=20520604171303Z


      subject=Name:
       rdnSequence=RDNSequence:
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.10
          value=0x0c0449455446
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.11
          value=0x0c0452415453
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.3
          value=0x0c06414b20525341


      subjectPublicKeyInfo=SubjectPublicKeyInfo:
       algorithm=AlgorithmIdentifier:
        algorithm=1.2.840.113549.1.1.1
        parameters=0x0500

       subjectPublicKey=31795268810366627125468059984427145931784542919710733587190808152893606542214208096328883077225607136393362795609997601968312039001251339428349101203532726047646450301142882318337709398316574407647199690000689245113739552615279534528145776090813314822312012607567736073057936820713733090928849092672110937300300755561797808000438134839458043673852453722969649609202093945235393494912138691342219564365300965387743701570507112064401758218314760153081271981340812350365663466513620853326534252424706992841033652817461354632316129312597825542820569667842318342646457447037125609399476844336456206583416539426479221164971369788464727307915820767918489601

      extensions=Extensions:
       Extension:
        extnID=2.5.29.14
        critical=False
        extnValue=0x04148919595e0ef169f5cbbd47e134fce298cc693091
       Extension:
        extnID=2.5.29.35
        critical=False
        extnValue=0x301680148919595e0ef169f5cbbd47e134fce298cc693091
       Extension:
        extnID=2.5.29.19
        critical=True
        extnValue=0x30030101ff


     signatureAlgorithm=AlgorithmIdentifier:
      algorithm=1.2.840.113549.1.1.11
      parameters=0x0500

     signature=12977775424631768289542539102653382982431795551146145281750189553757940982572813264428982985997740595878077027853994515775116752030963858469651548765808775269857271167748512795017916284867051302884465315751010913658016640170608413935780119349866986170148033301955753116984041271273907756544780231564646860424999020990745523383622980115200446260103173103500647838758197610238552349053064525420240826193553395378873725256584269666918504793674497748455574822238022085054752185687440807655337724821853332688158460379554906105417720665175648371832825939577039874730442790337726004105878168375998123110331993348833629325492

   signatureAlgorithm=AlgorithmIdentifier:
    algorithm=1.2.840.113549.1.1.10
    parameters=RSASSA_PSS_params:
     hashAlgorithm=AlgorithmIdentifier:
      algorithm=2.16.840.1.101.3.4.2.1

     maskGenAlgorithm=AlgorithmIdentifier:
      algorithm=1.2.840.113549.1.1.8

     saltLength=20
     trailerField=1


   signatureValue=0x9b6ac1932f1cd85befbde054e084577ebc9181bcf05179658a700e22556fc3f1931f59dc9734efe08df204fcfe55c64c6a97e8d520e58c1f64080b6cce1c08e88db510c06d6914a818b70df82326b37a2abe54fab0567d748e1e82e2de954cac63c5ab3bc92fff9cb8aa64fbcb83dd8bacbce96392f91dd40ee05058adceb11f5cf0c379241fd470918abceea70fd01c0cbc64d96067fe549ec443738655bc2bcf7e5bd54c15d5e5ac2f4ad180d973a7e6025126ccd2b45d78e9944662237959ef73f47e9ae0fa9b0c55177bb6f867a90b41d0efb72c192f15a66531d030bc85fed3d135aea4045e024ef2e807517504d313dbea4b0f709d0553b60793b2dcaa
  SignatureBlock:
   certChain=SequenceOf:
    Certificate:
     tbsCertificate=TBSCertificate:
      version=v3
      serialNumber=43752118382009037811618748949928339462896457144
      signature=AlgorithmIdentifier:
       algorithm=1.2.840.10045.4.3.2

      issuer=Name:
       rdnSequence=RDNSequence:
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.10
          value=0x0c0449455446
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.11
          value=0x0c0452415453
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.3
          value=0x0c07414b2050323536


      validity=Validity:
       notBefore=Time:
        utcTime=250117171428Z

       notAfter=Time:
        generalTime=20520604171428Z


      subject=Name:
       rdnSequence=RDNSequence:
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.10
          value=0x0c0449455446
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.11
          value=0x0c0452415453
        RelativeDistinguishedName:
         AttributeTypeAndValue:
          type=2.5.4.3
          value=0x0c07414b2050323536


      subjectPublicKeyInfo=SubjectPublicKeyInfo:
       algorithm=AlgorithmIdentifier:
        algorithm=1.2.840.10045.2.1
        parameters=0x06082a8648ce3d030107

       subjectPublicKey=57095560233504924588952816185508037812996307929249104847846164660564888397123390877585670462836285725041261897550020311481127562655774333675293173915140722

      extensions=Extensions:
       Extension:
        extnID=2.5.29.14
        critical=False
        extnValue=0x04145b70a79817f79ff637d2f7e3dc446c2109d7bbd4
       Extension:
        extnID=2.5.29.35
        critical=False
        extnValue=0x301680145b70a79817f79ff637d2f7e3dc446c2109d7bbd4
       Extension:
        extnID=2.5.29.19
        critical=True
        extnValue=0x30030101ff


     signatureAlgorithm=AlgorithmIdentifier:
      algorithm=1.2.840.10045.4.3.2

     signature=182167519797146035745575043154801415115532979136731128676399180692664821804883990401552040789643013103202424486088058364982966709324496782518079519267269438816178719668437

   signatureAlgorithm=AlgorithmIdentifier:
    algorithm=1.2.840.10045.2.1
    parameters=0x06082a8648ce3d030107

   signatureValue=0x304402201e7703f63bff951917714e5fa813de5265f151a6802165ef0be5f1fe6c91225b02200ad06b41a5062b07ff3ad37c7d112e19575f0e14a9750fe95e615550b88b5fed



DER Base64:
MIIIyzCCAiUCAQIwggIeMCEGBioDh2cAADAXMBUGByoDh2cBAAAECjAxMDIwMzA0MDUwbgYGKgOHZwABMGQwEgYHKgOHZwEBAAwHSFNNLTEyMzAMBgcqA4dnAQEBAQH/MBQGByoDh2cBAQIMCU1vZGVsIEFCQzAQBgcqA4dnAQEEDAUzLjEuOTAYBgcqA4dnAQEDGA0yMDI1MDIwMzIyMzRaMIGyBgYqA4dnAAIwgacwLwYHKgOHZwECAAwkMjZkNzY1ZDgtMWFmZC00ZGZiLWEyOTAtY2Y4NjdkZGVjZmExMAwGByoDh2cBAgMBAQAwZgYHKgOHZwECAQRbMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQiVI+I+3gv+17KN0RFLHKh5Vj71vc75eSOkyMsxFxbFsTNEMTLjVuKFxOelIgsiZJXKZNCX0FBmrfpCkKklCcjCBsgYGKgOHZwACMIGnMC8GByoDh2cBAgAMJDQ5YTk2YWNlLWUzOWEtNGZkMi1iZWMxLTEzMTY1YTk5NjIxYzAMBgcqA4dnAQIDAQH/MGYGByoDh2cBAgEEWzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERSxyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJQnIwHwYFKgOGeAAwFjAUBgUqA4Z4AQwLcGFydGl0aW9uIDEwggaeMIIEejCCA0UwggNBMIICKaADAgECAhRZa7LL1EZqtYP6TqThmzBiZDtxDTANBgkqhkiG9w0BAQsFADAvMQ0wCwYDVQQKDARJRVRGMQ0wCwYDVQQLDARSQVRTMQ8wDQYDVQQDDAZBSyBSU0EwIBcNMjUwMTE3MTcxMzAzWhgPMjA1MjA2MDQxNzEzMDNaMC8xDTALBgNVBAoMBElFVEYxDTALBgNVBAsMBFJBVFMxDzANBgNVBAMMBkFLIFJTQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALD56BlDp66YkqreF8p8QPh0T+0vgUjmyOqie30AFUj7UZKrKLVsUGCxGMzRMeWUh0xsqYm1bCcpbwn7k6A03zLpfG/wmYz9jm9C3aWKzR+peYbxRPPRVNZ2UBdeaFSzqVIAO8Boh7hFWsKxn3svdlBOvJjslFVxsHiSFQ3canTKD7zTVJfOgVNNr5QYhEsTrqMfnVprlVe732Ge/U6Ify1CuN2LyYfq4b+Jyrhe4h41YwXfbAeog44+9BxZXczkPa/EkSPvTYq7qT05BeQCjXupFISidZbge0tu2ZLwd7Uk09z+fd1VSb58zo2gNc+gs/uPnkb3MrKoa0YBZcCPUxMCAwEAAaNTMFEwHQYDVR0OBBYEFIkZWV4O8Wn1y71H4TT84pjMaTCRMB8GA1UdIwQYMBaAFIkZWV4O8Wn1y71H4TT84pjMaTCRMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAGbNxMg9iFU20x2s5v1572pgAOVO5CXXLWZ2sM9wL7ObBm7Aosm7z2G/GYV0OtU1zpCw0qcfR9a0xnFTlRBOupbZZ/SMtjduN8mQKZNBqE4rxcPehCp9dUoJ74wYVRKHvUFRdzgUhDMwnqmEb7mqIKqwP0Ev+AVd/hqj4EjhJCFVaLoVH4k4EzF33UNgPJivo1910BvNpbuIOhURZHWm9ABlvJxZ+/Uohjqd7bJDR1J506ogT052OqLZCRbiQPupdEtgpww+p7VI9qjbGhLYrPxIh2gsicu7sJvdALuf+gRuIrgkhUPb2CIym50nyBsEsuPAOsKWzTID6eDyf/CSSLQwKwYJKoZIhvcNAQEKMB6gDTALBglghkgBZQMEAgGhDTALBgkqhkiG9w0BAQgEggEAm2rBky8c2FvvveBU4IRXfryRgbzwUXllinAOIlVvw/GTH1nclzTv4I3yBPz+VcZMapfo1SDljB9kCAtszhwI6I21EMBtaRSoGLcN+CMms3oqvlT6sFZ9dI4eguLelUysY8WrO8kv/5y4qmT7y4Pdi6y86WOS+R3UDuBQWK3OsR9c8MN5JB/UcJGKvO6nD9AcDLxk2WBn/lSexENzhlW8K89+W9VMFdXlrC9K0YDZc6fmAlEmzNK0XXjplEZiI3lZ73P0fprg+psMVRd7tvhnqQtB0O+3LBkvFaZlMdAwvIX+09E1rqQEXgJO8ugHUXUE0xPb6ksPcJ0FU7YHk7LcqjCCAhwwggG7MIIBtzCCAV2gAwIBAgIUB6npr/yEpH9d/wPt8w6Lo5AflbgwCgYIKoZIzj0EAwIwMDENMAsGA1UECgwESUVURjENMAsGA1UECwwEUkFUUzEQMA4GA1UEAwwHQUsgUDI1NjAgFw0yNTAxMTcxNzE0MjhaGA8yMDUyMDYwNDE3MTQyOFowMDENMAsGA1UECgwESUVURjENMAsGA1UECwwEUkFUUzEQMA4GA1UEAwwHQUsgUDI1NjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERSxyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJQnKjUzBRMB0GA1UdDgQWBBRbcKeYF/ef9jfS9+PcRGwhCde71DAfBgNVHSMEGDAWgBRbcKeYF/ef9jfS9+PcRGwhCde71DAPBgNVHRMBAf8EBTADAQH/MAoGCCqGSM49BAMCA0gAMEUCIQCQfwSuP9Ms2gR8ki+iQQQNWaEfl/tRAd2usLJBYSEl6AIgJGzL/VWqOjeqD9aseiynBwHY9odjL4Wcfv2bOeo7uNUwEwYHKoZIzj0CAQYIKoZIzj0DAQcERjBEAiAedwP2O/+VGRdxTl+oE95SZfFRpoAhZe8L5fH+bJEiWwIgCtBrQaUGKwf/OtN8fREuGVdfDhSpdQ/pXmFVULiLX+0=

Appendix B. Acknowledgements

This specification is the work of a design team created by the chairs of the RATS working group. This specification has been developed based on discussions in that design team and also with great amounts of input taken from discussions on the RATS mailing list.¶

Authors' Addresses