Evidence Encoding for Hardware Security Modules

Evidence Encoding for Hardware Security Modules Crypto4A Inc.

1550A Laperriere Ave Ottawa, Ontario K1Z 7T2 Canada jp@crypto4a.com

Cryptic Forest Software

Sioux Lookout Canada mike@ounsworth.ca

University of the Bundeswehr Munich

Neubiberg Bavaria 85579 Germany hannes.tschofenig@gmx.net

Fraunhofer SIT

henk.birkholz@ietf.contact

United States of America monty@iomt.dev

United States ned.smith.ietf@gmail.com

Security RATS Internet-Draft RATS PKIX HSM This document specifies a vendor-agnostic format for Evidence produced and verified within a PKIX context. The Evidence produced this way includes claims collected about a cryptographic module, such as a Hardware Security Module (HSM), and elements found within it such as cryptographic keys. One scenario envisaged is that the state information about the cryptographic module can be securely presented to a remote operator or auditor in a vendor-agnostic verifiable format. A more complex scenario would be to submit this Evidence to a Certification Authority to aid in determining whether the storage properties of this key meet the requirements of a given certificate profile. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the RATS Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies a vendor-neutral Evidence format for remote attestation in PKIX-based environments, with a focus on hardware security modules (HSMs) and cryptographic keys managed by such devices. The format enables an Attester to convey measured platform and key properties to a Verifier and, ultimately, to a Relying Party in a form that integrates with existing X.509-based trust infrastructures. Concretely, this specification defines:

an ASN.1/DER Evidence envelope containing a to-be-signed section, one or more signature blocks, and optional intermediate certificates;
an element-and-claim data model organized around transaction, platform, and key elements, identified by OIDs;
encoding and signature-verification processing rules for PKIX Evidence.

The design is intentionally PKIX-native. ASN.1 and DER are used to align with existing certificate tooling, certification authority workflows, and HSM implementations where non-ASN.1 formats are less common. This document does not define a transport protocol for carrying Evidence, does not define Verifier appraisal policy, and does not standardize device-internal authentication/authorization mechanisms. It defines the data model and cryptographic container so that such mechanisms can be applied consistently across deployments.

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

Continuous Assurance There are situations where it is necessary to verify the current running state of an HSM as part of operational or auditing procedures. For example, there are devices that are certified to work in an environment only if certain versions of the firmware are loaded or only if user keys are protected with specific policies. The Evidence format offered by this specification allows a platform to report its firmware level along with other collected claims necessary in critical deployments.

Key import and HSM clustering Consider that an HSM is being added to a logical HSM cluster. Part of the onboarding process involves the newly-added HSM providing Evidence of its running state, for example that it is a genuine device from the same manufacturer as the existing clustered HSMs, firmware patch level, FIPS mode, etc. It could also be required to provide information about any system-level keys required to establish secure cluster communication. In this scenario, the Verifier and Relying Party will typically be other HSMs in the cluster deciding whether or not to admit the new HSM. A related scenario is when performing a key migration across HSMs. If the key being migrated is associated with certain properties, for example an environment running in FIPS mode at FIPS Level 3, and the key is set to certain protection properties such as Non-Exportable and Dual-Control, then the HSM might wish to verify that the key was previously stored under the same conditions. This specification provides an Evidence format with sufficient details to support this type of implementation across HSM vendors. These scenarios motivate the design requirements to have an ASN.1 based Evidence format and a data model that more closely matches typical HSM architecture since, as shown in both scenarios, an HSM is acting as Verifier and Relying Party.

Attesting subject of a certificate issuance Prior to a Certification Authority (CA) issuing a certificate on behalf of a subject, a number of procedures are required to verify that the subject of the certificate is associated with the key that is certified. In some cases, such as issuing a code signing certificate , a CA must ensure that the subject key is located in a Hardware Security Module (HSM). The Evidence format offered by this specification is designed to carry the information necessary for a CA to assess the location of the subject key along with a number of commonly-required attributes. More specifically, a CA could determine which HSM was used to generate the subject key, whether this device adheres to certain jurisdiction policies (such as FIPS mode) and the constraints applied to the key (such as whether it is extractable). The use of Evidence in a certification request is specified in . For relatively simple HSM devices, storage properties such as "extractable" may always be false for all keys since the devices are not capable of key export and so the Evidence could be essentially a hard-coded template asserting these immutable attributes. However, more complex HSM devices require a more elaborate Evidence format that encompasses the mutability of these attributes. Also, a client requesting a key attestation might wish to scope down the content of the produced Evidence as the HSM contains much more information than that which is relevant to the transaction. Not reducing the scope of the generated Evidence could, in some scenarios, constitute a privacy violation.

Conventions and Terminology 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 when, and only when, they appear in all capitals, as shown here. This specification uses a necessary mixture of PKI terminology and RATS Architecture definitions in order to map concepts between the two domains. The reader is assumed to be familiar with the vocabulary and concepts defined in the RATS Architecture () such as Attester, Relying Party, Verifier. The reader is assumed to be familiar with common vocabulary and concepts defined in such as certificate, signature, attribute, verification and validation. In order to avoid confusion, this document generally capitalizes RATS terms such as Attester, Relying Party, and Claim. Therefore, for example, a "Verifier" should be assumed to be an entity that checks the validity of Evidence as per , whereas a "verifier" could be a more general reference to a PKI entity that checks the validity of an X.509 certificate or other digital signature as per . The following terms are used in this document:

Attestation Key (AK):: Cryptographic key controlled solely by the Attester and used only for the purpose of producing Evidence. In other words, it is used to digitally sign the claims collected by the Attester.
Attester:: The term Attester respects the definition offered in . In this specification, it is also interchangeable with "platform" or "HSM".
Attesting Environment:: As defined in , the Attesting Environment collects the information to be represented in Claims. In practical terms, an implementation may be designed with services to perform this function. To remain consistent with the RATS Architecture, the term "Attesting Environment" is used throughout this specification.
Evidence:: The term Evidence respects the definition offered in . In this specification, it refers to claims, encoded according to the format defined within this document, and signed using Attestation Keys.
Hardware Security Module (HSM):: A physical computing device that safeguards and manages secrets, such as cryptographic keys, and performs cryptographic operations based on those secrets. This specification takes a broad definition of what counts as an HSM to include smartcards, USB tokens, TPMs, cryptographic co-processors (PCI cards) and "enterprise-grade" or "cloud-service grade" HSMs (possibly rack mounted). In this specification, it is interchangeable with "platform" or "Attester".
Key Attestation:: Process of producing Evidence containing claims pertaining to user keys found within an HSM. In general, the claims include enough information about a user key and its hosting platform to allow a Relying Party to make judicious decisions about the key, such as whether to issue a certificate for the key.
RATS:: Remote ATtestation procedureS. Refers to a working group within IETF and all the documents developed under this umbrella of efforts. This specification is developed using concepts developed in RATS but more particularly refers to the RATS Architecture as introduced in .
PKIX:: Public Key Infrastructure based on X.509 certificates. Refers to the framework of technology, policies and procedures used to manage and distribute digital certificates based on and related specifications.
Platform:: The module or device that embodies the Attester. In this specification, it is interchangeable with "Attester" or "HSM".
Platform Attestation:: Process of producing Evidence containing claims pertaining to measured values associated with the platform itself. In general, the claims include enough information about the platform to allow a Relying Party to make judicious decisions about the platform, such as those carried out during audit reviews.
Presenter:: Role that facilitates communication between the Attester and the Verifier. The Presenter initiates the operation of generating Evidence at the Attester and passes the generated Evidence to the Verifier. The interface by which the Presenter initiates Evidence generation is outside the scope of this specification.
Trust Anchor:: As defined in and , a Trust Anchor "represents an authoritative element via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative." The Trust Anchor may be a certificate, a raw public key, or other structure, as appropriate.
Trusted Platform Module (TPM):: A tamper-resistant processor generally located on a computer's motherboard used to enhance attestation functions for the hosting platform as defined by the Trusted Computing Group. TPMs are very specialized Hardware Security Modules and generally use other protocols (than the one presented in this specification) to transmit Evidence.
User Key:: A user key consists of a key hosted by an HSM (the platform) and intended to be used by a client of the HSM. Other terms used for a user key are "application key", "client key" or "operational key". The access and operations on a user key are controlled by the HSM.

Claims and measurements in generated Evidence The RATS Architecture states that Evidence is made up of claims and that a claim is "a piece of asserted information, often in the form of a name/value pair". The RATS Architecture also mentions the concept of "measurements" that "can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc., and how they are hardened." Some HSMs have a large amount of memory and can therefore contain a substantial amount of elements that can be observed independently by the Attesting Environment. Each of those elements, in turn, can contain a number of measurable attributes. A certain level of complexity arises as multiple elements of the same class can be reported simultaneously in generated Evidence. In this case, multiple similar claims are reported simultaneously but associated with different elements. For example, two independent user keys could be reported simultaneously in Evidence. Each key is associated with a SPKI (SubjectPublicKeyInfo). The measured values for the SPKI of the respective keys are different. To that end, in this specification, the claims are organized as collections where each claim is the association of a claim type with the measured value. The collections, in turn, are organized by "elements". An element represents a logical portion of the Target Environment that is observed by the Attesting Environment. Thus, an element is associated with a collection of claims. Each claim is the association of a claim type with a measured value. The grouping of claims into elements facilitates the comprehension of a large addressable space into portions recognizable by the user. More importantly, it curtails the produced Evidence to portions of the Target Environment that relate to the needs of the Verifier. See .

