PKIX Evidence for Remote 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 28 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 defines a format to transmit Evidence from an Attester to a Verifer within a PKIX environment. This environment refers to the components generally used to support a PKI applications such as Certification Authorities and their clients.¶

Within this specification, the concepts found in the Remote Attestation Procedures (RATS [RFC9334]) are mapped to the PKIX environment. There are many other specifications that are based on the RATS architecture which offer formats to carry evidence. This specification deals with peculiar aspects of the PKIX environment which discourage the use of other specifications:¶

• ASN.1 is the preferred encoding format in this environment. X.509 certificates ([RFC5280]) are used widely within this environment and the majority of tools are designed to support ASN.1. There are many specialized devices (Hardware Security Modules) that are inflexible in adopting other formats because of internal constraints or validation difficulties. This specification defines the format in ASN.1 to ease the adoption within the community.¶

• The claims within the Evidence are more about entities such as "platforms" and "keys". Although the concept of "measurement" is present within the PKIX environment, it is not as prevalent as in the environments targeted by other specifications based on RATS. Therefore, the emphasis of this specifications is adjusted accordingly.¶

• The devices found in the PKIX environment are developed by different vendors and are heterogeneous in features and capabilities. Therefore, this specification assumes that the Attesting Environment and the Target Environment, as outlined in [RFC9334], are the same. This might not be the case for all devices encountered, but is sufficient for the proposed specification.¶

This specification also aims at providing an extensible framework to encode within Evidence claims other than the one proposed in this document. This allows implementations to introduce new claims and their associated semantics to the Evidence produced.¶

2. Use Cases

This section covers use cases that motivated the development of this specification.¶

3. Terminology

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

The following terms are used in this document:¶

Application Key:

An application key consists of a key hosted by a HSM (the platform) and intended to be used by a client of the HSM. The access and operations on an application key is controlled by the HSM.¶

Attestation Key (AK):

Cryptographic key controlled solely by the Attester and used only for the purpose of producing Evidence. In other words, it is used to digitally sign the claims collected by the Attester.¶

Attestation Service (AttS):

A logical module within the HSM that is responsible for generating Evidence compatible with the format outlined in this specification. It collects claims from the platform and uses the Attestation Key to digitally sign the collection.¶

Attester :

The term Attester respects the definition offered in [RFC9334]. In this specification, it is also interchangeable with "platform" or "HSM".¶

Evidence :

The term Evidence respects the definition offered in [RFC9334]. In this specification, it refers to claims, encoded according to the format defined within this document, and signed using the Attestation Key.¶

Hardware Security Module (HSM):

A physical computing device that safeguards and manages secrets (most importantly cryptographic keys), and performs cryptographic operations based on those secrets. This specification takes a broad definition of what counts as an HSM to include smartcards, USB tokens, TPMs, cryptographic co-processors (PCI cards) and "enterprise-grade" or "cloud-service grade" HSMs (possibly rack mounted). In this specification, it is interchangeable with "platform" or "Attester".¶

Key Attestation:

Process of producing Evidence containing claims pertaining to application keys found within a HSM. In general, the claims includes enough information about an application key and its hosting platform to allow a Relying Party to make judicial decisions about the key, such as issuing a certificate.¶

Platform:

The module or device that embodies the Attester. In this specification, it is interchangeable with "Attester" or "HSM".¶

Platform Attestation:

Evidence containing claims pertaining to an attesting platform. In general, the claims includes enough information about the platform to allow a Relying Party to make judicial decisions about the platform, such as audit reviews.¶

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

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

4. Architecture and Conceptual Model

JPF: Note sure what in this section needs to be saved.¶

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

MikeO: While I understand that this image matches exactly the RATS architecture, I feel that we have lost something in that we no longer have the Attesting Environment collecting Claims about both the HSM itself and about application keys. I would like to go back to the original diagram.¶

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 6 will feel familiar to implementers with experience with PKI and PKCS#11.¶

5. Information Model

The PKIX Evidence format is composed of two main sections:¶

• A claim description section which describes the information transmitted as Evidence.¶

• A signature section where digital signature are offered to prove the origin of the claims and maintain their integrity.¶

The details of the signature section is left to the data model. The remainder of this section deals with the way the information is organized to form the claims.¶

The claims are organized into a set of entities to help with the organization and comprehension of the information. Entities are elements observed in the Target Environment by the Attester. Each entity, in turn, is associated with a set of attributes.¶

Therefore, the claim description section is a set of entities and each entity is composed of a set of attributes.¶

6. Data 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 9. 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 9.¶

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

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

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

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

11. ASN.1 Module

<CODE STARTS>

PKIX-Evidence-2025
      { iso(1) identified-organization(3) dod(6) internet(1)
        security(5) mechanisms(5) pkix(7) id-mod(0)
        id-mod-pkix-evidence-2025(TBDMOD) }


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

TbsPkixEvidence ::= 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-evidence OBJECT IDENTIFIER ::= { 1 2 3 999 }

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

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

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

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



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

<CODE ENDS>

12. IANA Considerations

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

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

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

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