Remote ATtestation procedureS M. Ounsworth Internet-Draft Entrust Intended status: Standards Track J.-P. Fiset Expires: 1 September 2025 Crypto4A H. Tschofenig H-BRS H. Birkholz Fraunhofer SIT M. Wiseman Beyond Identity N. Smith Intel Corporation 28 February 2025 PKIX Key Attestation draft-ounsworth-rats-key-attestation-latest Abstract This document specifies a vendor-agnostic format for attesting to the protection properties of a symmetric or asymmetric cryptographic key within a hardware cryptographic module to support applications 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 HSM vendors. This specification includes a format for requesting a key attestation containing certain attributes. This specification is called "PKIX Attestation" because it is designed to be easy to implement on top of a code base that already supports X.509 and PKCS#11 data models. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/. Source for this draft and an issue tracker can be found at https://github.com/hannestschofenig/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 2. Terminology 3. Architecture and Conceptual Model 3.1. Attestation Key Certificate Chain 4. Data Model 4.1. Attestation Requests 4.2. Transaction Attributes 4.2.1. nonce 4.2.2. time 4.3. Platform Attributes 4.3.1. usermods 4.3.2. fipsboot 4.3.3. envid 4.3.4. envdesc 4.4. Key Attributes 4.4.1. purpose 4.4.2. protection 4.5. Additional Entity and Attribute Types 4.6. Encoding 5. Signing Procedure 6. Verification Procedure 7. Appraisal Policies and Profiles 7.1. Key Import into an HSM 7.2. CA/Browser Forum Code-Signing 8. ASN.1 Module 9. IANA Considerations 10. Security Considerations 10.1. Simple to implement 10.2. Detached Signatures 10.3. Privacy 11. References 11.1. Normative References 11.2. Informative References Appendix A. Samples Appendix B. Acknowledgements Authors' Addresses 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. .-------------------------------------. | Crypto Module | | | | Platform environment | | ^ .-------------. | | | | Application | | | | | Keys | | | | '-------------' | | | ^ | | | | | | | measurements | | | .------------------------------. | | | Attestation | | | | Service | | | '------------------------------' | | ^ | | | | | | '-----+----+--------------------------' Attestation | | PKIX Request | | Attestation | v .-----------------. .-----------------. | | Usage Protocol | | | Presenter +---------------->| Recipient | | | | | '-----------------' '-----------------' Figure 1: Architecture 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. 3.1. Attestation Key Certificate Chain The data format in this specification represents self-attested evidence and therefore requires third-party endorsement in order to establish trust. This endorsement comes in the form of an X.509 certificate chain where the SubjectPublicKey of the leaf certificate is the HSM's attestation key (AK) which signs the evidence, and this AK certificate chains to a trust anchor which is trusted by the Recipient as authoritative to vouch for the authenticity of the device. In practice the trust anchor will usually be a manufacturing CA belonging to the device vendor which proves that the device is genuine and not counterfeit. The Trust Anchor can also belong to the device operator as would be the case when the AK certificate is replaced as part of on-boarding the device into a new operational network. Note that the data format specified in Section 4 allows for zero, one, or multiple 'SignatureBlock's, so a single evidence statement could be un-protected, or could be endorsed by multiple AK chains leading to different trust anchors. See Section 6 for a discussion of handling multiple SignatureBlocks. TODO: should this specification provide specific X.509 extensions that should be present in this AK Certificate to carry specific information about the device? TODO: should CPS be mentioned here? 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. 4.1. 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 Attesttion 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 requesting attestation of all keys in a given environment with the given key attributes. A full implementation will also create a PKIX Attestation containing exactly the 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 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. 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 MUST 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 {#sec-cons-privacy}. 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. 4.2. Transaction Attributes A default and vendor-agnostic set of transaction attributes is defined in this section. These attribute types MAY be contained within a transaction entity; i.e. an entity identified by id-pkix-attest-entity-transaction. +=========+==============+===================+========+========+============+ |Attribute|AttributeValue|Reference |Multiple|Request |Description | | | | |Allowed |Contains| | | | | | |a Value | | +=========+==============+===================+========+========+============+ |nonce |bytes |RFCthis |No |MUST |Repeats a | | | | | | |"nonce" | | | | | | |provided | | | | | | |during the | | | | | | |atttestation| | | | | | |request. | +---------+--------------+-------------------+--------+--------+------------+ |timestamp|time |[I-D.ietf-rats-eat]|No |MUST NOT|The time at | | | | | | |which this | | | | | | |attestation | | | | | | |was | | | | | | |generated. | | | | | | |Corresponds | | | | | | |to EAT IAT | | | | | | |claim. | +---------+--------------+-------------------+--------+--------+------------+ Table 1 4.2.1. nonce The nonce attribute is used to provide "freshness" quality as to the information provided by the Attester (HSM) in the PkixAttestation message. A client requesting a PkixAttestation message MAY provide a nonce value as part of the request. This nonce value, if provided, SHOULD be repeated as an attribute to the transaction entity. 4.2.2. time The time at which this attestation was generated, according to the internal system clock of the HSM. Note that it is common for HSMs to not have an accurate system clock; consider an HSM for a root CA kept offline and booted up infrequently in an local network segregated from all other network, or a smart card which boots up only when held against an NFC reader. Implementers of emitters SHOULD include this attribute only if the device reliably knows its own time (for example has had recent contact with an NTP server). Implementers of parsers SHOULD be wary of trusting the contents of this attribute. A challenge-response protocol that makes use of the nonce attribute is a far more reliable way of establishing freshness. 4.3. Platform Attributes A default and vendor-agnostic set of platform attributes is defined in this section. These attribute types MAY be contained within a platform entity; i.e. an entity identified by id-pkix-attest-entity-platform. +=========+==============+===================+========+========+====================+ |Attribute|AttributeValue|Reference |Multiple|Request |Description | | | | |Allowed |Contains| | | | | | |a Value | | +=========+==============+===================+========+========+====================+ |vendor |utf8String |RFCthis |No |MUST NOT|A human-readable | | | | | | |string by which the | | | | | | |vendor identifies | | | | | | |themself. | +---------+--------------+-------------------+--------+--------+--------------------+ |oemid |bytes |[I-D.ietf-rats-eat]|No |MUST NOT|The EAT OEM ID as | | | | | | |defined in | | | | | | |[I-D.ietf-rats-eat].| +---------+--------------+-------------------+--------+--------+--------------------+ |hwmodel |utf8String |[I-D.ietf-rats-eat]|No |MUST NOT|Model or product | | | | | | |line of the hardware| | | | | | |module. | +---------+--------------+-------------------+--------+--------+--------------------+ |hwserial |asciiString |RFCthis |No |MUST NOT|Serial number of the| | | | | | |hardware module, | | | | | | |often matches the | | | | | | |number engraved or | | | | | | |stickered on the | | | | | | |case. | +---------+--------------+-------------------+--------+--------+--------------------+ |swversion|asciiString |[I-D.ietf-rats-eat]|No |MUST NOT|A text string | | | | | | |identifying the | | | | | | |firmware or software| | | | | | |running on the HSM. | +---------+--------------+-------------------+--------+--------+--------------------+ |dbgstat |int |[I-D.ietf-rats-eat]|No |MUST NOT|Indicates whether | | | | | | |the HSM is currently| | | | | | |in a debug state, or| | | | | | |is capable in the | | | | | | |future of being | | | | | | |turned to a debug | | | | | | |state. Semantics | | | | | | |and integer codes | | | | | | |are defined in | | | | | | |[I-D.ietf-rats-eat].| +---------+--------------+-------------------+--------+--------+--------------------+ |uptime |int |[I-D.ietf-rats-eat]|No |MUST NOT|Contains the number | | | | | | |of seconds that have| | | | | | |elapsed since the | | | | | | |entity was last | | | | | | |booted. | +---------+--------------+-------------------+--------+--------+--------------------+ |bootcount|int |[I-D.ietf-rats-eat]|No |MUST NOT|Contains a count of | | | | | | |the number of times | | | | | | |the entity has been | | | | | | |booted. | +---------+--------------+-------------------+--------+--------+--------------------+ |usermods |utf8String |RFCthis |Yes |MUST NOT|This attribute lists| | | | | | |user modules | | | | | | |currently loaded | | | | | | |onto the HSM in a | | | | | | |human readable | | | | | | |format, preferabbly | | | | | | |JSON. | +---------+--------------+-------------------+--------+--------+--------------------+ |fipsboot |bool |[FIPS.140-3] |No |MUST NOT|Indicates whether | | | | | | |the devices is | | | | | | |currently running in| | | | | | |FIPS mode. | +---------+--------------+-------------------+--------+--------+--------------------+ |envid |asciiString |RFCthis |Yes |MAY |An environment ID, | | | | | | |which will typically| | | | | | |be a URI, UUID, or | | | | | | |similar. | +---------+--------------+-------------------+--------+--------+--------------------+ |envdesc |utf8String |RFCthis |Yes |MUST NOT|Further description | | | | | | |of the environment. | +---------+--------------+-------------------+--------+--------+--------------------+ Table 2 TODO: find the actual reference for "FIPS Mode" -- FIPS 140-3 does not define it (at least not the 11 page useless version of 140-3 that I found). Each attribute has an assigned OID, see Section 8. Some of the attributes defined in this specification have further details below. 4.3.1. usermods Most HSMs have some concept of trusted execution environment where user software modules can be loaded inside the HSM to run with some level of privileged access to the application keys. This attribute lists user modules currently loaded onto the HSM in a human readable format, preferably JSON. 4.3.2. fipsboot FIPS 140-3 CMVP validation places stringent requirements on the cryptography offered by the module, including only enabling FIPS- approved algorithms, certain requirements on entropy sources, and extensive start-up self-tests. Many HSMs include a configuration setting that allows the device to be taken out of FIPS mode and thus enable additional functionality or performance. This boolean attribute indicates whether the device is currently operating in FIPS mode. For most HSMs, changing this configuration setting from fipsboot=true to fips-boos=false is destructive and will result in zeroization of all cryptographic keys held within the module. Whether the device is currently running in FIPS mode is completely independent from whether the device has a valid and active FIPS CMVP certification. For example, some devices may have a FIPS mode configuration, and some operators may choose to enable it, even if that particular model was never submitted for certification. In fact, the device has no way to know whether it has an active certification or not. This information is available on the NIST CMVP website or by contacting the device vendor. 4.3.3. envid An identifier for an environment to which the attested keys belong. These will be an a vendor-chosen format, but are constrained to ASCII as URIs, UUID, and similar types of identifiers are envisioned. There MAY be multiple envid attributes if the attested keys simultaneously belong to multiple environments. Note that by including envid as a Platform Attribute, this implies that it applies to all attested key entities. If the HSM needs to attest multiple keys across multiple disjoint environments, then multiple PKIXAttestations are required. This naturally enforces privacy constraints of only attesting a single environment at a time. If an envdid request attribute contains a value, this means that the Presenter is requesting that only keys belogning to the given environment be included in the returned attestation. 4.3.4. envdesc Further description of the environment beyond hwvendor, hwmodel, hwserial, swversion; for example if there is a need to describe multiple logical partitions within the same device. Contents could be a human-readable description or other identifiers. 4.4. Key Attributes A default and vendor-agnostic set of key attributes is defined in this section. These attribute types MAY be contained within a key entity; i.e. an entity identified by id-pkix-attest-entity-key. +===========+==============+=========+========+========+======================+ |Attribute |AttributeValue|Reference|Multiple|Request |Description | | | | |Allowed |Contains| | | | | | |a Value | | +===========+==============+=========+========+========+======================+ |identifier |utf8String |RFCthis |Yes |MAY |Identifies the subject| | | | | | |key, with a vendor- | | | | | | |specific format which | | | | | | |could be numeric, | | | | | | |UUID, or other textual| | | | | | |identifier. | +-----------+--------------+---------+--------+--------+----------------------+ |spki |bytes |RFCthis |No |MAY |A complete DER-encoded| | | | | | |SubjectPublicKeyInfo | | | | | | |representing the | | | | | | |public key associated | | | | | | |with the asymetric key| | | | | | |pair being attested. | +-----------+--------------+---------+--------+--------+----------------------+ |purpose |bytes |[PKCS11] |No |MAY |Defines the intended | | | | | | |usage for the key. | +-----------+--------------+---------+--------+--------+----------------------+ |extractable|bool |[PKCS11] |No |MAY |Indicates if the key | | | | | | |is able to be exported| | | | | | |from the module. | | | | | | |Corresponds directly | | | | | | |to PKCS#11 | | | | | | |CKA_EXTRACTABLE. | +-----------+--------------+---------+--------+--------+----------------------+ |never- |bool |[PKCS11] |No |MAY |Indicates if the key | |extractable| | | | |was able to be | | | | | | |exported from the | | | | | | |module. Corresponds | | | | | | |directly to PKCS#11 | | | | | | |CKA_NEVER_EXTRACTABLE.| +-----------+--------------+---------+--------+--------+----------------------+ |local |bool |RFCthis |No |MAY |Indicates whether the | | | | | | |key was generated | | | | | | |locally or imported. | +-----------+--------------+---------+--------+--------+----------------------+ |expiry |time |RFCthis |No |MAY |Defines the expiry | | | | | | |date or "not after" | | | | | | |time for the key. | +-----------+--------------+---------+--------+--------+----------------------+ |protection |bytes |RFCthis |No |MAY |Indicates any | | | | | | |additional key | | | | | | |protection properties.| +-----------+--------------+---------+--------+--------+----------------------+ Table 3 4.4.1. purpose TODO: probably need to define a mapping from PKCS#11 CKA enums to a bit-indexed byte array. 4.4.2. protection Indicates any additional key protection properties around use or modification of this key. These are generalized properties and will not apply the same way to all HSM vendors. Consult vendor documentation for the in-context meaning of these flags. TODO: define a bit-indexed byte array BIT MASK / Boolean Array {DualControl (0), CardControl (1), PasswordControl (2), ...} We may need to say that the first X are reserved for use by future RFCs that update this specification, and beyond that is private use. 4.5. Additional Entity and Attribute Types It is expected that HSM vendors will register additional Entity and Attribute types by assigning OIDs from their own proprietary OID arcs to hold data describing additional proprietary key properties. An Attester (HSM) which is requested to provide information about unrecognized Entity or Attribute types MUST fail the operation. A Verifier which encounters an unrecognized Entity or Attribute type MAY ignore it. 4.6. Encoding A PKIXAttestation is to be DER encoded [X.690]. If a textual representation is required, then the DER encoding MAY be subsequently encoded into Base64. EDNOTE: I think we have to be precise about which flavour of Base64 we are referrring to. 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. 7.1. Key Import into an HSM An HSM which is compliant with this draft SHOULD validate any PKIX Key Attestations that are provided along with the key being imported. The SignatureBlocks MUST be validated and MUST chain to a trust anchor known to the HSM. In most cases this will be the same trust anchor that endorsed the HSMs own AK, but the HSM MAY be configured with set of third party trust anchors from which it will accept key attestations. If the HSM is operating in FIPS Mode, then it MUST only import keys from HSMs also operating in FIPS Mode. The claims key-purpose, key-extractable, key-never-extractable, key- local MUST be checked and honoured during key import, which typically means that after import, the key MUST NOT claim a stronger protection property than it had on the previous hardware. In other words, Key Attestation allows and requires that key protection properties be preserved over export / import operations between different HSMs, and this format provides a vendor-agnostic way to acheive this. How to handle errors is outside the scope of this specification and is left to implementors; for example the key import MAY be aborted, or a prompt MAY be given to the user administrator, or any similar reasonable error handling logic. 7.2. CA/Browser Forum Code-Signing TODO: ... intro text The subscriber MUST: * Provide the CA with a CSR containing the subscriber key. * Provide an attestation token as per this specification describing the private key protection properties of the subscriber's private key. This token MAY be transported inside the CSR as per draft- ietf-lamps-csr-attest, or it MAY be transported adjacent to the CSR over any other certificate enrollment mechanism. The CA / RA / RP / Verifier MUST: * Ensure that the subscriber key which is the subject of the CSR is also described by a KAT by matching either the key fingerprint or full SubjectPublicKeyInfo. * The hardware root-of-trust described by a PAT has a valid and active FIPS certificate according to the NIST CMVP database. * The attestation signing key (AK) which has signed the attestation token chains to a root certificate that A) belongs to the hardware vendor described in the PAT token, and B) is trusted by the CA / RA / RP / Verifier to endorse hardware from this vendor, for example through a CA's partner program or through a network operator's device on-boarding process. * The key is protected by a module running in FIPS mode. The parsing logic is to start at the leaf KAT token that matches the key in the CSR and parsing towards the root PAT ensuring that there is at least one fipsboot=true and no fipsboot=false on that path. 8. ASN.1 Module 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 } 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. 10.1. Simple to implement The nature of attestation requires the attestation service to be implemented in an extremely privileged position within the HSM so that it can collect measurements of both the hardware environment and the application keys being attested. For many HSM and TPM architectures, this will place the Attestation Service inside the "HSM kernel" and potentially subject to FIPS 140-3 or Common Criteria validation and change control. For both security and compliance reasons there is incentive for the emitting and parsing logic to be simple and easy to implement correctly. Additionally, when the data formats contained in this specification are parsed within an HSM boundary -- that would be parsing a request entity, or parsing an attestation produced by a different HSM -- implementers SHOULD opt for simple logic that rejects any data that does not match the expected format instead of attempting to be flexible. In particular, Attesting Services SHOULD generate the attestation object from scratch and avoid copying any content from the request. Attesting Services MUST NOT allow unrecognized attributes or any attribute value other than the nonce to be echoed from the request into the attestation object. 10.2. Detached Signatures TODO beef this up No indication within the tbs content about what or how many signatures to expect. A SignatureBlock can be trivially stripped off without leaving any evidence. When multiple SignatureBlocks are used for providing third party counter-signatures, note that the counter signature only covers the tbs content and not existing SignatureBlocks. 10.3. Privacy Often, a TPM will host cryptographic keys for an entire operating system but a Presenter only represents a single user or application. Similarly, a single Hardware Security Module will often host cryptographic keys for an entire multi-tenant cloud service and the Presenter or Recipient belongs only to a single tenant. In these cases, disclosing even the existance of a given key, let alone its attributes, to an unauthorized party would constitute an egregious privacy violation. Implementions SHOULD be careful to avoid over- disclosure of information, for example by authenticating the Presenter and only returning results for keys and envirnments for which it is authorized, and by supporting request attributes that can be used as filters to allow the Presenter to request a key attestation containing only content that is appropriate for the intended Recipient. 11. References 11.1. Normative References [I-D.ietf-rats-eat] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", Work in Progress, Internet-Draft, draft-ietf-rats-eat-31, 6 September 2024, . [PKCS11] OASIS PKCS 11 TC, "PKCS #11 Specification Version 3.1", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . [X.680] ITU-T, "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation", n.d., . [X.690] ITU-T, "Information technology - ASN.1 encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ISO/IEC 8825-1:2015, November 2015. 11.2. Informative References [I-D.bft-rats-kat] Brossard, M., Fossati, T., Tschofenig, H., and H. Birkholz, "An EAT-based Key Attestation Token", Work in Progress, Internet-Draft, draft-bft-rats-kat-05, 21 November 2024, . [I-D.fossati-tls-attestation] Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I., Deshpande, Y., Niemi, A., and T. Fossati, "Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", Work in Progress, Internet-Draft, draft-fossati-tls-attestation-08, 21 October 2024, . [I-D.ietf-lamps-csr-attestation] Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M., and N. Smith, "Use of Remote Attestation with Certification Signing Requests", Work in Progress, Internet-Draft, draft-ietf-lamps-csr-attestation-16, 1 February 2025, . [I-D.ietf-rats-msg-wrap] Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-11, 15 November 2024, . [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, . [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", RFC 4211, DOI 10.17487/RFC4211, September 2005, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . 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 Mike Ounsworth Entrust Limited 2500 Solandt Road – Suite 100 Ottawa, Ontario K2K 3G5 Canada Email: mike.ounsworth@entrust.com Jean-Pierre Fiset Crypto4A Inc. 1550A Laperriere Ave Ottawa, Ontario K1Z 7T2 Canada Email: jp@crypto4a.com Hannes Tschofenig University of Applied Sciences Bonn-Rhein-Sieg Germany Email: Hannes.Tschofenig@gmx.net Henk Birkholz Fraunhofer SIT Email: henk.birkholz@ietf.contact Monty Wiseman Beyond Identity United States of America Email: monty.wiseman@beyondidentity.com Ned Smith Intel Corporation United States of America Email: ned.smith@intel.com