Attestation Key Certificate Chain The data format in this specification represents Evidence and requires third-party endorsement in order to establish trust. Part of this endorsement is a trust anchor that chains to the HSM's attestation key (AK) which signs the Evidence. In practice the trust anchor usually is a manufacturing CA belonging to the device vendor which proves that the device is genuine and not counterfeit. The trust anchor can also belong to the device operator as would be the case when the AK certificate is replaced as part of onboarding the device into a new operational environment. The AK certificate associated with the AK that signs the Evidence has the following constraints:

the certificate MUST include the Extended Key Usage (EKU) certificate extension;
the EKU certificate extension MUST include the id-kp-attestationKey, as defined in this specification; and,
the KeyUsage extension (KU) MUST have the digitalSignature bit set.

An EKU that includes only a single KeyPurposeId of id-kp-attestationKey SHOULD be marked as critical. The reasoning here is that the usage of a true attestation key is constrained by the security module it's contained by. Presenting non-attestation data for validation by this AK public key should ALWAYS fail. An EKU that includes a KeyPurposeId of id-kp-attestationKey along with other attestation-related KeyPurposeId SHOULD NOT be marked as critical. The data format specified in requires one or more SignatureBlock values. Multiple signature blocks allow one Attester identity, represented by a single subject DN, to use distinct Attestation Keys and signature algorithms. See for the processing rules.

Presenter Role This specification introduces the role of "Presenter" as shown in . The Presenter is the role that initiates the generation of Evidence. Since HSMs are generally servers (client/server relationship) or peripherals (controller/peripheral relationship), a Presenter is required to launch the process of creating the Evidence and capturing it to forward it to the Verifier.

Presenter Role | | +----------------+ Evidence(5) +------------+ ]]> The process of generating Evidence generally starts at the Verifier with the generation of a nonce. The nonce is used to ensure freshness of the Evidence and this quality is guaranteed by the Verifier. Therefore, if a nonce is used, it must be provided to the Presenter by the Verifier (1). An Attestation Request (request) is assembled by the Presenter and submitted to the HSM (2). The Attesting Environment parses the request and collects the appropriate measurements from the Target Environment (3). In the previous figure, the HSM is represented as being composed of an Attesting Environment and a Target Environment. This representation is offered as a simplified view and implementations are not required to adhere to this separation of concerns. The Attesting Environment produces Evidence based on the collected information and returns it to the Presenter for distribution (4). Finally, the Presenter forwards the Evidence to the Verifier (5). The aim of the figure is to depict the position of the Presenter as an intermediate role between the Attester and the Verifier. The role of "Presenter" is privileged as it controls the claims included in the Evidence being generated by the Attester. However, the role is not "trusted" as the Verifier does not have to take into account the participation of the Presenter as part of the function of appraising the Evidence. The attestation request is a message used by the Presenter to specify the elements and the associated claims that are included by the Attester in the generated Evidence. The nonce specified by the Verifier MUST be included in the attestation request for the Attester to include in the Evidence. The nature and format of the attestation request is not dictated by this specification.

Information Model The Evidence format is composed of two main sections:

An Evidence description which describes the list of reported elements.
A signature section where one or more digital signatures are offered to prove the origin of the Evidence description and maintain its integrity.

The details of the signature section are left to the data model. The remainder of this section deals with the way the information is organized to form the Evidence description. The Evidence description is associated with elements to help with the organization and comprehension of the information. Elements are portions of the Target Environment observed by the Attesting Environment. Each element, in turn, is associated with a collection of claims that describes the attributes of the element. Therefore, the Evidence description is composed of a set of elements and each element is composed of a claim set.

Element An element is a logical construct that refers to a portion of the Target Environment's state. It is addressable via an identifier such as a UUID or a handle (as expressed in ). In general, an element refers to a component recognized by users of the HSM, such as a user key or the platform itself. An element is composed of a type, the element type, and a collection of claims. The element type describes the class of the element while the collection of claims defines its state. An element MUST be reported at most once in an Evidence description. The Evidence description can have multiple elements of the same type (for example reporting multiple keys), but each element MUST relate to different portions of the Target Environment. It is possible for two elements to be quite similar such as in a situation where a key is imported twice in an HSM. In this case, the two related elements could be associated with similar claims. However, they are treated as different elements as they are reporting different portions of the Target Environment. The number of elements reported in an Evidence description, and their respective type, is left to the implementer. For a simple device where there is only one key, the list of reported elements could be fixed. For larger and more complex devices, the list of reported elements should be tailored to the intended use and authorized recipient of the Evidence. In particular, note that the nonce claim contained with the Transaction element is optional, and therefore it is possible that an extremely simple device that holds one static key could have its Evidence generated at manufacturing time and injected statically into the device instead of being generated on-demand. This model would essentially off-board the Attesting Environment to be part of the manufacturing infrastructure. In the RATS Architecture, this configuration would refer to the information provided this way as an Endorsement provided by the manufacturer as opposed to Evidence generated by the HSM.

Element Type An element is defined by its type. This specification defines three element types:

Platform : This element holds claims that describe the state of the platform (or device) itself. Elements of this type hold claims that are global in nature within the Target Environment.
Key : The elements of this type represent a cryptographic key protected within the Target Environment and hold claims that describe that specific key.
Transaction : This element is abstract in nature since it is associated with claims that do not describe portions of the Target Environment. Instead, these claims relate to the Evidence-generation transaction, such as a nonce to support freshness.

Although this document defines a short list of element types, this list is extensible to allow implementers to report on elements found in their implementation and not covered by this specification. By using Object Identifiers (OIDs) for specifying element types and claim types, this format is inherently extensible; implementers of this specification MAY define new custom or proprietary element types and place them alongside the standardized elements, or define new claim types and place them inside standardized elements. Verifiers SHOULD ignore and skip over unrecognized element or claim types and continue processing normally. In other words, if a given Evidence would have been acceptable without the unrecognized elements or claims, then it SHOULD still be acceptable with them.

Claim Type Each claim found in an element is composed of a claim type and a value. Each claim describes a portion of the state from the associated element. For example, a platform element could have a claim which indicates the firmware version currently running. Another example is a key element with a claim that reports whether the key is extractable or not. A value provided by a claim is to be interpreted within the context of its element and in relation to the claim type. A claim type MUST be defined for a specific element type to reduce confusion when it comes to interpretation of the value. In other words, a specific claim type MUST NOT be used by multiple element types. For example, if a concept of "revision" is applicable to a platform and a key, the claim for one element type (platform revision) should have a different identifier from the one for the other element type (key revision). The nature of the value (boolean, integer, string, bytes) and its format are dependent on the claim type. This specification defines a limited set of claim types. However, the list is extensible through the IANA registration process or private OID allocation, enabling implementers to report additional claims not covered by this specification. The number of claims reported within an element, and their respective type, is left to the implementer. For a simple device, the reported list of claims for an element might be fixed. However, for larger and more complex devices, the list of reported claims should be tailored to the intended use and authorized recipient of the Evidence. Claims of a particular type MAY be repeated within an element while others MUST NOT. For example, for a platform element, there can only be one "firmware version" claim. Therefore, the associated claim MUST NOT be repeated as it may lead to confusion. Other claim definitions can allow multiple independent values. Therefore, the definition of a claim specifies whether or not multiple copies of that claim are allowed within an element's claim set. If a Verifier detects, within a single element, multiple copies of a claim type that should not be repeated, it MUST reject the Evidence as malformed. Since a Verifier is encouraged to ignore unrecognized claim types, it is possible that a potential rejection is missed. If a Verifier encounters, within the context of an element, a repeated claim for a type where it is allowed, it MUST treat each one as an independent claim and MUST NOT consider later ones to overwrite the previous one.

