PKIX Key Attestation
draft-ietf-rats-pkix-key-attestation-00
| Document | Type | Active Internet-Draft (rats WG) | |
|---|---|---|---|
| Authors | Mike Ounsworth , Jean-Pierre Fiset , Hannes Tschofenig , Henk Birkholz , Monty Wiseman , Ned Smith | ||
| Last updated | 2025-03-06 (Latest revision 2025-03-03) | ||
| Replaces | draft-ietf-rats-pkix-evidence | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| On agenda | rats at IETF-122 | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-rats-pkix-key-attestation-00
RATS M. Ounsworth
Internet-Draft Entrust
Intended status: Standards Track J.-P. Fiset
Expires: 4 September 2025 Crypto4A
H. Tschofenig
H-BRS
H. Birkholz
Fraunhofer SIT
M. Wiseman
Beyond Identity
N. Smith
Intel Corporation
3 March 2025
PKIX Key Attestation
draft-ietf-rats-pkix-key-attestation-00
Abstract
This document specifies a vendor-agnostic format for attesting to the
protection properties of a symmetric or asymmetric cryptographic key
within a hardware cryptographic module to support applications such
as providing evidence to a Certification Authority that a key is
being protected in accordance with the requested certificate profile,
or that HSMs can perform key import and maintain the private key
protection properties in a robust way even when migrating keys across
HSM vendors. This specification includes a format for requesting a
key attestation containing certain attributes. This specification is
called "PKIX Attestation" because it is designed to be easy to
implement on top of a code base that already supports X.509 and
PKCS#11 data models.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Remote ATtestation
ProcedureS Working Group mailing list (rats@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/hannestschofenig/key-attestation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Ounsworth, et al. Expires 4 September 2025 [Page 1]
Internet-Draft PKIX Key Attestation March 2025
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Architecture and Conceptual Model . . . . . . . . . . . . . . 7
3.1. Attestation Key Certificate Chain . . . . . . . . . . . . 9
4. Information Model . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Transaction Attributes . . . . . . . . . . . . . . . . . 13
4.1.1. nonce . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2. time . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Platform Attributes . . . . . . . . . . . . . . . . . . . 14
4.2.1. usermods . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. fipsboot, fipsver and fipslevel . . . . . . . . . . . 16
4.2.3. envid . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.4. envdesc . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Key Attributes . . . . . . . . . . . . . . . . . . . . . 18
4.3.1. purpose . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2. protection . . . . . . . . . . . . . . . . . . . . . 20
4.4. Additional Entity and Attribute Types . . . . . . . . . . 20
4.5. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 20
5. Signing Procedure . . . . . . . . . . . . . . . . . . . . . . 20
6. Verification Procedure . . . . . . . . . . . . . . . . . . . 21
Ounsworth, et al. Expires 4 September 2025 [Page 2]
Internet-Draft PKIX Key Attestation March 2025
7. Attestation Requests . . . . . . . . . . . . . . . . . . . . 21
8. Appraisal Policies and Profiles . . . . . . . . . . . . . . . 23
8.1. Key Import into an HSM . . . . . . . . . . . . . . . . . 23
8.2. CA/Browser Forum Code-Signing . . . . . . . . . . . . . . 24
9. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Simple to Implement . . . . . . . . . . . . . . . . . . 27
11.2. Detached Signatures . . . . . . . . . . . . . . . . . . 27
11.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 28
11.4. Authenticating and Authorizing the Presenter . . . . . . 28
11.5. Proof-of-Possession of Application Keys . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.1. Normative References . . . . . . . . . . . . . . . . . . 30
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Appendix A. Samples . . . . . . . . . . . . . . . . . . . . . . 32
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
This specification is targeted at attesting to the storage of
cryptographic key material -- symmetric keys or asymmetric private
keys -- within a hardware cryptographic module such as a Hardware
Security Module (HSM) or Trusted Platform Module (TPM). HSMs and
TPMs are devices whose primary purpose is to hold cryptographic keys
and support interfaces whereby they can be used to perform encrypt,
decrypt, sign, MAC and other keyed cryptographic operations on
provided data without the key material ever leaving the hardware
module. Typically an HSM or TPM holds an uses cryptographic keys on
behalf of an application such as a Certification Authority, a code
signing service, a TLS server. However, also included in the scope
of this draft are single-purpose cryptographic devices such as
smartcards which may hold only a single application key for a single
purpose such as authenticating to a near-field "tap" terminal.
Within this specification we will generically refer to the attesting
device as an "HSM", and to the cryptographic keys that it holds an
operates on behalf of some other application as "application keys".
The goal of this specification is to provide a standardized format in
which an HSM can attest that one or more application keys are
contained within a hardware module, and attest to any additional
attributes relating to the protection of this key material.
This requires providing evidence to the key protection properties of
that key, referred to in this specification as "key attributes", as
well as to the operational state of the hardware platform, referred
to as "platform attributes". This specification also provides a
Ounsworth, et al. Expires 4 September 2025 [Page 3]
Internet-Draft PKIX Key Attestation March 2025
format for requesting that a cryptographic module produce a key
attestation about a specific application key, the application keys in
a specific sub-environment of the HSM, or that the returned
attestation contain a specific set of attributes. See Section 4 for
the full information model.
As described below in Section 3 "Architecture and Conceptual Model",
this specification uses a simplification of the Remote ATtestation
procedureS (RATS) Architecture [RFC9334] by assuming that the
attesting environment and the target environment are the same
environment, and that this environment only produces evidence as this
aligns with the target hardware platforms. As such, the attestation
data format specified in Section 4 only contains evidence (referred
to in this document as "attributes") and does not provide for any
form of endorsement except for endorsement of the device's
attestation signing key which is endorsed via an X.509 certificate
chain rooted in a trust anchor belonging either to the device
manufacturer or to the device operator, as described in Section 3.1.
Unlike other attestation data formats defined by the RATS working
group, the format defined in this document is targeting devices
designed to operate within Public Key Infrastructure (PKI)
ecosystems; this motivates the following design choices:
* Attestation data structure defined in ASN.1 [X.680] and encoded in
Distinguished Encoding Rules (DER) [X.690].
* Endorsement of attesting key uses an X.509 certificate chain
[RFC5280].
* Key attributes are mostly just a mapping of the private key
properties from PKCS#11 [PKCS11].
For these reasons, this attestation format is called "PKIX Key
Attestation" and may be used, for example within a Certificate
Signing Request (CSR) object; [I-D.ietf-lamps-csr-attestation]
specifies how to carry evidence within PKCS#10 [RFC2986] or
Certificate Request Message Format (CRMF) [RFC4211].
This document provides a vendor-agnostic format for attesting to the
logical and physical protection properties of a cryptographic key and
it envisions uses such as providing evidence to a Certification
Authority that a key is being protected in accordance with the
requested certificate profile, or that HSMs can perform key import
and maintain the private key protection properties in a robust way
even when migrating keys across HSMs from different vendors.
Ounsworth, et al. Expires 4 September 2025 [Page 4]
Internet-Draft PKIX Key Attestation March 2025
2. Terminology
The reader is assumed to be familiar with the vocabulary and concepts
defined in [RFC9334].
The following terms are used in this document:
Root of Trust (RoT):
A set of software and/or hardware components that need to be
trusted to act as a security foundation required for accomplishing
the security goals of a system. In our case, the RoT is expected
to offer the functionality for attesting to the state of the
platform, and to attest the properties of the application key.
More precisely, it has to attest the integrity of the application
key (public as well as private key) and the confidentiality of the
private part of the application key. This document makes a
simplifying assumption that the RoT, the attesting environment
holding the attestation key, and the target environment being
measured and attested are all the same environment.
Attestation Key (AK):
Cryptographic key belonging to the RoT that is only used to sign
attestation tokens.
Hardware Security Module (HSM):
a physical computing device that safeguards and manages secrets
(most importantly cryptographic keys), and performs encryption,
decryption, signing, MACing and other cryptographic operations
with the managed cryptographic keys. HSMs can sometimes host user
applications within a secure enclave environment within the HSM
that are often used to extend the cryptographic functionality of
the HSM. This specification takes a broad definition of what
counts as an HSM to include smartcards, USB tokens, and similar
devices which this specification refers to as "personal
cryptographic tokens", as well as TPMs, in addition to the usual
PCI card, rack-mount, and blade server form-factor of HSM which
this specification refers to as "enterprise-grade" or "cloud-
service grade" HSMs.
Key Attestation:
Evidence containing properties of the environment(s) in which the
private keys are generated and stored. For example, a Relying
Party may want to know whether a private key is stored in a
hardware security module and cannot be exported in cleartext.
Usage Protocol:
A (security) protocol that requires demonstrating possession of
the private component of the application key.
Ounsworth, et al. Expires 4 September 2025 [Page 5]
Internet-Draft PKIX Key Attestation March 2025
Attestation Token (AT):
A collection of claims that a RoT assembles (and signs) with the
purpose of informing - in a verifiable way - relying parties about
the identity and state of the platform. Essentially a type of
Evidence as per the RATS architecture terminology [RFC9334].
Platform Attestation Entity:
An Entity containing attributes relating to the security state of
the platform,. The process of generating a platform entity
typically involves gathering data during measured boot.
Key Attestation Entity:
An Entity containing attributes relating to a specific application
key protected by the HSM. The key attestation service is part of
the root of trust (RoT).
Application Key:
The application key consists of a private and a public key. The
private key is used by the usage protocol. The public key is
included in the Key Attestation Token. The Key Attestation Entity
makes claims about the protection of this key.
Trust Anchor:
As defined in [RFC6024] and [RFC9019], a Trust Anchor "represents
an authoritative entity via a public key and associated data. The
public key is used to verify digital signatures, and the
associated data is used to constrain the types of information for
which the trust anchor is authoritative." The Trust Anchor may be
a certificate, a raw public key, or other structure, as
appropriate. It can be a non-root certificate when it is a
certificate.
Presenter:
Party that proves possession of a private key to a recipient of a
key attestation token. Typically this will be an application
layer entity, such as a cryptographiclibrary constructing a
Certificate Signing Request that must embed attestation evidence,
or a TLS library attempting to perform attested TLS. The
Presenter is not fulfilling any roles in the RATS architecture.
Recipient:
Party that receives the attestation evidence containing the proof-
of-possession key information from the presenter. The Recipient
is likely fulfilling the roles of Verifier and Relying Party in
the RATS architecture, but the exact details of this arrangement
is out-of-scope for this specification.
Key Attestation Service (KAS):
Ounsworth, et al. Expires 4 September 2025 [Page 6]
Internet-Draft PKIX Key Attestation March 2025
The module within the HSM that is responsible for parsing the PKIX
Attestation Request, measuring the Platform and the Key
attributes, constructing the PKIX Attestation object, and signing
it with the AK. The KAS fulfills the role of Attester in the RATS
architecture. Note that real HSMs may or may not implement the
Attester as a single internal module, but this abstraction is used
for the design and security analysis of this specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Architecture and Conceptual Model
Key attestation is an extension to the attestation functionality
described in [RFC9334]. In the general RATS Architecture, an
attesting device consists of a hardware Root of Trust (RoT) which
provides the basis for trust in the device, and then one or more
layers of attestations where an attesting environment collects and
signs measurements (evidence) about a target environment. Trust is
established by chaining the cryptographic signatures on each layer of
evidence up to the next layer of attester until the RoT is reached,
and trust is established in the RoT via 3rd party endorsements. The
target devices for this specification tend to operate on a different
architecture and trust model: the devices consist of one single
logical environment (combining the RATS roles of RoT, attesting
environment, and target environment together into a single entity),
and trust is established via product validations conducted by third-
party testing labs against standardized security and functional
requirements such as FIPS 140-3 or a given Common Criteria protection
profile. A FIPS or CC certification provided by a testing lab would
conceptually count as an endorsement of the hardware platform in the
RATS architecture, but they are often not digitally-signed artifacts,
and are often conveyed out of band, sometimes via a website or even
via a paper certificate and so they are out of scope for the wire
format specified in this document.
As such, the attestation data format defined in this document does
not capture the full functionality of the RATS architecture. If a
device producing evidence in the specified format requires to also
carry nested attestation statements or endorsements, then it must be
achieved by placing the attestation from this draft within another
wrapper layer such as RATS Conceptual Message Wrapper (CMW)
[I-D.ietf-rats-msg-wrap].
Ounsworth, et al. Expires 4 September 2025 [Page 7]
Internet-Draft PKIX Key Attestation March 2025
.-------------------------------------.
| Hardware Security Module |
| |
| Platform environment |
| ^ .-------------. |
| | | Application | |
| | | Keys | |
| | '-------------' |
| | ^ |
| | | |
| | measurements | |
| .------------------------------. |
| | Attestation | |
| | Service | |
| '------------------------------' |
| ^ | |
| | | |
'-----+----+--------------------------'
Attestation | | PKIX
Request | | Attestation
| v
.-----------------. .-----------------.
| | Usage Protocol | |
| Presenter +---------------->| Recipient |
| | | |
'-----------------' '-----------------'
Figure 1: Architecture
Figure 1 depicts a typical workflow where an external tool queries
the HSM for the status of one or more cryptographic keys that it is
protecting ("Application Keys"). The "Presenter" may be, for
example, a command-line or graphical user interface which will
display the evidence to an operator or auditor; a cryptographic
library which will include the evidence in a CSR for transmission to
a Certification Authority; a TLS library which will include the
evidence in at attested TLS session [I-D.fossati-tls-attestation]; or
similar applications, refered to as the "Usage Protocol".
This model does not assume any internal structure or logical
separation within the HSM except for the existence of some kind of
attestation service which may or may not be logically separate from
the overall HSM Root of Trust, and that this attestation service
measures the required evidence about both the hardware environment
and the application keys that are being attested. In addition to
emitting key attestation evidence, an HSM may also need to parse it,
for example when running in an operational mode that only allows
importing keys from other HSMs at a comparable security level
Ounsworth, et al. Expires 4 September 2025 [Page 8]
Internet-Draft PKIX Key Attestation March 2025
(requires checking for specific claims) or within the same
operational network (requires checking the trust anchor of the
attestation key certificate chain). This implies that the
attestation service needs to be part of the core HSM "kernel" and
therefore would be subject to validations such as FIPS 140-3 or
Common Criteria, which motivates a design requirement to keep the
evidence data format as simple as possible and as close as possible
to existing functionality and data models of existing HSM and TPM
products. As such, the information model presented in Section 4 will
feel familiar to implementers with experience with PKI and PKCS#11.
3.1. Attestation Key Certificate Chain
The data format in this specification represents attestation 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 will usually be a manufacturing CA belonging to the device
vendor which proves that the device is genuine and not counterfeit.
The trust anchor can also belong to the device operator as would be
the case when the AK certificate is replaced as part of onboarding
the device into a new operational network.
Note that the data format specified in Section 4 allows for zero,
one, or multiple 'SignatureBlock's, so a single evidence statement
could be un-protected, or could be endorsed by multiple AK chains
leading to different trust anchors. See Section 6 for a discussion
of handling multiple SignatureBlocks.
4. Information Model
This section describes the semantics of the key claims as part of the
information model.
The envelop structure is:
Ounsworth, et al. Expires 4 September 2025 [Page 9]
Internet-Draft PKIX Key Attestation March 2025
PkixAttestation ::= SEQUENCE {
tbs TbsPkixAttestation,
signatures SEQUENCE SIZE (0..MAX) of SignatureBlock
}
TbsPkixAttestation ::= SEQUENCE {
version INTEGER,
reportedEntities SEQUENCE SIZE (1..MAX) OF ReportedEntity
}
SignatureBlock ::= SEQUENCE {
certChain SEQUENCE of Certificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue OCTET STRING
}
A PkixAttestation message is composed of a protected section known as
the To-Be-Signed or TBS. The integrity of the To-Be-Signed section
is ensured with one or multiple cryptographic signatures over the
content of the section. There is a provision to carry the X.509
certificates supporting the signature(s).
The TBS section is composed of a version number, to ensure future
extensibility, and a sequence of reported entities.
For compliance with this specification, TbsPkixAttestation.version
MUST be 1. This envelope format is not extensible; future
specifications which make compatibility-breaking changes MUST
increment the version number.
EDNOTE: do we want extension marks on the TbsAttestation object? I
can see pros and cons to doing that.
SignatureBlock.certChain MUST contain at least one X.509 certificate
as per [RFC5280]. While there might exist attesting environments
which use out-of-band or non-X.509 mechanisms for communicating the
AK public key to the Verifier, these SHALL be considered non-
compliant with this specification.
The attribute format is intended to be generic, flexible, and
extensible with a default set of attributes defined in this document.
Attributes are grouped into entities; an entity can be either a key,
a platform, or a request containing a set of claims that are
requested to be filled by the attesting environment.
Ounsworth, et al. Expires 4 September 2025 [Page 10]
Internet-Draft PKIX Key Attestation March 2025
ReportedEntity ::= SEQUENCE {
entityType OBJECT IDENTIFIER,
reportedAttributes SEQUENCE SIZE (1..MAX) OF ReportedAttribute
}
A reported entity is a unit of observation measured by the Attester
(the HSM). In this specification, there are three types of entities
defined: - Platform Entity : An entity that reports attributes about
the platform, itself. A PKIX Attestation MAY contain only one
Platform Entity. - Key Entity : An entity that represents a single
cryptographic key found in a HSM ad its associated attributes. A
PKIX Attestation MAY contain one or more Key Entities. - Transaction
Entity : An entity reporting attributes observed from the request
itself. A PKIX Attestation MAY contain only one Transaction Entity.
A reported entity is composed of an Object Identifier (OID),
specifying the entity type, and a sequence of reported attributes
associated with the entity.
Although this specification defines only three types of entities,
implementations MAY define additional entity types by registering
additional OIDs.
An Attester (HSM) which is requested to provide information about
unrecognized entity types MUST fail the operation.
A Verifier which encounters an unrecognized entity type MAY ignore
it.
id-pkix-attest OBJECT IDENTIFIER ::= { 1 2 3 999 }
id-pkix-attest-entity-type OBJECT IDENTIFIER ::= { id-pkix-attest 0 }
id-pkix-attest-entity-transaction OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 0 }
id-pkix-attest-entity-platform OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 1 }
id-pkix-attest-entity-key OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 2 }
id-pkix-attest-entity-request OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 3 }
TODO: do we need entity types for "platform policy" and "key policy"
?
A PKIX Attestation MUST NOT contain more than one platform entity
since duplicate and conflicting platform claims across multiple
platform entities can easily lead to security bugs. A parser MUST
fail with an error if it encouters multiple platform entities.
A PKIX Attestation MUST NOT contain more than one transaction entity.
A transaction entity contains attributes that are related to the
request such as a "nonce". A parser MUST fail with an error if it
encouters multiple transaction entities.
Ounsworth, et al. Expires 4 September 2025 [Page 11]
Internet-Draft PKIX Key Attestation March 2025
A PKIX Attestation MAY contain one or more application key entities.
Each key entity SHOULD describe a unique application key. Multiple
ReportedEntity objects of type entity-key that describe the same
application key SHOULD be avoided since different or conflicting
claims could lead to security issues on the part of the Verifier or
Relying Party.
TODO: note that we need to be careful about whether it is allowed to
include the AK(s) and other "platform-owned" keys in the set of keys
you can attest, or only attesting application keys.
Each reported attribute is composed of an Object Identifier (OID),
identifying the type of the attribute, and a value which must be one
of the prescribed data types.
ReportedAttribute ::= SEQUENCE {
attributeType OBJECT IDENTIFIER,
value OPTIONAL AttributeValue
}
AttributeValue :== CHOICE {
bytes [0] IMPLICIT OCTET STRING
utf8String [1] IMPLICIT UTF8String,
bool [2] IMPLICIT BOOLEAN,
time [3] IMPLICIT GeneralizedTime,
int [4] IMPLICIT INTEGER,
oid [5] IMPLICIT OBJECT IDENTIFIER
}
An attribute type is generally associated with a single entity type.
In the following sub-sections, defined attributes are grouped
according to their related entity types.
There are circumstances where an attribute type can be repeated for a
given entity while other attribute types are unique. For example,
the hwmodel, uptime, and fipsboot attributes are not allowed to have
multiple instances since these are global measurements of the
platform. However, other attribute types such as usermods allow
multiple instances as an HSM can have more than one user module
loaded. The tables below list for each attribute type whether
multiples are allowed. For attribute types that do not allow
multiples, a parser MUST fail with an error if it encouters multiple
instances. For attribute types that allow multiples, a parser MUST
treat each one as an independent attribute and MUST NOT, for example,
consider later ones to overwrite the previous one. Appraisal
policies and profiles SHOULD be clear about how to handle multiples
when requiring attribute types that allow multiples.
Ounsworth, et al. Expires 4 September 2025 [Page 12]
Internet-Draft PKIX Key Attestation March 2025
PKIX Attestation Requests are discussed in Section 7. In the tables
in the sections that follow, the column "Request Contains a Value"
specifies whether, when the given attribute appears in a request,
whether it is to be a valued or un-valued request attribute as
described in Section 7.
4.1. Transaction Attributes
A default and vendor-agnostic set of transaction attributes is
defined in this section.
These attribute types MAY be contained within a transaction entity;
i.e. an entity identified by id-pkix-attest-entity-transaction.
+=========+==============+===================+========+========+============+
|Attribute|AttributeValue|Reference |Multiple|Request |Description |
| | | |Allowed |Contains| |
| | | | |a Value | |
+=========+==============+===================+========+========+============+
|nonce |bytes |RFCthis |No |MUST |Repeats a |
| | | | | |"nonce" |
| | | | | |provided |
| | | | | |during the |
| | | | | |atttestation|
| | | | | |request. |
+---------+--------------+-------------------+--------+--------+------------+
|timestamp|time |[I-D.ietf-rats-eat]|No |MUST NOT|The time at |
| | | | | |which this |
| | | | | |attestation |
| | | | | |was |
| | | | | |generated. |
| | | | | |Corresponds |
| | | | | |to EAT IAT |
| | | | | |claim. |
+---------+--------------+-------------------+--------+--------+------------+
Table 1
4.1.1. nonce
The nonce attribute is used to provide "freshness" quality as to the
information provided by the Attester (HSM) in the PkixAttestation
message. A client requesting a PkixAttestation message MAY provide a
nonce value as part of the request. This nonce value, if provided,
SHOULD be repeated as an attribute to the transaction entity.
Ounsworth, et al. Expires 4 September 2025 [Page 13]
Internet-Draft PKIX Key Attestation March 2025
4.1.2. time
The time at which this attestation was generated, according to the
internal system clock of the HSM.
Note that it is common for HSMs to not have an accurate system clock;
consider an HSM for a root CA kept offline and booted up infrequently
in an local network segregated from all other network, or a smart
card which boots up only when held against an NFC reader.
Implementers of emitters SHOULD include this attribute only if the
device reliably knows its own time (for example has had recent
contact with an NTP server). Implementers of parsers SHOULD be wary
of trusting the contents of this attribute. A challenge-response
protocol that makes use of the nonce attribute is a far more reliable
way of establishing freshness.
4.2. Platform Attributes
A default and vendor-agnostic set of platform attributes is defined
in this section.
These attribute types MAY be contained within a platform entity; i.e.
an entity identified by id-pkix-attest-entity-platform.
+=========+==============+===================+========+========+====================+
|Attribute|AttributeValue|Reference |Multiple|Request |Description |
| | | |Allowed |Contains| |
| | | | |a Value | |
+=========+==============+===================+========+========+====================+
|vendor |utf8String |RFCthis |No |MUST NOT|A human-readable |
| | | | | |string by which the |
| | | | | |vendor identifies |
| | | | | |themself. |
+---------+--------------+-------------------+--------+--------+--------------------+
|oemid |bytes |[I-D.ietf-rats-eat]|No |MUST NOT|The EAT OEM ID as |
| | | | | |defined in |
| | | | | |[I-D.ietf-rats-eat].|
+---------+--------------+-------------------+--------+--------+--------------------+
|hwmodel |utf8String |[I-D.ietf-rats-eat]|No |MUST NOT|Model or product |
| | | | | |line of the hardware|
| | | | | |module. |
+---------+--------------+-------------------+--------+--------+--------------------+
|hwserial |utf8String |RFCthis |No |MUST NOT|Serial number of the|
| | | | | |hardware module, |
| | | | | |often matches the |
| | | | | |number engraved or |
| | | | | |stickered on the |
| | | | | |case. |
Ounsworth, et al. Expires 4 September 2025 [Page 14]
Internet-Draft PKIX Key Attestation March 2025
+---------+--------------+-------------------+--------+--------+--------------------+
|swversion|utf8String |[I-D.ietf-rats-eat]|No |MUST NOT|A text string |
| | | | | |identifying the |
| | | | | |firmware or software|
| | | | | |running on the HSM. |
+---------+--------------+-------------------+--------+--------+--------------------+
|dbgstat |int |[I-D.ietf-rats-eat]|No |MUST NOT|Indicates whether |
| | | | | |the HSM is currently|
| | | | | |in a debug state, or|
| | | | | |is capable in the |
| | | | | |future of being |
| | | | | |turned to a debug |
| | | | | |state. Semantics |
| | | | | |and integer codes |
| | | | | |are defined in |
| | | | | |[I-D.ietf-rats-eat].|
+---------+--------------+-------------------+--------+--------+--------------------+
|uptime |int |[I-D.ietf-rats-eat]|No |MUST NOT|Contains the number |
| | | | | |of seconds that have|
| | | | | |elapsed since the |
| | | | | |entity was last |
| | | | | |booted. |
+---------+--------------+-------------------+--------+--------+--------------------+
|bootcount|int |[I-D.ietf-rats-eat]|No |MUST NOT|Contains a count of |
| | | | | |the number of times |
| | | | | |the entity has been |
| | | | | |booted. |
+---------+--------------+-------------------+--------+--------+--------------------+
|usermods |utf8String |RFCthis |Yes |MUST NOT|This attribute lists|
| | | | | |user modules |
| | | | | |currently loaded |
| | | | | |onto the HSM in a |
| | | | | |human readable |
| | | | | |format, preferabbly |
| | | | | |JSON. |
+---------+--------------+-------------------+--------+--------+--------------------+
|fipsboot |bool |[FIPS.140-3] |No |MUST NOT|Indicates whether |
| | | | | |the devices is |
| | | | | |currently running in|
| | | | | |FIPS mode. |
+---------+--------------+-------------------+--------+--------+--------------------+
|fipsver |utf8String |[FIPS.140-3] |No |MUST NOT|Indicates the |
| | | | | |version of the FIPS |
| | | | | |CMVP standard that |
| | | | | |is being enforced. |
| | | | | |At time of writing |
| | | | | |this is typically |
| | | | | |"FIPS 140-2" or |
Ounsworth, et al. Expires 4 September 2025 [Page 15]
Internet-Draft PKIX Key Attestation March 2025
| | | | | |"FIPS 140-3". |
+---------+--------------+-------------------+--------+--------+--------------------+
|fipslevel|int |[FIPS.140-3] |No |MUST NOT|Indicates the FIPS |
| | | | | |Level to which the |
| | | | | |device is currently |
| | | | | |operating in |
| | | | | |compliance with. |
+---------+--------------+-------------------+--------+--------+--------------------+
|envid |utf8String |RFCthis |Yes |MAY |An environment ID, |
| | | | | |which will typically|
| | | | | |be a URI, UUID, or |
| | | | | |similar. |
+---------+--------------+-------------------+--------+--------+--------------------+
|envdesc |utf8String |RFCthis |Yes |MUST NOT|Further description |
| | | | | |of the environment. |
+---------+--------------+-------------------+--------+--------+--------------------+
Table 2
TODO: find the actual reference for "FIPS Mode" -- FIPS 140-3 does
not define it (at least not the 11 page useless version of 140-3 that
I found).
Each attribute has an assigned OID, see Section 9.
Some of the attributes defined in this specification have further
details below.
4.2.1. usermods
Most HSMs have some concept of trusted execution environment where
user software modules can be loaded inside the HSM to run with some
level of privileged access to the application keys. This attribute
lists user modules currently loaded onto the HSM in a human readable
format, preferably JSON.
4.2.2. fipsboot, fipsver and fipslevel
FIPS 140-3 CMVP validation places stringent requirements on the mode
of operation of the device and the cryptography offered by the
module, including only enabling FIPS-approved algorithms, 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.
Ounsworth, et al. Expires 4 September 2025 [Page 16]
Internet-Draft PKIX Key Attestation March 2025
The boolean attribute fipsboot indicates whether the device is
currently operating in FIPS mode. For most HSMs, changing this
configuration setting from fipsboot=true to fips-boos=false is
destructive and will result in zeroization of all cryptographic keys
held within the module.
The UTF8String attribet fipsver indicates the version of the FIPS
CMVP specification with which the device's operational mode is
compliant. At the time of writing, the strings "FIPS 140-2" or "FIPS
140-3" SHOULD be used.
The integer attribute fipslevel indicates the compliance level to
which the device is currently operating and MUST only be 1, 2, 3, or
4. The fipslevel attribute has no meaning if fipsboot is absent or
false.
The FIPS status information in a PKIX Attestation indicates only the
mode of operation of the device and is not authoritative of its
validation status. This information is available on the NIST CMVP
website 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 sumbitted 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 and certified to Level
2. A Relying Party wishing to know the validation status of the
device MUST couple the device state information contained in the
attestation with a valid FIPS CMVP certificate for the device.
4.2.3. envid
An identifier for an environment to which the attested keys belong.
These will be an a vendor-chosen format, but are constrained to ASCII
as URIs, UUID, and similar types of identifiers are envisioned.
There MAY be multiple envid attributes if the attested keys
simultaneously belong to multiple environments.
Note that by including envid as a Platform Attribute, this implies
that it applies to all attested key entities. If the HSM needs to
attest multiple keys across multiple disjoint environments, then
multiple PKIXAttestations are required. This naturally enforces
privacy constraints of only attesting a single environment at a time.
If an envdid request attribute contains a value, this means that the
Presenter is requesting that only keys belogning to the given
environment be included in the returned attestation.
Ounsworth, et al. Expires 4 September 2025 [Page 17]
Internet-Draft PKIX Key Attestation March 2025
4.2.4. envdesc
Further description of the environment beyond hwvendor, hwmodel,
hwserial, swversion; for example if there is a need to describe
multiple logical partitions within the same device. Contents could
be a human-readable description or other identifiers.
4.3. Key Attributes
A default and vendor-agnostic set of key attributes is defined in
this section.
These attribute types MAY be contained within a key entity; i.e. an
entity identified by id-pkix-attest-entity-key.
+===========+==============+=========+========+========+======================+
|Attribute |AttributeValue|Reference|Multiple|Request |Description |
| | | |Allowed |Contains| |
| | | | |a Value | |
+===========+==============+=========+========+========+======================+
|identifier |utf8String |RFCthis |Yes |MAY |Identifies the subject|
| | | | | |key, with a vendor- |
| | | | | |specific format which |
| | | | | |could be numeric, |
| | | | | |UUID, or other textual|
| | | | | |identifier. |
+-----------+--------------+---------+--------+--------+----------------------+
|spki |bytes |RFCthis |No |MAY |A complete DER-encoded|
| | | | | |SubjectPublicKeyInfo |
| | | | | |representing the |
| | | | | |public key associated |
| | | | | |with the asymetric key|
| | | | | |pair being attested. |
+-----------+--------------+---------+--------+--------+----------------------+
|purpose |bytes |[PKCS11] |No |MAY |Defines the intended |
| | | | | |usage for the key. |
+-----------+--------------+---------+--------+--------+----------------------+
|extractable|bool |[PKCS11] |No |MAY |Indicates if the key |
| | | | | |is able to be exported|
| | | | | |from the module. |
| | | | | |Corresponds directly |
| | | | | |to PKCS#11 |
| | | | | |CKA_EXTRACTABLE. |
+-----------+--------------+---------+--------+--------+----------------------+
|sensitive |bool |[PKCS11] |No |MAY |Indicates that the key|
| | | | | |cannot leave the |
| | | | | |module in plaintext. |
| | | | | |Corresponds directly |
Ounsworth, et al. Expires 4 September 2025 [Page 18]
Internet-Draft PKIX Key Attestation March 2025
| | | | | |to PKCS#11 |
| | | | | |CKA_SENSITIVE. |
+-----------+--------------+---------+--------+--------+----------------------+
|never- |bool |[PKCS11] |No |MAY |Indicates if the key |
|extractable| | | | |was able to be |
| | | | | |exported from the |
| | | | | |module. Corresponds |
| | | | | |directly to PKCS#11 |
| | | | | |CKA_NEVER_EXTRACTABLE.|
+-----------+--------------+---------+--------+--------+----------------------+
|local |bool |RFCthis |No |MAY |Indicates whether the |
| | | | | |key was generated |
| | | | | |locally or imported. |
+-----------+--------------+---------+--------+--------+----------------------+
|expiry |time |RFCthis |No |MAY |Defines the expiry |
| | | | | |date or "not after" |
| | | | | |time for the key. |
+-----------+--------------+---------+--------+--------+----------------------+
|protection |bytes |RFCthis |No |MAY |Indicates any |
| | | | | |additional key |
| | | | | |protection properties.|
+-----------+--------------+---------+--------+--------+----------------------+
Table 3
PKCS#11 private key attributes can be somewhat complex to parse,
especially as their exact meanings can vary by the key type and the
exact details of key export mechanisms supported by the HSM.
In most cases, the Verifier of a PKIX Attestation will want to know
simply that the key is in hardware and cannot be extracted to be used
with a software cryptographic module. A setting of extractable=false
satisfies this requirement. Generally extractable=true &&
sensitive=true also satisfies this requirement as the key cannot be
extracted in plaintext, but only under key wrap. This is common in
HSM clustering scenarios, and is also common in scenarios where keys
are exported under wrap so that they can be stored in an off-board
database for re-import later, thus allowing the HSM to protect and
manage a much larger set of keys than it has internal memory for.
The never-extractable and local attributes give additional assurance
that the key has always been in hardware and was not imported from
software.
4.3.1. purpose
TODO: probably need to define a mapping from PKCS#11 CKA enums to a
bit-indexed byte array.
Ounsworth, et al. Expires 4 September 2025 [Page 19]
Internet-Draft PKIX Key Attestation March 2025
4.3.2. protection
Indicates any additional key protection properties around use or
modification of this key. These are generalized properties and will
not apply the same way to all HSM vendors. Consult vendor
documentation for the in-context meaning of these flags.
TODO: define a bit-indexed byte array
BIT MASK / Boolean Array {DualControl (0), CardControl (1),
PasswordControl (2), ...}
We may need to say that the first X are reserved for use by future
RFCs that update this specification, and beyond that is private use.
4.4. Additional Entity and Attribute Types
It is expected that HSM vendors will register additional Entity and
Attribute types by assigning OIDs from their own proprietary OID arcs
to hold data describing additional proprietary key properties.
An Attester (HSM) which is requested to provide information about
unrecognized Entity or Attribute types MUST fail the operation.
A Verifier which encounters an unrecognized Entity or Attribute type
MAY ignore it.
4.5. Encoding
A PKIXAttestation is to be DER encoded [X.690].
If a textual representation is required, then the DER encoding MAY be
subsequently encoded into Base64.
EDNOTE: I think we have to be precise about which flavour of Base64
we are referrring to.
5. Signing Procedure
The SignatureBlock.signatureValue signs over the DER-encoded to-be-
signed attestation data PkixAttestation.tbs and MUST be validated
with the subject public key of the leaf X.509 certificate contained
in the SignatureBlock.certChain.
Ounsworth, et al. Expires 4 September 2025 [Page 20]
Internet-Draft PKIX Key Attestation March 2025
6. Verification Procedure
The SignatureBlock.signatureValue signs over the DER-encoded to-be-
signed attestation data PkixAttestation.tbs and MUST be validated
with the subject public key of the leaf X.509 certificate contained
in the SignatureBlock.certChain.
Note that a PkixAttestation MAY contain zero or more SignatureBlocks.
A PkixAttestation with zero SignatureBlocks is unsigned, MUST be
treated as un-protected and un-trusted, and any signature validation
procedure MUST fail.
More than one SignatureBlocks MAY be used to convey a number of
different semantics. For example, the HSM's Attesting Service might
hold multiple Attestation Keys on different cryptographic algorithms
in order to provide algorithm redundancy in the case that one
algorithm becomes cryptographically broken. In this case a Verifier
would be expected to validate all SignatureBlocks. Alternatively,
the HSM's Attesting Service may hold multiple Attestion Keys (or
multiple X.509 certificates for the same key) from multiple
operational environments to which it belongs. In this case a
Verifier would be expected to only validate the SignatureBlock
corresponding to its own environment. Alternatively, multiple
SignatureBlocks could be used to convey counter-signatures from
external parties, in which case the Verifier will need to be equipped
with environment-specific verification logic. Multiple of these
cases, and potentially others, could be present in a single
PkixAttestation object.
Note that each SignatureBlock is a fully detached signature over the
tbs content with no binding between the signed content and the
SignatureBlocks, or between SignatureBlocks, meaning that a third
party can add a counter-signature of the evidence after the fact, or
an attacker can remove a SignatureBlock without leaving any artifact.
See {#sec-detached-sigs} for further discussion.
7. Attestation Requests
EDNOTE: MikeO: this is complex, but I'm not really sure how to define
a request format in any simpler way. Ideas are welcome!
This section specifies a standardized format that a Presenter can use
to request a PKIX Attestation about a specific key or set of keys, a
specific environment, or containing specific attributes.
Ounsworth, et al. Expires 4 September 2025 [Page 21]
Internet-Draft PKIX Key Attestation March 2025
Hardware Security Modules range greatly in size and complexity from
personal cryptographic tokens containing a single application key
such as a smartcard acting as a personal ID card, up to clusters of
enterprise-grade HSMs serving an entire cloud service.
The manufacturer of a HSM device with limited capabilities may
implement a response to the attestation request which includes a
fixed set of reported entities, each with a fixed set of reported
attributes and parses an Attestion Request object only for the
purposes of extracting the nonce.
On the other hand, an enterprise grade HSM with the capability to
hold a large number of private keys is expected to be capable of
parsing attestation requests such that a Presenter can request
attestation of specific key(s) by their identifier, or request
attestation of all keys with given key attributes within a given sub-
environment of the HSM. A full implementation will also create a
PKIX Attestation containing exactly the set of requested attributes
so that the Presenter can fine-tune the information that it wishes to
disclose to the Recipient.
A PKIX Attestation Request consists of a un-signed TbsPkixAttestation
object containing a single ReportedEntity identified with id-pkix-
attest-entity-request, called a request entity. A TbsPkixAttestation
containing a request entity MUST NOT contain any other type of
entities. Request entities MAY contain Attributes of any type;
transaction, platform, key, or any additional attribute type. Any
attribute contained in a request entity is called a request
attribute. Request entities MUST NOT appear in PKIX Attestation
response objects. The TbsPkixAttestation object of an attestation
request MAY appear inside a signed PKIXAttestation for the purposes
of authenticating and authorizing the requester, but the semantics of
doing so are left to the implementer.
An Attester that supports Attestation Requests MUST, at the minimum,
support extracting the value from a nonce attribute and echoing it
into a nonce attribute within a TransactionEntity.
Some request attributes contain a value that the HSM uses as a filter
or search parameter in constructing the PKIX Attestation; these are
called valued requests attributes. Other requests attributes omit
the optional value field so that they consist of only the attribute
type OID and indicate that the HSM SHOULD collect and return the
appropriate measurement; these are called un-valued request
attributes. An Attester SHOULD return a PKIX Attestation containing
exactly the set of attributes listed in the request, including both
valued and un-valued request attributes but MAY omit requested
attributes if it cannot be measured in the current device
Ounsworth, et al. Expires 4 September 2025 [Page 22]
Internet-Draft PKIX Key Attestation March 2025
configuration. Note that an Attestation Request will contain all
request attributes inside a single request entity, but the HSM MUST
sort the attributes in the response PKIX Attestation into the
appropriate entity types. For example, if the request contains the
key purpose attribute (either valued or un-valued), then all returned
key entities will contain the purpose attribute when this data is
available for the given key. The tables in the following sections
indicate whether an attribute of the given type MUST, MAY, or MUST
NOT contain a value when included in a request entity.
Generally errors should be handled gracefully by simply omitting an
unfulfillable request attribute from the response. An example would
be if the hwserial attribute was requested but the devices does not
have a serial number. However in some cases a fatal error MAY be
returned, for example if attestation of a specific key is requested
by key identifier or SubjectPublicKeyInfo but the HSM does not
contain a matching key. HSMs SHOULD ignore request attributes with
unrecognized type OIDs.
Generally, the Attester SHOULD NOT include additional attributes
beyond those that were requested. This is to allow the Presenter to
fine-tune the information that will be disclosed to the Recipient.
Further privacy concerns are discussed in Section 11.3. However, in
some contexts this MAY be appropriate, for example, a request
containing only a key identifier attribute could be responded to with
the full set of platform and key attributes that apply to that key.
Discretion is left to implementers.
For both error handling and privacy reasons, the Presenter SHOULD
check that the returned PKIX Attestation contains the expected
attributes prior to forwarding it to the Recipient.
8. Appraisal Policies and Profiles
This section provides some sample profiles of appraisal policies that
verifiers MAY apply when evaluating evidence. These appraisal
profiles represent environment-specific requirements on the contents
of the evidence and / or endorsement certificate chain.
8.1. Key Import into an HSM
An HSM which is compliant with this draft SHOULD validate any PKIX
Key Attestations that are provided along with the key being imported.
Ounsworth, et al. Expires 4 September 2025 [Page 23]
Internet-Draft PKIX Key Attestation March 2025
The SignatureBlocks MUST be validated and MUST chain to a trust
anchor known to the HSM. In most cases this will be the same trust
anchor that endorsed the HSMs own AK, but the HSM MAY be configured
with set of third party trust anchors from which it will accept key
attestations.
If the HSM is operating in FIPS Mode, then it MUST only import keys
from HSMs also operating in FIPS Mode.
The claims key-purpose, key-extractable, key-never-extractable, key-
local MUST be checked and honoured during key import, which typically
means that after import, the key MUST NOT claim a stronger protection
property than it had on the previous hardware. In other words, Key
Attestation allows and requires that key protection properties be
preserved over export / import operations between different HSMs, and
this format provides a vendor-agnostic way to acheive this.
How to handle errors is outside the scope of this specification and
is left to implementors; for example the key import MAY be aborted,
or a prompt MAY be given to the user administrator, or any similar
reasonable error handling logic.
8.2. CA/Browser Forum Code-Signing
TODO: ... intro text
The subscriber MUST:
* Provide the CA with a CSR containing the subscriber key.
* Provide an attestation token as per this specification describing
the private key protection properties of the subscriber's private
key. This token MAY be transported inside the CSR as per draft-
ietf-lamps-csr-attest, or it MAY be transported adjacent to the
CSR over any other certificate enrollment mechanism.
The CA / RA / RP / Verifier MUST:
* Ensure that the subscriber key which is the subject of the CSR is
also described by a KAT by matching either the key fingerprint or
full SubjectPublicKeyInfo.
* The hardware root-of-trust described by a PAT has a valid and
active FIPS certificate according to the NIST CMVP database.
* The attestation signing key (AK) which has signed the attestation
token chains to a root certificate that A) belongs to the hardware
vendor described in the PAT token, and B) is trusted by the CA /
Ounsworth, et al. Expires 4 September 2025 [Page 24]
Internet-Draft PKIX Key Attestation March 2025
RA / RP / Verifier to endorse hardware from this vendor, for
example through a CA's partner program or through a network
operator's device on-boarding process.
* The key is protected by a module running in FIPS mode. The
parsing logic is to start at the leaf KAT token that matches the
key in the CSR and parsing towards the root PAT ensuring that
there is at least one fipsboot=true and no fipsboot=false on that
path.
9. ASN.1 Module
<CODE STARTS>
PKIX-Key-Attest-2025
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkik-key-attest-2025(TBDMOD) }
PkixAttestation ::= SEQUENCE {
tbs TbsPkixAttestation,
signatures SEQUENCE SIZE (0..MAX) of SignatureBlock
}
TbsPkixAttestation ::= SEQUENCE {
version INTEGER,
reportedEntities SEQUENCE SIZE (1..MAX) OF ReportedEntity
}
ReportedEntity ::= SEQUENCE {
entityType OBJECT IDENTIFIER,
reportedAttributes SEQUENCE SIZE (1..MAX) OF ReportedAttribute
}
ReportedAttribute ::= SEQUENCE {
attributeType OBJECT IDENTIFIER,
value AttributeValue
}
AttributeValue :== CHOICE {
bytes [0] IMPLICIT OCTET STRING
utf8String [1] IMPLICIT UTF8String,
bool [2] IMPLICIT BOOLEAN,
time [3] IMPLICIT GeneralizedTime,
int [4] IMPLICIT INTEGER,
oid [5] IMPLICIT OBJECT IDENTIFIER
}
Ounsworth, et al. Expires 4 September 2025 [Page 25]
Internet-Draft PKIX Key Attestation March 2025
SignatureBlock ::= SEQUENCE {
certChain SEQUENCE of Certificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue OCTET STRING
}
id-pkix-attest OBJECT IDENTIFIER ::= { 1 2 3 999 }
id-pkix-attest-entity-type OBJECT IDENTIFIER ::= { id-pkix-attest 0 }
id-pkix-attest-entity-transaction OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 0 }
id-pkix-attest-entity-platform OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 1 }
id-pkix-attest-entity-key OBJECT IDENTIFIER ::= { id-pkix-attest-entity-type 2 }
id-pkix-attest-attribute-type OBJECT IDENTIFIER ::= { id-pkix-attest 1 }
id-pkix-attest-attribute-transaction OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-type 0 }
id-pkix-attest-attribute-transaction-nonce OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-transaction 0 }
id-pkix-attest-attribute-platform OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-type 1 }
id-pkix-attest-attribute-platform-vendor OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 0 }
id-pkix-attest-attribute-platform-hwserial OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 1 }
id-pkix-attest-attribute-platform-fipsboot OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 2 }
id-pkix-attest-attribute-platform-desc OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 3 }
id-pkix-attest-attribute-platform-time OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 4 }
id-pkix-attest-attribute-platform-swversion OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 5 }
id-pkix-attest-attribute-platform-oemid OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 6 }
id-pkix-attest-attribute-platform-debugstat OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 7 }
id-pkix-attest-attribute-platform-uptime OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 8 }
id-pkix-attest-attribute-platform-bootcount OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 9 }
id-pkix-attest-attribute-platform-usermods OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 8 }
id-pkix-attest-attribute-platform-envid OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 9 }
id-pkix-attest-attribute-platform-envdesc OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 10 }
id-pkix-attest-attribute-platform-fipsver OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 11 }
id-pkix-attest-attribute-platform-fipslevel OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-platform 12 }
id-pkix-attest-attribute-key OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-type 2 }
id-pkix-attest-attribute-key-identifier OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 0 }
id-pkix-attest-attribute-key-spki OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 1 }
id-pkix-attest-attribute-key-purpose OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 2 }
id-pkix-attest-attribute-key-extractable OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 3 }
id-pkix-attest-attribute-key-never-extractable OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 4 }
id-pkix-attest-attribute-key-local OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 5 }
id-pkix-attest-attribute-key-expiry OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 6 }
id-pkix-attest-attribute-key-protection OBJECT IDENTIFIER ::= { id-pkix-attest-attribute-key 7 }
<CODE ENDS>
Ounsworth, et al. Expires 4 September 2025 [Page 26]
Internet-Draft PKIX Key Attestation March 2025
10. IANA Considerations
Please replace "RFCthis" with the RFC number assigned to this
document.
TODO: list out all the OIDs that need IANA registration.
11. Security Considerations
A Verifier MAY reject a PKIX Attestation if it lacks required
attributes per their appraisal policy. For example, if a Relying
Party mandates a FIPS-certified device, it SHOULD reject evidence
lacking sufficient information to verify the device's FIPS
certification status.
11.1. Simple to Implement
The nature of attestation requires the attestation service to be
implemented in an extremely privileged position within the HSM so
that it can collect measurements of both the hardware environment and
the application keys being attested. For many HSM and TPM
architectures, this will place the Attestation Service inside the
"HSM kernel" and potentially subject to FIPS 140-3 or Common Criteria
validation and change control. For both security and compliance
reasons there is incentive for the emitting and parsing logic to be
simple and easy to implement correctly. Additionally, when the data
formats contained in this specification are parsed within an HSM
boundary -- that would be parsing a request entity, or parsing an
attestation produced by a different HSM -- implementers SHOULD opt
for simple logic that rejects any data that does not match the
expected format instead of attempting to be flexible.
In particular, Attesting Services SHOULD generate the attestation
object from scratch and avoid copying any content from the request.
Attesting Services MUST NOT allow unrecognized attributes or any
attribute value other than the nonce to be echoed from the request
into the attestation object.
11.2. Detached Signatures
TODO beef this up
No indication within the tbs content about what or how many
signatures to expect.
A SignatureBlock can be trivially stripped off without leaving any
evidence.
Ounsworth, et al. Expires 4 September 2025 [Page 27]
Internet-Draft PKIX Key Attestation March 2025
When multiple SignatureBlocks are used for providing third party
counter-signatures, note that the counter signature only covers the
tbs content and not existing SignatureBlocks.
11.3. Privacy
Often, a TPM will host cryptographic keys for both the kernel and
userspace of a local operating system but a Presenter may only
represents a single user or application. Similarly, a single
enterprise-grade Hardware Security Module will often host
cryptographic keys for an entire multi-tenant cloud service and the
Presenter or Reciever or Recipient belongs only to a single tenant.
For example the HSM backing a TLS-terminating loadbalancer fronting
thousands of un-related web domains. In these cases, disclosing that
two different keys reside on the same hardware, or in some cases even
disclosing the existance of a given key, let alone its attributes, to
an unauthorized party would constitute an egregious privacy
violation.
Implementions SHOULD be careful to avoid over-disclosure of
information, for example by authenticating the Presenter as described
in Section 11.4 and only returning results for keys and envirnments
for which it is authorized. In absence of an existing mechanism for
authenticating and authorizing administrative connections to the HSM,
the attestation request MAY be authenticated by embedding the
TbsPkixAttestation of the request inside a PKIXAttestation signed
with a certificate belogning to the Presenter.
Furthermore, enterprise and cloud-services grade HSMs SHOULD support
the full set of attestation request functionality described in
Section 7 so that Presenters can fine-tune the content of a PKIX
Attestation such that it is appropriate for the intended Recipient.
11.4. Authenticating and Authorizing the Presenter
The Presenter represents a priviledged role within the architecture
of this specification as it gets to learn about the existence of
application keys and their protection properties, as well as details
of the platform. The Presenter is in the position of deciding how
much information to disclose to the Recipient, and to request a
suitably redacted attestation from the HSM.
Ounsworth, et al. Expires 4 September 2025 [Page 28]
Internet-Draft PKIX Key Attestation March 2025
For personal cryptographic tokens it might be appropriate for the
attestation request interface to be un-authenticated. However, for
enterprise and cloud-services grade HSMs the Presenter SHOULD be
authenticated using the HSM's native authentication mechanism. The
details will be HSM-specific and are thus left up to the implementer,
however it is RECOMMENDED to implement an authorization framework
similar to the following.
A Presenter SHOULD be allowed to request attestation for any
application keys which it is allowed to use. For example, a TLS
application that is correctly authenticated to the HSM in order to
use its TLS keys SHOULD be able to request attestation of those same
keys without needing to perform any additional authentication or
requiring any additional roles or permissions. HSMs that wish to
allow a Presenter to request attestation of keys which is not allowed
to use, for example for the purposes of displaying HSM status
information on an administrative console or UI, SHOULD have a
"Attestation Requester" role or permission and SHOULD enforce the
HSM's native access controls such that the Presenter can only
retrieve attestations for keys for which it has read access.
11.5. Proof-of-Possession of Application 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
mechnaism for PoP of application keys and relies on the Presenter,
Recipient, Verifier, and Relying Party trusting the Attester to
correctly report the cryptographic keys that it is holding.
It would be easy to add a PoP Key Attribute that uses the attested
application key to sign over, for example, the Transaction Entity,
however this is a bad idea and MUST NOT be added as a custom
attribute for several reasons.
First, an application key intended, for example, for TLS SHOULD only
be used with the TLS protocol and introducing a signature oracle
whereby the TLS application key is used to sign attestation content
could lead to cross-protocol attacks whereby the attacker submits 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 who has connected to the HSM to request an
attestation may have permissions to view the requested application
keys but not permission to use them, as in the case where the
Presenter is an administrative UI displaying HSM status information
Ounsworth, et al. Expires 4 September 2025 [Page 29]
Internet-Draft PKIX Key Attestation March 2025
to an systems administrator or auditor. Requiring the Attestation
Service to use the attested application keys could, in some
architectures, require the Attestation Service to resolve complex
access control logic and handle complex error conditions for each
requested key, which violates the "simple to implement" design
principle outlined in Section 11.1. More discussion of
authenticating the Presenter can be found in Section 11.4.
In cases where explicit PoP is required for a given attested
application key, it MUST be done as part of the regular usage
protocol for which that key is intended and performed through the
HSM's regular application interface, not its attestation interface.
For example, PoP could be performed by signing a Certificate Signing
Request (CSR), through a PKI enrollment protocol such as Certificate
Management Protocol (CMP) which includes a challenge-response PoP, by
using the key within a TLS handshake, or some other protocol which is
part of the key's intended usage.
12. References
12.1. Normative References
[FIPS.140-3]
NIST - Information Technology Laboratory, "SECURITY
REQUIREMENTS FOR CRYPTOGRAPHIC MODULES", FIPS 140-3, n.d.,
<https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.140-3.pdf>.
[I-D.ietf-rats-eat]
Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", Work in
Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
September 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-eat-31>.
[PKCS11] Cox, T., "PKCS #11 Specification Version 3.1", n.d.,
<https://docs.oasis-open.org/pkcs11/pkcs11-spec/v3.1/cs01/
pkcs11-spec-v3.1-cs01.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Ounsworth, et al. Expires 4 September 2025 [Page 30]
Internet-Draft PKIX Key Attestation March 2025
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[X.680] ITU-T, "Information technology -- Abstract Syntax Notation
One (ASN.1): Specification of basic notation", n.d.,
<https://www.itu.int/rec/T-REC-X.680>.
[X.690] ITU-T, "Information technology - ASN.1 encoding Rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", ISO/IEC 8825-1:2015, November 2015.
12.2. Informative References
[I-D.fossati-tls-attestation]
Tschofenig, H., Sheffer, Y., Howard, P., Mihalcea, I.,
Deshpande, Y., Niemi, A., and T. Fossati, "Using
Attestation in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS)", Work in Progress,
Internet-Draft, draft-fossati-tls-attestation-08, 21
October 2024, <https://datatracker.ietf.org/doc/html/
draft-fossati-tls-attestation-08>.
[I-D.ietf-lamps-csr-attestation]
Ounsworth, M., Tschofenig, H., Birkholz, H., Wiseman, M.,
and N. Smith, "Use of Remote Attestation with
Certification Signing Requests", Work in Progress,
Internet-Draft, draft-ietf-lamps-csr-attestation-17, 2
March 2025, <https://datatracker.ietf.org/doc/html/draft-
ietf-lamps-csr-attestation-17>.
Ounsworth, et al. Expires 4 September 2025 [Page 31]
Internet-Draft PKIX Key Attestation March 2025
[I-D.ietf-rats-msg-wrap]
Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-12,
28 February 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-12>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211,
DOI 10.17487/RFC4211, September 2005,
<https://www.rfc-editor.org/rfc/rfc4211>.
[RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management
Requirements", RFC 6024, DOI 10.17487/RFC6024, October
2010, <https://www.rfc-editor.org/rfc/rfc6024>.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021,
<https://www.rfc-editor.org/rfc/rfc9019>.
Appendix A. Samples
A reference implementation of this specification can be found at
https://github.com/hannestschofenig/keyattestation
It produces the following sample attestation:
PkixAttestation:
tbs=TbsPkixAttestation:
version=2
reportedEntities=SequenceOf:
ReportedEntity:
entityType=1.2.3.999.0.0
reportedAttributes=SequenceOf:
ReportedAttribute:
attributeType=1.2.3.999.1.0.0
value=AttributeValue:
bytes=0102030405
ReportedEntity:
entityType=1.2.3.999.0.1
Ounsworth, et al. Expires 4 September 2025 [Page 32]
Internet-Draft PKIX Key Attestation March 2025
reportedAttributes=SequenceOf:
ReportedAttribute:
attributeType=1.2.3.999.1.1.0
value=AttributeValue:
utf8String=HSM-123
ReportedAttribute:
attributeType=1.2.3.999.1.1.1
value=AttributeValue:
bool=True
ReportedAttribute:
attributeType=1.2.3.999.1.1.2
value=AttributeValue:
utf8String=Model ABC
ReportedAttribute:
attributeType=1.2.3.999.1.1.4
value=AttributeValue:
utf8String=3.1.9
ReportedAttribute:
attributeType=1.2.3.999.1.1.3
value=AttributeValue:
time=202502032234Z
ReportedEntity:
entityType=1.2.3.999.0.2
reportedAttributes=SequenceOf:
ReportedAttribute:
attributeType=1.2.3.999.1.2.0
value=AttributeValue:
utf8String=26d765d8-1afd-4dfb-a290-cf867ddecfa1
ReportedAttribute:
attributeType=1.2.3.999.1.2.3
value=AttributeValue:
bool=False
ReportedAttribute:
attributeType=1.2.3.999.1.2.1
value=AttributeValue:
bytes=0x3059301306072a8648ce3d020106082a8648ce3d03010703420004422548f88fb782ffb5eca3744452c72a1e558fbd6f73be5e48e93232cc45c5b16c4cd10c4cb8d5b8a17139e94882c8992572993425f41419ab7e90a42a494272
ReportedEntity:
entityType=1.2.3.999.0.2
Ounsworth, et al. Expires 4 September 2025 [Page 33]
Internet-Draft PKIX Key Attestation March 2025
reportedAttributes=SequenceOf:
ReportedAttribute:
attributeType=1.2.3.999.1.2.0
value=AttributeValue:
utf8String=49a96ace-e39a-4fd2-bec1-13165a99621c
ReportedAttribute:
attributeType=1.2.3.999.1.2.3
value=AttributeValue:
bool=True
ReportedAttribute:
attributeType=1.2.3.999.1.2.1
value=AttributeValue:
bytes=0x3059301306072a8648ce3d020106082a8648ce3d03010703420004422548f88fb782ffb5eca3744452c72a1e558fbd6f73be5e48e93232cc45c5b16c4cd10c4cb8d5b8a17139e94882c8992572993425f41419ab7e90a42a494272
ReportedEntity:
entityType=1.2.3.888.0
reportedAttributes=SequenceOf:
ReportedAttribute:
attributeType=1.2.3.888.1
value=AttributeValue:
utf8String=partition 1
signatures=SequenceOf:
SignatureBlock:
certChain=SequenceOf:
Certificate:
tbsCertificate=TBSCertificate:
version=v3
serialNumber=510501933685942792810365453374472870755160518925
signature=AlgorithmIdentifier:
algorithm=1.2.840.113549.1.1.11
parameters=0x0500
issuer=Name:
rdnSequence=RDNSequence:
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.10
value=0x0c0449455446
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.11
Ounsworth, et al. Expires 4 September 2025 [Page 34]
Internet-Draft PKIX Key Attestation March 2025
value=0x0c0452415453
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.3
value=0x0c06414b20525341
validity=Validity:
notBefore=Time:
utcTime=250117171303Z
notAfter=Time:
generalTime=20520604171303Z
subject=Name:
rdnSequence=RDNSequence:
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.10
value=0x0c0449455446
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.11
value=0x0c0452415453
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.3
value=0x0c06414b20525341
subjectPublicKeyInfo=SubjectPublicKeyInfo:
algorithm=AlgorithmIdentifier:
algorithm=1.2.840.113549.1.1.1
parameters=0x0500
subjectPublicKey=31795268810366627125468059984427145931784542919710733587190808152893606542214208096328883077225607136393362795609997601968312039001251339428349101203532726047646450301142882318337709398316574407647199690000689245113739552615279534528145776090813314822312012607567736073057936820713733090928849092672110937300300755561797808000438134839458043673852453722969649609202093945235393494912138691342219564365300965387743701570507112064401758218314760153081271981340812350365663466513620853326534252424706992841033652817461354632316129312597825542820569667842318342646457447037125609399476844336456206583416539426479221164971369788464727307915820767918489601
extensions=Extensions:
Extension:
extnID=2.5.29.14
critical=False
extnValue=0x04148919595e0ef169f5cbbd47e134fce298cc693091
Extension:
extnID=2.5.29.35
critical=False
extnValue=0x301680148919595e0ef169f5cbbd47e134fce298cc693091
Extension:
Ounsworth, et al. Expires 4 September 2025 [Page 35]
Internet-Draft PKIX Key Attestation March 2025
extnID=2.5.29.19
critical=True
extnValue=0x30030101ff
signatureAlgorithm=AlgorithmIdentifier:
algorithm=1.2.840.113549.1.1.11
parameters=0x0500
signature=12977775424631768289542539102653382982431795551146145281750189553757940982572813264428982985997740595878077027853994515775116752030963858469651548765808775269857271167748512795017916284867051302884465315751010913658016640170608413935780119349866986170148033301955753116984041271273907756544780231564646860424999020990745523383622980115200446260103173103500647838758197610238552349053064525420240826193553395378873725256584269666918504793674497748455574822238022085054752185687440807655337724821853332688158460379554906105417720665175648371832825939577039874730442790337726004105878168375998123110331993348833629325492
signatureAlgorithm=AlgorithmIdentifier:
algorithm=1.2.840.113549.1.1.10
parameters=RSASSA_PSS_params:
hashAlgorithm=AlgorithmIdentifier:
algorithm=2.16.840.1.101.3.4.2.1
maskGenAlgorithm=AlgorithmIdentifier:
algorithm=1.2.840.113549.1.1.8
saltLength=20
trailerField=1
signatureValue=0x9b6ac1932f1cd85befbde054e084577ebc9181bcf05179658a700e22556fc3f1931f59dc9734efe08df204fcfe55c64c6a97e8d520e58c1f64080b6cce1c08e88db510c06d6914a818b70df82326b37a2abe54fab0567d748e1e82e2de954cac63c5ab3bc92fff9cb8aa64fbcb83dd8bacbce96392f91dd40ee05058adceb11f5cf0c379241fd470918abceea70fd01c0cbc64d96067fe549ec443738655bc2bcf7e5bd54c15d5e5ac2f4ad180d973a7e6025126ccd2b45d78e9944662237959ef73f47e9ae0fa9b0c55177bb6f867a90b41d0efb72c192f15a66531d030bc85fed3d135aea4045e024ef2e807517504d313dbea4b0f709d0553b60793b2dcaa
SignatureBlock:
certChain=SequenceOf:
Certificate:
tbsCertificate=TBSCertificate:
version=v3
serialNumber=43752118382009037811618748949928339462896457144
signature=AlgorithmIdentifier:
algorithm=1.2.840.10045.4.3.2
issuer=Name:
rdnSequence=RDNSequence:
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.10
value=0x0c0449455446
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.11
value=0x0c0452415453
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.3
value=0x0c07414b2050323536
Ounsworth, et al. Expires 4 September 2025 [Page 36]
Internet-Draft PKIX Key Attestation March 2025
validity=Validity:
notBefore=Time:
utcTime=250117171428Z
notAfter=Time:
generalTime=20520604171428Z
subject=Name:
rdnSequence=RDNSequence:
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.10
value=0x0c0449455446
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.11
value=0x0c0452415453
RelativeDistinguishedName:
AttributeTypeAndValue:
type=2.5.4.3
value=0x0c07414b2050323536
subjectPublicKeyInfo=SubjectPublicKeyInfo:
algorithm=AlgorithmIdentifier:
algorithm=1.2.840.10045.2.1
parameters=0x06082a8648ce3d030107
subjectPublicKey=57095560233504924588952816185508037812996307929249104847846164660564888397123390877585670462836285725041261897550020311481127562655774333675293173915140722
extensions=Extensions:
Extension:
extnID=2.5.29.14
critical=False
extnValue=0x04145b70a79817f79ff637d2f7e3dc446c2109d7bbd4
Extension:
extnID=2.5.29.35
critical=False
extnValue=0x301680145b70a79817f79ff637d2f7e3dc446c2109d7bbd4
Extension:
extnID=2.5.29.19
critical=True
extnValue=0x30030101ff
signatureAlgorithm=AlgorithmIdentifier:
algorithm=1.2.840.10045.4.3.2
Ounsworth, et al. Expires 4 September 2025 [Page 37]
Internet-Draft PKIX Key Attestation March 2025
signature=182167519797146035745575043154801415115532979136731128676399180692664821804883990401552040789643013103202424486088058364982966709324496782518079519267269438816178719668437
signatureAlgorithm=AlgorithmIdentifier:
algorithm=1.2.840.10045.2.1
parameters=0x06082a8648ce3d030107
signatureValue=0x304402201e7703f63bff951917714e5fa813de5265f151a6802165ef0be5f1fe6c91225b02200ad06b41a5062b07ff3ad37c7d112e19575f0e14a9750fe95e615550b88b5fed
DER Base64:
MIIIyzCCAiUCAQIwggIeMCEGBioDh2cAADAXMBUGByoDh2cBAAAECjAxMDIwMzA0MDUwbgYGKgOHZwABMGQwEgYHKgOHZwEBAAwHSFNNLTEyMzAMBgcqA4dnAQEBAQH/MBQGByoDh2cBAQIMCU1vZGVsIEFCQzAQBgcqA4dnAQEEDAUzLjEuOTAYBgcqA4dnAQEDGA0yMDI1MDIwMzIyMzRaMIGyBgYqA4dnAAIwgacwLwYHKgOHZwECAAwkMjZkNzY1ZDgtMWFmZC00ZGZiLWEyOTAtY2Y4NjdkZGVjZmExMAwGByoDh2cBAgMBAQAwZgYHKgOHZwECAQRbMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEQiVI+I+3gv+17KN0RFLHKh5Vj71vc75eSOkyMsxFxbFsTNEMTLjVuKFxOelIgsiZJXKZNCX0FBmrfpCkKklCcjCBsgYGKgOHZwACMIGnMC8GByoDh2cBAgAMJDQ5YTk2YWNlLWUzOWEtNGZkMi1iZWMxLTEzMTY1YTk5NjIxYzAMBgcqA4dnAQIDAQH/MGYGByoDh2cBAgEEWzBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERSxyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJQnIwHwYFKgOGeAAwFjAUBgUqA4Z4AQwLcGFydGl0aW9uIDEwggaeMIIEejCCA0UwggNBMIICKaADAgECAhRZa7LL1EZqtYP6TqThmzBiZDtxDTANBgkqhkiG9w0BAQsFADAvMQ0wCwYDVQQKDARJRVRGMQ0wCwYDVQQLDARSQVRTMQ8wDQYDVQQDDAZBSyBSU0EwIBcNMjUwMTE3MTcxMzAzWhgPMjA1MjA2MDQxNzEzMDNaMC8xDTALBgNVBAoMBElFVEYxDTALBgNVBAsMBFJBVFMxDzANBgNVBAMMBkFLIFJTQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALD56BlDp66YkqreF8p8QPh0T+0vgUjmyOqie30AFUj7UZKrKLVsUGCxGMzRMeWUh0xsqYm1bCcpbwn7k6A03zLpfG/wmYz9jm9C3aWKzR+peYbxRPPRVNZ2UBdeaFSzqVIAO8Boh7hFWsKxn3svdlBOvJjslFVxsHiSFQ3canTKD7zTVJfOgVNNr5QYhEsTrqMfnVprlVe732Ge/U6Ify1CuN2LyYfq4b+Jyrhe4h41YwXfbAeog44+9BxZXczkPa/EkSPvTYq7qT05BeQCjXupFISidZbge0tu2ZLwd7Uk09z+fd1VSb58zo2gNc+gs/uPnkb3MrKoa0YBZcCPUxMCAwEAAaNTMFEwHQYDVR0OBBYEFIkZWV4O8Wn1y71H4TT84pjMaTCRMB8GA1UdIwQYMBaAFIkZWV4O8Wn1y71H4TT84pjMaTCRMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEBAGbNxMg9iFU20x2s5v1572pgAOVO5CXXLWZ2sM9wL7ObBm7Aosm7z2G/GYV0OtU1zpCw0qcfR9a0xnFTlRBOupbZZ/SMtjduN8mQKZNBqE4rxcPehCp9dUoJ74wYVRKHvUFRdzgUhDMwnqmEb7mqIKqwP0Ev+AVd/hqj4EjhJCFVaLoVH4k4EzF33UNgPJivo1910BvNpbuIOhURZHWm9ABlvJxZ+/Uohjqd7bJDR1J506ogT052OqLZCRbiQPupdEtgpww+p7VI9qjbGhLYrPxIh2gsicu7sJvdALuf+gRuIrgkhUPb2CIym50nyBsEsuPAOsKWzTID6eDyf/CSSLQwKwYJKoZIhvcNAQEKMB6gDTALBglghkgBZQMEAgGhDTALBgkqhkiG9w0BAQgEggEAm2rBky8c2FvvveBU4IRXfryRgbzwUXllinAOIlVvw/GTH1nclzTv4I3yBPz+VcZMapfo1SDljB9kCAtszhwI6I21EMBtaRSoGLcN+CMms3oqvlT6sFZ9dI4eguLelUysY8WrO8kv/5y4qmT7y4Pdi6y86WOS+R3UDuBQWK3OsR9c8MN5JB/UcJGKvO6nD9AcDLxk2WBn/lSexENzhlW8K89+W9VMFdXlrC9K0YDZc6fmAlEmzNK0XXjplEZiI3lZ73P0fprg+psMVRd7tvhnqQtB0O+3LBkvFaZlMdAwvIX+09E1rqQEXgJO8ugHUXUE0xPb6ksPcJ0FU7YHk7LcqjCCAhwwggG7MIIBtzCCAV2gAwIBAgIUB6npr/yEpH9d/wPt8w6Lo5AflbgwCgYIKoZIzj0EAwIwMDENMAsGA1UECgwESUVURjENMAsGA1UECwwEUkFUUzEQMA4GA1UEAwwHQUsgUDI1NjAgFw0yNTAxMTcxNzE0MjhaGA8yMDUyMDYwNDE3MTQyOFowMDENMAsGA1UECgwESUVURjENMAsGA1UECwwEUkFUUzEQMA4GA1UEAwwHQUsgUDI1NjBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABEIlSPiPt4L/teyjdERSxyoeVY+9b3O+XkjpMjLMRcWxbEzRDEy41bihcTnpSILImSVymTQl9BQZq36QpCpJQnKjUzBRMB0GA1UdDgQWBBRbcKeYF/ef9jfS9+PcRGwhCde71DAfBgNVHSMEGDAWgBRbcKeYF/ef9jfS9+PcRGwhCde71DAPBgNVHRMBAf8EBTADAQH/MAoGCCqGSM49BAMCA0gAMEUCIQCQfwSuP9Ms2gR8ki+iQQQNWaEfl/tRAd2usLJBYSEl6AIgJGzL/VWqOjeqD9aseiynBwHY9odjL4Wcfv2bOeo7uNUwEwYHKoZIzj0CAQYIKoZIzj0DAQcERjBEAiAedwP2O/+VGRdxTl+oE95SZfFRpoAhZe8L5fH+bJEiWwIgCtBrQaUGKwf/OtN8fREuGVdfDhSpdQ/pXmFVULiLX+0=
Appendix B. Acknowledgements
This specification is the work of a design team created by the chairs
of the RATS working group. This specification has been developed
based on discussions in that design team and also with great amounts
of input taken from discussions on the RATS mailing list.
Authors' Addresses
Mike Ounsworth
Entrust Limited
2500 Solandt Road - Suite 100
Ottawa, Ontario K2K 3G5
Canada
Email: mike.ounsworth@entrust.com
Jean-Pierre Fiset
Crypto4A Inc.
1550A Laperriere Ave
Ottawa, Ontario K1Z 7T2
Canada
Email: jp@crypto4a.com
Hannes Tschofenig
University of Applied Sciences Bonn-Rhein-Sieg
Germany
Email: Hannes.Tschofenig@gmx.net
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@ietf.contact
Ounsworth, et al. Expires 4 September 2025 [Page 38]
Internet-Draft PKIX Key Attestation March 2025
Monty Wiseman
Beyond Identity
United States of America
Email: monty.wiseman@beyondidentity.com
Ned Smith
Intel Corporation
United States of America
Email: ned.smith@intel.com
Ounsworth, et al. Expires 4 September 2025 [Page 39]