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

EDNOTE: is "application keys" a bad choice since "AK" already means "attestation key"?¶

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 [!RFC9443] by assuming that the attesting environment and the target environment are the same environment, and that this environment only produces self-attested 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 [X680] 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

TODO: I think some of this terminology is not needed. TODO: JP believes that PAK, KAK and KAS should be removed. TODO: MikeO believes that PAT, KAT, and CAB can also be removed.¶

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 identity key (IK). More precisely, it has to attest the integrity of the IK (public as well as private key) and the confidentiality of the IK private 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.¶

Platform Attestation Key (PAK):

An AK used specifically for signing attestation tokens relating to the state of the platform.¶

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

Key Attestation Key (KAK):

An AK used specifically for signing KATs. In some systems only a single AK is used. In that case the AK is used as a PAK and a KAK.¶

Identity Key (IK):

The IK 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 IK is protected by the RoT.¶

Usage Protocol:

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

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 Token (PAT):

An AT containing claims relating to the security state of the platform, including software constituting the platform trusted computing base (TCB). The process of generating a PAT typically involves gathering data during measured boot.¶

Key Attestation Token (KAT):

An AT containing a claim with a public key. The KAT may also contain other claims, such as those indicating its validity. The KAT is signed by the KAK. The key attestation service, which is part of the platform root of trust (RoT), conceptually acts as a local certification authority since the KAT behaves like a certificate.¶

Combined Attestation Bundle (CAB):

A structure used to bundle a KAT and a PAT together for transport in the usage protocol. If the KAT already includes a PAT, in form of a nested token, then it already corresponds to a CAB. A CAB is equivalent to a certificate that binds the identity of the platform's TCB with the IK public key.¶

Presenter:

Party that proves possession of a private key to a recipient of a KAT. Typically this will be an application layer entity such as a cryptographic library constructing a Certificate Signing Request that must embed a key attestation, 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 KAT 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-11].¶

TODO: for the RATS audience, we probably need to clarify what exactly an "Application Key" is. Add to glossary? Potentially we need a Use Cases section: CA keys, TLS keys, etc.¶

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

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. A PKIX Attestation containing more than one platform entity is considered a fatal error by a parser since duplicate and conflicting platform claims across multiple platform entities can easily lead to security bugs.¶

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

A PKIX Attestation can contain at most one transaction entity. A transaction entity contains attributes that are related to the request such as a "nonce". Attributes associated with the request do not belong with any other entities and should be reported as part of the transaction entity.¶

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,
   asciiString [1] IMPLICIT IA5String,
   utf8String  [2] IMPLICIT UTF8String,
   bool        [3] IMPLICIT BOOLEAN,
   time        [4] IMPLICIT GeneralizedTime,
   int         [5] IMPLICIT INTEGER,
   oid         [6] 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 identifier for a key entity (key identifier) should not be repeated as this is a unique value. However, other attribute types could be interpreted as a "set". Therefore, this specification is not constraining the number of times a particular attribute type is encountered within an entity.¶

A Verifier is responsible of ensuring the consistency of the recognized attributes reported for a given entity. Ultimately, a Verifier is responsible for providing attestation results to a Relying Party. Therefore, the Verifier should be constructed in such a way as to extract the relevant information for this Relying Party.¶

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

8. 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,
   asciiString [1] IMPLICIT IA5String,
   utf8String  [2] IMPLICIT UTF8String,
   bool        [3] IMPLICIT BOOLEAN,
   time        [4] IMPLICIT GeneralizedTime,
   int         [5] IMPLICIT INTEGER,
   oid         [6] 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-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>

9. IANA Considerations

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

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

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

11. References

Appendix A. Samples

TODO¶

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