Data Model This section describes the data model associated with generated Evidence. For ease of deployment within the target ecosystem, ASN.1 definitions and DER encoding are used. A complete ASN.1 module is provided in . The top-level structures, as ASN.1 fragments, are: An Evidence message is composed of a protected section known as the To-Be-Signed (TBS) section. The TbsEvidence corresponds to the "Evidence Description" referred to in . The integrity of the TBS section is ensured with one or multiple cryptographic signatures over the content of this section. There is a provision to carry X.509 certificates supporting each signature. The SEQUENCE OF SignatureBlock supports algorithm agility by allowing the same Attester identity to sign the TBS section with multiple Attestation Keys. When more than one SignatureBlock is present, each signing certificate represents the same Attester identity with the same subject Distinguished Name (DN), but contains a distinct SPKI. The TBS section is composed of a version number, to ensure future extensibility, and a sequence of reported elements. For compliance with this specification, TbsEvidence.version MUST be 1. This envelope format is not extensible; future specifications which make compatibility-breaking changes MUST increment the version number. A SignatureBlock is included for each signature submitted against the TBS section. The SignatureBlock includes the signature algorithm (signatureAlgorithm) and the signature itself (signatureValue). It also includes information to identify the authority that provided the signature which is the structure SignerIdentifier (sid). The signer identifier includes a combination of X.509 certificate, SubjectPublicKeyInfo (SPKI) and/or key identifier (keyId). It is expected that an X.509 certificate will be generally used, as it provides the public key needed to verify the signature and clearly identifies the subject that provided the signature. The SPKI and keyId are allowed to support environments where X.509 certificates are not used. The field SignerIdentifier.keyId is not constrained to specific details. It is an identifier that is shared between the Attester and the Verifier to establish which public key should be used during the verification of a signature block. The fields SignerIdentifier.subjectPublicKeyInfo and SignerIdentifier.certificate are encouraged as these fields have specific syntax and semantics. When SignerIdentifier.keyId is used without a certificate or SPKI, the Verifier MUST obtain the corresponding public key by some implementation-specific or out-of-band mechanism before it can validate the signature. The optional certificate list provided in Evidence.intermediateCertificates enables the insertion of X.509 certificates to support trusting the signatures found in signature blocks. This information is intended to provide the certificates required by the Verifier to validate the endorsement on the certificates included with the signatures. intermediateCertificates MAY include any or all intermediate CA certificates needed to build paths. It is not required to include trust anchors. Order is not significant. As described in , the TbsEvidence is a collection of elements. Each element is associated with a type that defines its class. The element types are represented by object identifiers (OIDs). The following ASN.1 fragment defines the structures associated with elements: In turn, elements are composed of a collection of claims. Each claim is composed of a type and a value. The claim types are represented by object identifiers (OIDs). The following ASN.1 fragment defines the structures associated with claims: The ClaimSet object set in the complete ASN.1 module is extensible. This allows future or proprietary claim types to be encoded without changing the ReportedClaim syntax. A Verifier that does not recognize a claim type SHOULD ignore that claim as described in , unless local policy requires rejection. Every reported claim contains a value. Each claim type SHOULD be associated with a single element type. Therefore, it is encouraged to define claim types grouped with their respective element type. The nature of a claim value is dictated by the claim type. When a claim type is defined, the definition must include the type of the value, its semantics and interpretation. The following ASN.1 fragment illustrates how a claim is associated with a type, in this case the OID id-evidence-claim-transaction-nonce and the expected data format (OCTET STRING). The remainder of this section describes the element types and their associated claims.

Platform Element A platform element reports information about the device where the Evidence is generated and is composed of a collection of claims that are global to the Target Environment. It is associated with the type identifier id-evidence-element-platform. A platform element, if provided, MUST be included only once within the generated Evidence. If a Verifier encounters multiple elements of type id-evidence-element-platform, it MUST reject the Evidence as malformed. The following table lists the claims for a platform element (platform claims) defined within this specification. In cases where the claim is borrowed from another specification, the "Reference" column refers to the specification where the semantics for the claim value can be found.

Claim Type	Reference	Multiple?	OID
vendor	RFCthis	No	id-evidence-claim-platform-vendor
oemid		No	id-evidence-claim-platform-oemid
hwmodel		No	id-evidence-claim-platform-hwmodel
hwversion		No	id-evidence-claim-platform-hwversion
hwserial	RFCthis	No	id-evidence-claim-platform-hwserial
swname		No	id-evidence-claim-platform-swname
swversion		No	id-evidence-claim-platform-swversion
dbgstat		No	id-evidence-claim-platform-dbgstat
uptime		No	id-evidence-claim-platform-uptime
bootcount		No	id-evidence-claim-platform-bootcount
fipsboot		No	id-evidence-claim-platform-fipsboot
fipsver		No	id-evidence-claim-platform-fipsver
fipslevel		No	id-evidence-claim-platform-fipslevel
fipsmodule		No	id-evidence-claim-platform-fipsmodule
ccmoduleid	RFCthis	No	id-evidence-claim-platform-ccmoduleid
ccboot	RFCthis	No	id-evidence-claim-platform-ccboot
ccscheme		No	id-evidence-claim-platform-ccscheme
ccrequirement		No	id-evidence-claim-platform-ccrequirement
cceallevel		No	id-evidence-claim-platform-cceallevel

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

vendor A human-readable string that reports the name of the device's manufacturer. This field is for informational purposes only and should not be used in any automated mechanism to compare the Evidence. For the purposes of comparison, the claims oemid and hwmodel should be used. If the device is submitted to FIPS validation, this string should correspond to the vendor field of the submission.

oemid, hwmodel, hwversion, swname, swversion, dbgstat, uptime, bootcount These claims are defined in and are reused in this specification for interoperability. Small descriptions are offered for each to ease the reading of this specification. In case of confusion between the description offered here and the one in , the definition offered in the latter shall prevail. The claim "oemid" uniquely identifies the Original Equipment Manufacturer (OEM) of the HSM. This is a sequence of bytes and is not meant to be a human readable string. The claim "hwmodel" differentiates models, products, and variants manufactured by a particular OEM. A model must be unique within a given "oemid". This is a sequence of bytes and is not meant to be a human readable string. The claim "hwversion" is a text string reporting the version of the hardware. This claim must be interpreted along with the claim "hwmodel". The claim "swname" is a text string reporting the name of the firmware running on the platform. The claim "swversion" differentiates between the various revisions of a firmware offered for the platform. This is a string that is expected to be human readable. The claim "dbgstat" refers to the state of the debug facilities offered by the HSM. This is an integer value describing the current state as described in . The claim "uptime" reports the number of seconds that have elapsed since the HSM was last booted. The claim "bootcount" reports the number of times the HSM was booted.

hwserial A human-readable string that reports the serial number of the hardware module. This serial number often matches the number engraved on the case or on an applied sticker.

fipsboot, fipsver, fipslevel and fipsmodule FIPS 140-3 CMVP validation places stringent requirements on the mode of operation of the device and the cryptography offered by the module, including restricting cryptographic services to approved (or explicitly allowed) security functions, certain requirements on entropy sources, and extensive start-up self-tests. FIPS 140-3 offers compliance levels 1 through 4 with increasingly strict requirements. Many HSMs include a configuration setting that allows the device to be taken out of FIPS mode and thus enable additional functionality or performance, and some offer configuration settings to change between compliance levels. adopts the requirements of (2012 edition). In this specification, "FIPS mode" refers to the "approved mode of operation" and "compliance level" refers to the "security level", both as defined in . Guidance on how a module indicates that it is operating in the approved mode is provided in . The module name and overall security level of a validated module are documented in its Security Policy, whose content is specified in . The boolean claim fipsboot indicates whether the device is currently operating in FIPS mode. When the claim value is "true", the HSM is running in compliance with the FIPS 140 restrictions. If the value of this claim is "false", then the HSM is not restricted to the behavior limited by compliance. A fipsboot value of "true" indicates that the module is in an approved mode of operation as described in its Security Policy. It is not, by itself, the per-service indicator required by section 7.2.4.2. As clarified in IG 2.4.C, a module-level indicator satisfies that requirement only when the module, in that mode, prevents the use of any non-approved service. The textual claim fipsver indicates the version of the FIPS CMVP specification with which the device's operational mode is compliant. At the time of writing, the string "FIPS 140-3" SHOULD be used; devices operating under the legacy specification MAY report "FIPS 140-2". The integer claim fipslevel indicates the overall compliance level to which the device is currently operating and MUST only be 1, 2, 3, or 4. The fipslevel claim has no meaning if fipsboot is absent or false. The claim fipsmodule is a textual field used to represent the name of the module that was submitted to CMVP for validation. The information derived by combining this claim with the vendor name shall be sufficient to find the associated records in the CMVP database. The FIPS status information found in Evidence indicates only the mode of operation of the device and is not authoritative of its validation status. This information is available in the NIST CMVP database of validated modules or by contacting the device vendor. As an example, some devices may have the option to enable FIPS mode in configuration even if the vendor has not submitted this model for validation. As another example, a device may be running in a mode consistent with FIPS Level 3 but the device was only validated at Level 2. A Relying Party wishing to know the validation status of the device MUST couple the device state information contained in the Evidence with a valid FIPS CMVP certificate for the device.

ccmoduleid, ccboot, ccscheme, ccrequirement and cceallevel Common Criteria certification schemes place stringent requirements on the mode of operation of the device and the cryptography offered by the module, including only enabling a restricted set of algorithms, key sizes and modes (e.g., only the algorithms listed in the Security Target of the device), certain requirements on entropy sources, and extensive start-up self-tests. Common Criteria offers Evaluation Assurance Levels (EAL) from EAL1 to EAL7, with increasingly strict requirements, optionally augmented with additional assurance components (see ). This specification signals augmentation with a trailing "+" sign, following common industry practice. Many HSMs include a configuration setting that allows the device to be taken out of its certified mode and thus enable additional functionality or performance, and some offer configuration settings to change between compliance levels. In this section, the evaluation, validation or certification scheme is referred to simply as the "certification scheme", and the evaluation, validation or certification of a module is referred to simply as its "certification". The claim ccmoduleid is a textual field used to represent the name of the module that was submitted to the certification scheme for certification. The information derived by combining this claim with the vendor name shall be sufficient to manually find the associated records in the certification databases. The boolean claim ccboot indicates whether the device was booted in, and has been continuously operating in, the Common Criteria certified mode. Among other restrictions, this means that only the restricted algorithm set is available. When the claim value is "true", the HSM has been running in compliance with the claimed restrictions since its last boot. If the value of this claim is "false", then the HSM is not restricted to the behavior limited by Common Criteria compliance; the claims ccscheme, ccrequirement and cceallevel then have no meaning and SHOULD be omitted. The textual claim ccscheme indicates the name and the version of the certification scheme specification with which the device's operational mode is compliant. At the time of writing, the strings "ISO15408 v3.1r5", "ISO15408:2022", "ISO15408:2026", "CCRA v3.1r5", "CCRA:2022" and "EUCC" are defined, but any other scheme can be named if the intended Verifier has knowledge about it. The textual claim ccrequirement indicates the name and the version of the requirements with which the device's operational mode is compliant. For the Common Criteria schemes, a particular Protection Profile or a proprietary Security Target is the requirement to be satisfied. At the time of writing, when the value of ccscheme begins with "ISO15408", "CCRA" or "EUCC", the values "EN 419 221-5:2018", "EN 419 241-2:2019" and "SecurityTarget:STversion" (where "STversion" is replaced with the exact version of the Security Target of the device) are defined, but any other requirement, specification or standard can be named if the intended Verifier has knowledge about it. The textual claim cceallevel indicates the assurance level of the certification under which the device is currently operating. When the value of ccscheme begins with "ISO15408", "CCRA" or "EUCC", cceallevel describes the Evaluation Assurance Level achieved (see ) and MUST use the following syntax, expressed in EBNF: Valid examples are "EAL1", "EAL4+AVA_VAN.5" and "EAL4+AVA_VAN.5,ALC_FLR.3".

Key Element A key element is associated with the type id-evidence-element-key. Each instance of a key element represents a different addressable key found in the Target Environment. There can be multiple key elements found in Evidence, but each reported key element MUST describe a different key observed from the Target Environment. Two key elements may represent the same underlying cryptographic key (keys with the exact same value) but they must be different portions of the Target Environment. A key element is composed of a collection of claims relating to the cryptographic key. At minimum, a key element MUST report the claim "identifier" to uniquely identify this cryptographic key from any others found in the same Target Environment. A Verifier that detects Evidence with multiple key elements referring to the same addressable key MUST reject the Evidence. The following table lists the claims for a key element defined within this specification. The "Reference" column refers to the specification where the semantics for the claim can be found.

Claim Type	Reference	Multiple?	OID
identifier	RFCthis	Yes	id-evidence-claim-key-identifier
spki	RFCthis	No	id-evidence-claim-key-spki
extractable		No	id-evidence-claim-key-extractable
sensitive		No	id-evidence-claim-key-sensitive
never-extractable		No	id-evidence-claim-key-never-extractable
local		No	id-evidence-claim-key-local
device-bound	RFCthis	No	id-evidence-claim-key-device-bound
expiry	RFCthis	No	id-evidence-claim-key-expiry
purpose	RFCthis	No	id-evidence-claim-key-purpose

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

identifier A human-readable string that uniquely identifies the cryptographic key. This value often contains a UUID but could also have a numeric value expressed as text or any other textual description. This claim MAY be repeated as some environments have more than one way to refer to a cryptographic key.

spki The value of this claim is the SubjectPublicKeyInfo (see ) associated with the cryptographic key.

extractable, sensitive, never-extractable, local These claims are defined as key attributes in and reused in this specification for interoperability. Small descriptions are offered for each to ease the reading of this specification. In case of confusion between the description offered here and the one in , the definition offered in the latter shall prevail. The claim "extractable" indicates that the key can be exported from the HSM. Corresponds directly to the attribute CKA_EXTRACTABLE found in PKCS#11. The claim "sensitive" indicates that the value of the key cannot leave the HSM in plaintext. Corresponds directly to the attribute CKA_SENSITIVE found in PKCS#11. The claim "never-extractable" indicates if the key was never extractable from the HSM throughout the life of the key. Corresponds directly to the attribute CKA_NEVER_EXTRACTABLE found in PKCS#11. The claim "local" indicates whether the key was generated locally or imported. Corresponds directly to the attribute CKA_LOCAL found in PKCS#11.

device-bound The boolean claim device-bound indicates whether the key is unique to the device on which it is hosted. When the claim value is "true", the device asserts that:

the key was generated on the device;
the key has never been exported from the device, in any form; and,
the device offers no means to export the key in the future. This includes, but is not limited to, export in plaintext, export wrapped by another key, backup, cloning, and migration to another device.

The assertion applies to every means by which the key could leave the device, whether or not this specification defines a claim for it. In particular, a device that reports device-bound as "true" asserts that none of the following can reveal the key or let it be reconstructed outside the device:

vendor-specific or proprietary mechanisms, including mechanisms not defined by PKCS#11 or any other standard API;
splitting the key into shares or components (for example, M-of-N secret sharing), even if no single share reveals the key;
administrative, maintenance, recovery or manufacturer interfaces, including interfaces available only to the vendor;
debug interfaces, diagnostic modes, firmware updates or changes to the device's configuration or operating mode; and,
exporting any value from which the key can be derived or recomputed outside the device.

A device that cannot make this assertion for all export mechanisms, including those it may enable in the future, MUST NOT report device-bound as "true". When the value of this claim is "false", the device makes no such assertion. A value of "false" does not by itself indicate that the key is extractable or was imported. A key for which device-bound is "true" can be understood as having attributes that the key claims "local", "extractable" and "never-extractable" express individually with the values "true", "false" and "true" respectively, but with the additional guarantee that no configuration change or future operation can make the key leave the device. If a key element reports device-bound as "true" along with any of the claims "local", "extractable" or "never-extractable" with a contradicting value, a Verifier MUST reject the Evidence as malformed.

expiry Reports a time after which the key is not to be used. The device MAY enforce this policy based on its internal clock. Note that security considerations should be taken relating to HSMs and their internal clocks. See .

purpose Reports the key purposes, also referred to as key capabilities, associated with the subject key. Since multiple purposes can be associated with a single key, the value of this claim is a list of purposes, each reported as an object identifier (OID). The value of this claim is the DER encoding of the following structure: The following table describes the key purposes defined in this specification. The key purposes offered are based on key attributes provided by PKCS#11. Each purpose is assigned an object identifier (OID).

Capability	PKCS#11	OID
encrypt	CKA_ENCRYPT	id-evidence-key-capability-encrypt
decrypt	CKA_DECRYPT	id-evidence-key-capability-decrypt
wrap	CKA_WRAP	id-evidence-key-capability-wrap
unwrap	CKA_UNWRAP	id-evidence-key-capability-unwrap
sign	CKA_SIGN	id-evidence-key-capability-sign
sign-recover	CKA_SIGN_RECOVER	id-evidence-key-capability-sign-recover
verify	CKA_VERIFY	id-evidence-key-capability-verify
verify-recover	CKA_VERIFY_RECOVER	id-evidence-key-capability-verify-recover
derive	CKA_DERIVE	id-evidence-key-capability-derive
decapsulate	CKA_DECAPSULATE	id-evidence-key-capability-decapsulate
encapsulate	CKA_ENCAPSULATE	id-evidence-key-capability-encapsulate

The use of an object identifier to report a purpose allows third parties to extend this list to support implementations that have other key purposes.

Transaction Element A transaction element is associated with the type id-evidence-element-transaction. This is an abstract element and does not relate to any state found in the Target Environment. Instead, it groups together claims that relate to the generation of the Evidence. For example, a Verifier can supply a nonce for the generation of Evidence. This nonce is included in the Evidence to support the freshness of the Evidence. The nonce is not related to any portion of the Target Environment and the transaction element is used to gather those values into claims. A transaction element, if provided, MUST be included only once within the reported elements. If a Verifier detects multiple elements of type id-evidence-element-transaction, it MUST reject the Evidence. The following table lists the claims for a transaction element defined within this specification. The "Reference" column refers to the specification where the semantics for the claim value can be found.

Claim Type	Reference	Multiple?	OID
nonce		No	id-evidence-claim-transaction-nonce
timestamp		No	id-evidence-claim-transaction-timestamp
ak-spki	RFCthis	Yes	id-evidence-claim-transaction-ak-spki

nonce The claim nonce is used to provide "freshness" quality as to the generated Evidence. If a nonce is used, it MUST be generated by the Verifier and conveyed to the Attester, possibly through a Presenter. The Attester MUST include the nonce unchanged in the generated Evidence. The mechanism by which the nonce is conveyed to the Attester is outside the scope of this specification. This claim is similar to the "eat_nonce" as defined in . According to that specification, this claim may be specified multiple times with different values. However, within the scope of this specification, the "nonce" value can be specified only once within a transaction.

timestamp The time at which the Evidence was generated, according to the internal system clock of the Attesting Environment. This is similar to the "iat" claim in . Note that security considerations should be taken relating to the evaluation of timestamps generated by HSMs. See .

ak-spki This claim contains the Subject Public Key Information (SPKI) for the attestation key used to sign the Evidence. The claim value is of type SubjectPublicKeyInfo, as defined for X.509 certificates in . This transaction claim is used to bind the content of the Evidence with the key(s) used to sign that Evidence. The importance of this binding is discussed in . This claim can be reported multiple times. Each included claim MUST refer to a different attestation key. In other words, this claim should be repeated only if multiple attestation keys are used to sign the Evidence.

Additional Element and Claim Types It is expected that HSM vendors will register additional Element and Claim types by assigning OIDs from their own proprietary OID arcs to hold data describing additional proprietary key properties. When new element and claim types are used, documentation similar to the one produced in this specification SHOULD be distributed to explain the semantics of the claims and the frequency that values can be provided. See and for handling of unrecognized custom types.

Encoding The structure Evidence is to be DER encoded . If a textual representation is required, then the DER encoding MAY be subsequently encoded into Standard Base64 as defined in . PEM-like representations are also allowed where a MIME-compliant Base64 transformation of the DER encoding is used, provided that the header label is "EVIDENCE". For example:

Processing This section deals with the exchanges between the Presenter, the Attester and the Verifier during the request, generation and consumption of Evidence as defined in this specification. The architecture as shown in should be used as a reference for this section.

Initiation from Presenter The Presenter assembles a request to initiate the generation of Evidence by the Attester. This request selects the elements and the claims that are to be included in the generated Evidence. Ultimately, the generated Evidence is consumed by the Verifier. Therefore, a certain level of coordination is required between the Presenter and the Verifier so that the generated Evidence includes the necessary information for the specific purpose. The nonce used during the generation of Evidence is used to determine the freshness of the included information. Since the freshness is guaranteed by the Verifier, the nonce is generally selected by the Verifier. If the Verifier generates the nonce, then it must be transmitted to the Presenter prior to making the request. It is possible to devise schemes where a Presenter and a Verifier would agree to use a central "bell" as nonce, alleviating the need to transmit the nonce between the two parties prior to the generation of the Evidence. Finally, in the case where an Attester has multiple attestation keys, the Presenter needs to select the attestation key(s) that are required by the Verifier.

Generation of Evidence Upon receiving a request, the Attesting Environment verifies the validity of the request. This specification RECOMMENDS that:

An Attesting Environment fails a request if it contains an unrecognized element. This is to ensure that all the semantics expected by the Presenter are fully understood by the Attesting Environment.
An Attesting Environment ignores unrecognized claim types for a specific element. In this situation, the Attesting Environment is expected not to include the claim as part of the response. This guidance is intended to increase the likelihood of interoperability between tools of different vendors.
An Attesting Environment includes only elements and claims in the generated Evidence if these elements and claims were specified as part of the request. This is to give control to the Presenter as to what information is disclosed by the Attesting Environment.
An Attesting Environment fails a request if the Presenter does not have the appropriate access rights to the elements or claims included in the request.

The Attesting Environment collects the necessary information from the Target Environment and assembles the TbsEvidence structure. During the assembly of TbsEvidence, the Attesting Environment MUST:

include the nonce (if present) provided by the Presenter to the transaction element using the claim claim-transaction-nonce; and,
add a claim of type claim-transaction-ak-spki to the transaction element to represent each attestation key selected to sign the Evidence.

For each selected attestation key, the Attesting Environment generates a signature over the DER encoding of the structure TbsEvidence. Each signature is captured in a structure of type SignatureBlock. Each signature block is augmented with the appropriate information identifying the attestation key used to generate the signature. Finally, the structure Evidence is assembled by combining the structures TbsEvidence and SignatureBlock. The Attesting Environment MAY add intermediate certificates required by the Verifier to ascertain the validity of the provided signatures.

Verification by Presenter This sub-section describes the considerations that are relevant when a Presenter receives Evidence from the Attester (the HSM) prior to distribution. A Presenter is expected to review the Evidence produced by an Attester for fitness prior to distribution. A Presenter is expected not to disclose Evidence if it contains information it cannot parse. This restriction applies to element types and claim types. This is to ensure that the information provided by the Attester can be evaluated by the Presenter. A Presenter is expected not to disclose Evidence if it contains elements other than the ones that were requested of the Attester. This is to ensure that only the selected elements are exposed to the Verifier. A Presenter is expected not to disclose Evidence if it contains an element with a claim that was not requested of the Attester. This is to ensure that only the selected information is disclosed to the Verifier. Further privacy concerns are discussed in .

Verification Procedures This sub-section describes the considerations to be taken by the Verifier when handling Evidence generated under this specification. If SignerIdentifier.certificate is present, the signature MUST be validated with the subject public key of that end-entity X.509 certificate. If SignerIdentifier.subjectPublicKeyInfo is present, the signature MUST be validated with that public key. If SignerIdentifier.keyId is present, the Verifier MUST obtain the corresponding public key by some implementation-specific or out-of-band mechanism; if no such key can be obtained, the SignatureBlock MUST be treated as unverifiable and the Evidence MUST be rejected. The certificate-based mode remains the preferred form in PKIX deployments because it provides both the public key and an X.509 identity. Verifiers MUST ensure, prior to accepting the signature associated with an end-entity certificate, that:

the certificate contains the KeyUsage (KU) extension with the digitalSignature bit set; and,
the certificate contains the Extended Key Usage (EKU) extension that includes the id-kp-attestationKey usage.

Verifiers MAY also use Evidence.intermediateCertificates to build a certification path from the end-entity certificate to a trust anchor. Each SignatureBlock is evaluated independently. A Verifier MUST successfully validate at least one SignatureBlock using an algorithm and certification path acceptable under its appraisal policy. A Verifier MAY validate additional SignatureBlock values when it supports their algorithms. The presence of a signature made with an algorithm that is unsupported or unacceptable to the Verifier does not make an otherwise acceptable signature invalid. A Verifier MUST reject Evidence when multiple signing certificates do not represent the same Attester identity as described above. If any transaction.ak-spki claims are present, the Verifier SHOULD verify that each SignerIdentifier's SubjectPublicKeyInfo (or the SPKI of its certificate) matches at least one ak-spki value. Each such claim is authoritative only when it is backed by a successfully verified SignatureBlock using the corresponding attestation key. An ak-spki claim that is not matched by a valid signature block MUST NOT by itself be treated as proof that the corresponding key was used to sign the Evidence.

ASN.1 Module PKIX-Evidence-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix-evidence-2025(TBDMOD1) } DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS ALL ; IMPORTS AlgorithmIdentifier{}, SIGNATURE-ALGORITHM FROM AlgorithmInformation-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5)mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } Certificate, SubjectPublicKeyInfo FROM PKIX1Explicit-2009 -- in [RFC5912] { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } ; -- OID Arc id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- Attestation Key Extended Key Usage -- id-kp-attestationKey OBJECT IDENTIFIER ::= { id-kp TBDMOD2 } -- Evidence -- Evidence ::= SEQUENCE { tbs TbsEvidence, signatures SEQUENCE SIZE (1..MAX) OF SignatureBlock, intermediateCertificates [0] SEQUENCE OF Certificate OPTIONAL -- As defined in RFC 5912 } SignatureBlock ::= SEQUENCE { sid SignerIdentifier, signatureAlgorithm AlgorithmIdentifier { SIGNATURE-ALGORITHM, { ... } }, signatureValue OCTET STRING } SignerIdentifier ::= SEQUENCE { keyId [0] EXPLICIT OCTET STRING OPTIONAL, subjectPublicKeyInfo [1] EXPLICIT SubjectPublicKeyInfo OPTIONAL, -- As defined in RFC 5912 certificate [2] EXPLICIT Certificate OPTIONAL -- As defined in RFC 5912 } ( WITH COMPONENTS { ..., keyId PRESENT} | WITH COMPONENTS { ..., subjectPublicKeyInfo PRESENT } | WITH COMPONENTS { ...,certificate PRESENT } ) TbsEvidence ::= SEQUENCE { version INTEGER, reportedElements SEQUENCE SIZE (1..MAX) OF ReportedElement } ReportedElement ::= SEQUENCE { elementType OBJECT IDENTIFIER, claims SEQUENCE SIZE (1..MAX) OF ReportedClaim } CLAIM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type } WITH SYNTAX { ID &id WITH TYPE &Type } ReportedClaim ::= SEQUENCE { claimType CLAIM.&id ({ClaimSet}), value CLAIM.&Type ({ClaimSet}{@claimType}) } ClaimSet CLAIM ::= { claim-transaction-nonce | claim-transaction-timestamp | claim-transaction-ak-spki | claim-platform-vendor | claim-platform-oemid | claim-platform-hwmodel | claim-platform-hwversion | claim-platform-hwserial | claim-platform-swname | claim-platform-swversion | claim-platform-dbgstat | claim-platform-uptime | claim-platform-bootcount | claim-platform-fipsboot | claim-platform-fipsver | claim-platform-fipslevel | claim-platform-fipsmodule | claim-platform-ccmoduleid | claim-platform-ccboot | claim-platform-ccscheme | claim-platform-ccrequirement | claim-platform-cceallevel | claim-key-identifier | claim-key-spki | claim-key-extractable | claim-key-sensitive | claim-key-never-extractable | claim-key-local | claim-key-device-bound | claim-key-expiry | claim-key-purpose, ... } id-evidence OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) TBDMOD3 } id-evidence-element OBJECT IDENTIFIER ::= { id-evidence 0 } id-evidence-element-transaction OBJECT IDENTIFIER ::= { id-evidence-element 0 } id-evidence-element-platform OBJECT IDENTIFIER ::= { id-evidence-element 1 } id-evidence-element-key OBJECT IDENTIFIER ::= { id-evidence-element 2 } id-evidence-claim OBJECT IDENTIFIER ::= { id-evidence 1 } id-evidence-claim-transaction OBJECT IDENTIFIER ::= { id-evidence-claim 0 } id-evidence-claim-transaction-nonce OBJECT IDENTIFIER ::= { id-evidence-claim-transaction 0 } id-evidence-claim-transaction-timestamp OBJECT IDENTIFIER ::= { id-evidence-claim-transaction 1 } id-evidence-claim-transaction-ak-spki OBJECT IDENTIFIER ::= { id-evidence-claim-transaction 2 } id-evidence-claim-platform OBJECT IDENTIFIER ::= { id-evidence-claim 1 } id-evidence-claim-platform-vendor OBJECT IDENTIFIER ::= { id-evidence-claim-platform 0 } id-evidence-claim-platform-oemid OBJECT IDENTIFIER ::= { id-evidence-claim-platform 1 } id-evidence-claim-platform-hwmodel OBJECT IDENTIFIER ::= { id-evidence-claim-platform 2 } id-evidence-claim-platform-hwversion OBJECT IDENTIFIER ::= { id-evidence-claim-platform 3 } id-evidence-claim-platform-hwserial OBJECT IDENTIFIER ::= { id-evidence-claim-platform 4 } id-evidence-claim-platform-swname OBJECT IDENTIFIER ::= { id-evidence-claim-platform 5 } id-evidence-claim-platform-swversion OBJECT IDENTIFIER ::= { id-evidence-claim-platform 6 } id-evidence-claim-platform-dbgstat OBJECT IDENTIFIER ::= { id-evidence-claim-platform 7 } id-evidence-claim-platform-uptime OBJECT IDENTIFIER ::= { id-evidence-claim-platform 8 } id-evidence-claim-platform-bootcount OBJECT IDENTIFIER ::= { id-evidence-claim-platform 9 } id-evidence-claim-platform-fipsboot OBJECT IDENTIFIER ::= { id-evidence-claim-platform 10 } id-evidence-claim-platform-fipsver OBJECT IDENTIFIER ::= { id-evidence-claim-platform 11 } id-evidence-claim-platform-fipslevel OBJECT IDENTIFIER ::= { id-evidence-claim-platform 12 } id-evidence-claim-platform-fipsmodule OBJECT IDENTIFIER ::= { id-evidence-claim-platform 13 } id-evidence-claim-platform-ccmoduleid OBJECT IDENTIFIER ::= { id-evidence-claim-platform 14 } id-evidence-claim-platform-ccboot OBJECT IDENTIFIER ::= { id-evidence-claim-platform 15 } id-evidence-claim-platform-ccscheme OBJECT IDENTIFIER ::= { id-evidence-claim-platform 16 } id-evidence-claim-platform-ccrequirement OBJECT IDENTIFIER ::= { id-evidence-claim-platform 17 } id-evidence-claim-platform-cceallevel OBJECT IDENTIFIER ::= { id-evidence-claim-platform 18 } id-evidence-claim-key OBJECT IDENTIFIER ::= { id-evidence-claim 2 } id-evidence-claim-key-identifier OBJECT IDENTIFIER ::= { id-evidence-claim-key 0 } id-evidence-claim-key-spki OBJECT IDENTIFIER ::= { id-evidence-claim-key 1 } id-evidence-claim-key-extractable OBJECT IDENTIFIER ::= { id-evidence-claim-key 2 } id-evidence-claim-key-sensitive OBJECT IDENTIFIER ::= { id-evidence-claim-key 3 } id-evidence-claim-key-never-extractable OBJECT IDENTIFIER ::= { id-evidence-claim-key 4 } id-evidence-claim-key-local OBJECT IDENTIFIER ::= { id-evidence-claim-key 5 } id-evidence-claim-key-expiry OBJECT IDENTIFIER ::= { id-evidence-claim-key 6 } id-evidence-claim-key-purpose OBJECT IDENTIFIER ::= { id-evidence-claim-key 7 } id-evidence-claim-key-device-bound OBJECT IDENTIFIER ::= { id-evidence-claim-key 8 } id-evidence-key-capability OBJECT IDENTIFIER ::= { id-evidence 2 } id-evidence-key-capability-encrypt OBJECT IDENTIFIER ::= { id-evidence-key-capability 0 } id-evidence-key-capability-decrypt OBJECT IDENTIFIER ::= { id-evidence-key-capability 1 } id-evidence-key-capability-wrap OBJECT IDENTIFIER ::= { id-evidence-key-capability 2 } id-evidence-key-capability-unwrap OBJECT IDENTIFIER ::= { id-evidence-key-capability 3 } id-evidence-key-capability-sign OBJECT IDENTIFIER ::= { id-evidence-key-capability 4 } id-evidence-key-capability-sign-recover OBJECT IDENTIFIER ::= { id-evidence-key-capability 5 } id-evidence-key-capability-verify OBJECT IDENTIFIER ::= { id-evidence-key-capability 6 } id-evidence-key-capability-verify-recover OBJECT IDENTIFIER ::= { id-evidence-key-capability 7 } id-evidence-key-capability-derive OBJECT IDENTIFIER ::= { id-evidence-key-capability 8 } id-evidence-key-capability-decapsulate OBJECT IDENTIFIER ::= { id-evidence-key-capability 9 } id-evidence-key-capability-encapsulate OBJECT IDENTIFIER ::= { id-evidence-key-capability 10 } claim-transaction-nonce CLAIM ::= { ID id-evidence-claim-transaction-nonce WITH TYPE OCTET STRING } claim-transaction-timestamp CLAIM ::= { ID id-evidence-claim-transaction-timestamp WITH TYPE GeneralizedTime } claim-transaction-ak-spki CLAIM ::= { ID id-evidence-claim-transaction-ak-spki WITH TYPE SubjectPublicKeyInfo } claim-platform-vendor CLAIM ::= { ID id-evidence-claim-platform-vendor WITH TYPE UTF8String } claim-platform-oemid CLAIM ::= { ID id-evidence-claim-platform-oemid WITH TYPE OCTET STRING } claim-platform-hwmodel CLAIM ::= { ID id-evidence-claim-platform-hwmodel WITH TYPE OCTET STRING } claim-platform-hwversion CLAIM ::= { ID id-evidence-claim-platform-hwversion WITH TYPE UTF8String } claim-platform-hwserial CLAIM ::= { ID id-evidence-claim-platform-hwserial WITH TYPE UTF8String } claim-platform-swname CLAIM ::= { ID id-evidence-claim-platform-swname WITH TYPE UTF8String } claim-platform-swversion CLAIM ::= { ID id-evidence-claim-platform-swversion WITH TYPE UTF8String } claim-platform-dbgstat CLAIM ::= { ID id-evidence-claim-platform-dbgstat WITH TYPE INTEGER } claim-platform-uptime CLAIM ::= { ID id-evidence-claim-platform-uptime WITH TYPE INTEGER } claim-platform-bootcount CLAIM ::= { ID id-evidence-claim-platform-bootcount WITH TYPE INTEGER } claim-platform-fipsboot CLAIM ::= { ID id-evidence-claim-platform-fipsboot WITH TYPE BOOLEAN } claim-platform-fipsver CLAIM ::= { ID id-evidence-claim-platform-fipsver WITH TYPE UTF8String } claim-platform-fipslevel CLAIM ::= { ID id-evidence-claim-platform-fipslevel WITH TYPE INTEGER } claim-platform-fipsmodule CLAIM ::= { ID id-evidence-claim-platform-fipsmodule WITH TYPE UTF8String } claim-platform-ccmoduleid CLAIM ::= { ID id-evidence-claim-platform-ccmoduleid WITH TYPE UTF8String } claim-platform-ccboot CLAIM ::= { ID id-evidence-claim-platform-ccboot WITH TYPE BOOLEAN } claim-platform-ccscheme CLAIM ::= { ID id-evidence-claim-platform-ccscheme WITH TYPE UTF8String } claim-platform-ccrequirement CLAIM ::= { ID id-evidence-claim-platform-ccrequirement WITH TYPE UTF8String } claim-platform-cceallevel CLAIM ::= { ID id-evidence-claim-platform-cceallevel WITH TYPE UTF8String } claim-key-identifier CLAIM ::= { ID id-evidence-claim-key-identifier WITH TYPE UTF8String } claim-key-spki CLAIM ::= { ID id-evidence-claim-key-spki WITH TYPE SubjectPublicKeyInfo } claim-key-extractable CLAIM ::= { ID id-evidence-claim-key-extractable WITH TYPE BOOLEAN } claim-key-sensitive CLAIM ::= { ID id-evidence-claim-key-sensitive WITH TYPE BOOLEAN } claim-key-never-extractable CLAIM ::= { ID id-evidence-claim-key-never-extractable WITH TYPE BOOLEAN } claim-key-local CLAIM ::= { ID id-evidence-claim-key-local WITH TYPE BOOLEAN } claim-key-expiry CLAIM ::= { ID id-evidence-claim-key-expiry WITH TYPE GeneralizedTime } claim-key-purpose CLAIM ::= { ID id-evidence-claim-key-purpose WITH TYPE KeyPurposes } KeyPurposes ::= SEQUENCE OF OBJECT IDENTIFIER claim-key-device-bound CLAIM ::= { ID id-evidence-claim-key-device-bound WITH TYPE BOOLEAN } END

]]>


    
      IANA Considerations
      Please replace "RFCthis" with the RFC number assigned to this document.
      For the ASN.1 module found in , IANA is requested to assign
an object identifier for the module identifier (TBDMOD1) with a
description of "id-mod-pkix-evidence-2025". This should be allocated in the
"SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).
      For the ASN.1 module found in , IANA is requested to assign an
object identifier for the extended key usage id-kp-attestationKey (TBDMOD2).
This identifier should be allocated under the PKIX KP arc (1.3.6.1.5.5.7.3)
with the description "Extended Key Usage (EKU) for signing Evidence".
      IANA is asked to define a new arc under "SMI Security for Mechanism Codes" (1.3.6.1.5.5) with the following
details:
      
        
          OID Value: 1.3.6.1.5.5.TBDMOD3
        
        
          Name: evidence
        
        
          Description: Evidence Encoding for Hardware Security Modules
        
        
          Reference: RFCthis
        
      
    
    
      Security Considerations
      
        Policies relating to Verifier and Relying Party
        The generation of Evidence by an HSM is to provide sufficient information to
a Verifier and, ultimately, a Relying Party to appraise the Target Environment (the HSM) and make
decisions based on this appraisal.
        The Appraisal Policy associated with the Verifier influences the generation of the Attestation
Results. Those results, in turn, are consumed by the Relying Party to make decisions about
the HSM, which might be based on a set of rules and policies. Therefore, the interpretation of
the provided Evidence may greatly influence the outcome of some decisions.
        A Verifier MAY reject Evidence if it lacks the claims required per the Verifier's
appraisal policy. For example, if a Relying Party mandates a FIPS 140 validated device,
it SHOULD reject Evidence lacking sufficient information to verify the device's FIPS 140
validation status.
        If a Verifier encounters a claim with an unrecognized claim type, it MAY ignore it and
treat it as extraneous information. By ignoring a claim, the Verifier may accept Evidence
that would be deemed malformed to a Verifier with different policies. However, this approach
fosters a higher likelihood of achieving interoperability.
      
      
        Simple to Implement
        The nature of attestation requires the Attesting Environment to be implemented in an extremely
privileged position within the HSM so that it can collect the required measurements such as
hardware registers and the user keys. For many HSM architectures, this will
place the Attesting Environment inside the "security kernel" and potentially subject to FIPS 140-3
or Common Criteria validation and change control. For both security and compliance reasons,
there is an incentive for the generation and parsing logic to be simple and easy to implement
correctly. Additionally, when the data formats contained in this specification are parsed
within an HSM boundary -- that would be parsing Evidence
produced by a different HSM -- implementers SHOULD opt for simple logic that rejects any
data that does not match the expected format, instead of attempting to be flexible.
        In particular, the Attesting Environment SHOULD generate Evidence from scratch. The Attesting Environment MUST generate Evidence
only from information and measurements that are directly observable by it.
      
      
        Privacy and Evidence Encryption
        Some HSMs have the capacity of supporting cryptographic keys controlled by separate entities referred to as "tenants", and when the HSM is used in that mode
it is referred to as a multi-tenant configuration.
        For example, an enterprise-grade HSM in a large multi-tenant cloud service could host TLS keys fronting multiple unrelated web domains. Providing Evidence for
claims of any one of the keys would involve a Presenter that could potentially access any of the hosted keys.
In such a case, privacy violations could occur if the Presenter was to disclose information that does not relate to the subject key.
        Implementers SHOULD avoid over-disclosure of information by authenticating and authorizing the entity that initiates Evidence generation and by including only
keys and portions of the Target Environment that this entity is authorized to access. The interface for selecting the elements and claims included in Evidence
is outside the scope of this specification.
        A Presenter SHOULD review Evidence before disclosure and SHOULD NOT disclose Evidence containing information that the intended Verifier is not authorized to receive.
This specification does not provide Evidence encryption; deployments that require confidentiality MUST use an appropriate conveyance protocol or object-security mechanism.
         presents a framework for identifying points in an Evidence conveyance protocol where designers and implementers need to be conscious of privacy concerns.
For the Evidence mechanism specified in this document, the primary privacy concern has to do with authenticating the Presenter against the HSM's local policies, and only releasing claims that they are authorized to view.
The means by which a Presenter requests the generation of Evidence is not covered by this specification and is left to the implementers.
        Additionally,  calls for object-level evidence encryption (instead of relying solely on transport encryption), and corresponding validation
of the provided Verifier encryption certificate against local policies. Such a mechanism is left out-of-scope in this specification since it is largely independent of the Evidence
formatting structures defined in this specification. Implementers are welcome to wrap the structures defined here in such an encryption layer either within the HSM or externally to the HSM
at an entity such as the Presenter.
      
      
        Authenticating and Authorizing the Presenter
        The Presenter represents a privileged role because it can learn about the existence of user keys and their protection properties, as well as details of the platform.
It can also decide whether to disclose generated Evidence to a Verifier.
        For personal cryptographic tokens it might be appropriate for the local Evidence-generation interface to be unauthenticated. For enterprise and cloud-services grade HSMs,
the entity invoking that interface SHOULD be authenticated using the HSM's native authentication mechanism. The details of this interface are HSM-specific and outside the
scope of this specification.
        The HSM MUST enforce its native access controls when generating Evidence. An authenticated application SHOULD be allowed to obtain Evidence only for user keys that it
is authorized to access. An administrative application that obtains Evidence for keys it is not allowed to use MUST have a distinct permission and MUST be limited to keys
for which it has administrative visibility.
      
      
        Proof-of-Possession of User Keys
        With asymmetric keys within a Public Key Infrastructure (PKI) it is common to require a key holder to prove that they are in control of the private key by using it. This is
called "proof-of-possession (PoP)". This specification intentionally does not provide a mechanism for PoP of user keys and relies on the Presenter, Verifier, and Relying Party
trusting the Attester to correctly report the cryptographic keys that it is holding.
        It would be trivial to add a PoP Key claim that uses the attested user key to sign over, for example, the Transaction Element. However, this approach leads to undesired consequences, as explained
below.
        First, a user key intended for TLS, as an example, SHOULD only be used with the TLS protocol. Introducing a signature oracle whereby the TLS application key is used to sign Evidence could lead to cross-protocol attacks.
In this example, an attacker could submit a "nonce" value which is in fact not random but is crafted in such a way as to appear as a valid message in some other protocol context or exploit some other weakness in the signature algorithm.
        Second, the Presenter that initiates Evidence generation may have permission to list the relevant application keys but not permission to use them,
as in the case where the Presenter is an administrative UI displaying HSM status information to a system's administrator or auditor.
        Requiring the Attesting Environment to use the reported application keys to generate Evidence could, in some architectures, require the Attesting Environment to
resolve complex access control logic and handle complex error conditions, which violates the "simple to implement" design principle outlined in .
More discussion on authenticating the Presenter can be found in .
      
      
        Timestamps and HSMs
        It is common for HSMs to have an inaccurate system clock. Most clocks have a natural drift and must be corrected periodically. HSMs, like any other devices,
are subject to these issues.
        There are many situations where HSMs cannot naturally correct their internal system clocks. For example, consider an HSM hosting a trust anchor and usually kept offline
and booted up infrequently in a network without a reliable time management service. Another example is a smart card which boots up only when held against an NFC reader.
        When a timestamp generated from an HSM is evaluated, the expected behavior of the system clock SHOULD be considered.
        More specifically, the timestamp SHOULD NOT be relied on for establishing the freshness of the Evidence generated by an HSM. Instead, Verifiers SHOULD rely on other provisions
such as the "nonce" claim of the "transaction" element, introduced in this specification.
        Furthermore, the internal system clock of HSMs SHOULD NOT be relied on to enforce expiration policies.


  
    
      References
      
        Normative References
        
          
            Remote ATtestation procedureS (RATS) Architecture
            
            
            
            
            
            
            
              In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols.
            
          
          
          
        
        
          
            Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
            
            
            
            
            
            
            
            
              This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
            
          
          
          
        
        
          
            The Entity Attestation Token (EAT)
            
            
            
            
            
            
              An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity.
              An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims.
            
          
          
          
        
        
          
            The Base16, Base32, and Base64 Data Encodings
            
            
            
              This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Information technology — ASN.1: Specification of basic notation
            
              ITU-T
            
            n.d.
          
        
        
          
            Information technology — ASN.1 encoding rules: BER, CER, DER
            
              ITU-T
            
            n.d.
          
        
        
          
            Key words for use in RFCs to Indicate Requirement Levels
            
            
            
              In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
            
          
          
          
          
        
        
          
            Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
            
            
            
              RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
            
          
          
          
          
        
      
      
        Informative References
        
          
            Trust Anchor Management Requirements
            
            
            
            
              A trust anchor represents an authoritative entity via a public key and associated data. The public key is used to verify digital signatures, and the associated data is used to constrain the types of information for which the trust anchor is authoritative. A relying party uses trust anchors to determine if a digitally signed object is valid by verifying a digital signature using the trust anchor's public key, and by enforcing the constraints expressed in the associated data for the trust anchor. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism and defines requirements for data formats and push-based protocols designed to address these problems. This document is not an Internet Standards Track specification; it is published for informational purposes.
            
          
          
          
        
        
          
            A Firmware Update Architecture for Internet of Things
            
            
            
            
            
            
              Vulnerabilities in Internet of Things (IoT) devices have raised the need for a reliable and secure firmware update mechanism suitable for devices with resource constraints. Incorporating such an update mechanism is a fundamental requirement for fixing vulnerabilities, but it also enables other important capabilities such as updating configuration settings and adding new functionality.
              In addition to the definition of terminology and an architecture, this document provides the motivation for the standardization of a manifest format as a transport-agnostic means for describing and protecting firmware updates.
            
          
          
          
        
        
          
            Use of Remote Attestation with Certification Signing Requests
            
              Cryptic Forest Software
            
            
              Siemens
            
            
              Fraunhofer SIT
            
            
              Independent
            
            
         
            
            
                 Certification Authorities (CAs) issuing certificates to Public Key
   Infrastructure (PKI) end entities may require a certificate signing
   request (CSR) to include additional verifiable information to confirm
   policy compliance.  For example, a CA may require an end entity to
   demonstrate that the private key corresponding to a CSR's public key
   is secured by a hardware security module (HSM), is not exportable,
   etc.  The process of generating, transmitting, and verifying
   additional information required by the CA is called remote
   attestation.  While work is currently underway to standardize various
   aspects of remote attestation, a variety of proprietary mechanisms
   have been in use for years, particularly regarding protection of
   private keys.

   This specification defines ASN.1 structures which may carry
   attestation data for PKCS#10 and Certificate Request Message Format
   (CRMF) messages.  Both standardized and proprietary attestation
   formats are supported by this specification.

              
            
          
          
        
        
          
            Privacy Framework for Remote ATtestation procedureS
            
              Cryptic Forest Software
            
            
              University of the Bundeswehr Munich
            
            
              University of Applied Sciences Bonn-Rhein-Sieg
            
            
            
                 This document extends the RATS Architecture to consider "coercive
   uses of RATS" where a malicious Verifier or Relying Party uses RATS
   protocols to extract sensitive information from an Attester or a
   victim Verifier that it would not otherwise be inclined to disclose.
   This over-disclosure can include revealing sensitive measurements,
   stable identifiers, device fingerprints, vendor information, or
   conclusions derived from Evidence.  This document defines a privacy
   framework for Remote Attestation that identifies this threat
   surfaces; classifies claims produced by Attesters and Presenters;
   restricts sensitive Evidence disclosure to authorized Trusted
   Verifiers using confidentiality protection; and describes privacy-
   preserving Attestation Results based on data minimization, Selective
   Disclosure, and Zero-Knowledge Proofs.

              
            
          
          
        
        
          
            Commercial National Security Algorithm Suite 2.0
            
              National Security Agency
            
            
          
        
        
          
            Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates Version 3.8
            
              CA/Browser Forum
            
            n.d.
          
        
        
          
            Information technology — Security techniques — Security requirements for cryptographic modules
            
              ISO/IEC
            
            n.d.
          
          
        
        
          
            Cryptographic Module Validation Program (CMVP) Security Policy Requirements: CMVP Validation Authority Updates to ISO/IEC 24759 and ISO/IEC 19790 Annex B
            
              NIST
            
            n.d.
          
          
        
        
          
            Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program
            
              NIST and CCCS
            
            
          
        
        
          
            Cryptographic Module Validation Program — Validated Modules
            
              NIST
            
            n.d.
          
        
        
          
            Security Requirements for Cryptographic Modules
            
              NIST, Information Technology Laboratory
            
            n.d.
          
          
        
        
          
            Security Requirements for Cryptographic Modules
            
              NIST, Information Technology Laboratory
            
            n.d.
          
          
        
        
          
            Common Criteria for Information Technology Security Evaluation Part 1: Introduction and general model
            
              Common Criteria
            
            
          
        
        
          
            Common Criteria for Information Technology Security Evaluation Part 5: Pre-defined packages of security requirements
            
              Common Criteria
            
            
          
        
        
          
            PKCS #11 Specification Version 3.1
            
              
            
            
              
            
            
              OASIS PKCS 11 TC
            
            
          
        
      
    
    


      Samples
      A reference implementation of this specification can be found at https://github.com/ietf-rats-wg/key-attestation
      It produces the following sample Evidence.
      All signatures throughout the samples chain to the following root certificate:
      
      
        Simple Platform Evidence
        This example shows a minimal PKIX Evidence object with only transaction and platform elements and a single signature where the AK key is identified only by
its SHA1 hash KeyID. In other words, this Evidence describes only the HSM itself (rather than application keys stored within it), and it assumes
that the Verifier will be able to look up the AK key by its SHA1 hash.
        
        Here is a pretty-print of the Evidence object:
         [OCTET STRING] deadbeefcafebabe
      Claim[1]: id-evidence-claim-transaction-timestamp
              -> [GeneralizedTime] 20261030172826Z
      Claim[2]: id-evidence-claim-transaction-ak-spki
              -> [SubjectPublicKeyInfo] 3059301306072a8648ce3d02...
    ReportedElement[1]: id-evidence-element-platform
      Claim[0]: id-evidence-claim-platform-vendor
              -> [UTF8String] Acme Corp
      Claim[1]: id-evidence-claim-platform-hwmodel
              -> [OCTET STRING] 48534d2d39303030
      Claim[2]: id-evidence-claim-platform-hwversion
              -> [UTF8String] 2.1.0
      Claim[3]: id-evidence-claim-platform-fipsboot
              -> [BOOLEAN] True
      Claim[4]: id-evidence-claim-platform-fipslevel
              -> [INTEGER] 3
      Claim[5]: id-evidence-claim-platform-uptime
              -> [INTEGER] 86400
  Signatures (1):
    SignatureBlock[0]:
      algorithm      : 1.2.840.10045.4.3.2
      signatureValue : 3044022044a79158010aa2e1...
      keyId          : e8ec8f23b61e50cb5c21241cd5e816e1e9176e0e
  Intermediate Certificates:  (1)
]]>
        For completeness of the sample, the following AK and Intermediate CA certificates are required for verification:
        
      
      
        Key Attestation Evidence
        This example shows a PKIX Evidence object that is attesting two different application keys held within the HSM.
For the purposes of this example, the Platform Element is kept short.
This example embeds the AK and Intermediate CA certificates in the Evidence object. It chains to the same root as above.
        
        Here is a pretty-print of the Evidence object:
         [OCTET STRING] beefcafebabedead
      Claim[1]: id-evidence-claim-transaction-timestamp
              -> [GeneralizedTime] 20261030172826Z
      Claim[2]: id-evidence-claim-transaction-ak-spki
              -> [SubjectPublicKeyInfo] 3059301306072a8648ce3d02...
    ReportedElement[1]: id-evidence-element-platform
      Claim[0]: id-evidence-claim-platform-hwmodel
              -> [OCTET STRING] 48534d2d39303030
    ReportedElement[2]: id-evidence-element-key
      Claim[0]: id-evidence-claim-key-identifier
              -> [UTF8String] 9a25f603-a2c4-4dad-9ee0-...
      Claim[1]: id-evidence-claim-key-spki
              -> [SubjectPublicKeyInfo] 3059301306072a8648ce3d02...
      Claim[2]: id-evidence-claim-key-extractable
              -> [BOOLEAN] False
      Claim[3]: id-evidence-claim-key-never-extractable
              -> [BOOLEAN] True
      Claim[4]: id-evidence-claim-key-sensitive
              -> [BOOLEAN] True
      Claim[5]: id-evidence-claim-key-local
              -> [BOOLEAN] True
      Claim[6]: id-evidence-claim-key-purpose
              -> [KeyPurposes] id-evidence-key-capability-sign
    ReportedElement[3]: id-evidence-element-key
      Claim[0]: id-evidence-claim-key-identifier
              -> [UTF8String] 85704b99-7097-4bca-93b6-...
      Claim[1]: id-evidence-claim-key-spki
              -> [SubjectPublicKeyInfo] 3059301306072a8648ce3d02...
      Claim[2]: id-evidence-claim-key-extractable
              -> [BOOLEAN] True
      Claim[3]: id-evidence-claim-key-sensitive
              -> [BOOLEAN] False
  Signatures (1):
    SignatureBlock[0]:
      algorithm      : 1.2.840.10045.4.3.2
      signatureValue : 3046022100adc171a4467829...
      AK Certificate : present
  Intermediate Certificates:  (1)
]]>
      
    
    
      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.
      We would like to thank Jeff Andersen for the review comments.
      We would like to thank Dave Thaler for his guidance.