title: DER Web Token abbrev: DER Web Token (DWT) docname: draft-ounsworth-rats-dwt-latest category: std consensus: true submissiontype: IETF
ipr: trust200902 area: Security workgroup: RATS keyword: Internet-Draft
stand_alone: yes pi: rfcedstyle: yes toc: yes tocindent: yes sortrefs: yes symrefs: yes strict: yes comments: yes inline: yes text-list-symbols: o-*+ compact: yes subcompact: yes consensus: false
ins: M. Ounsworth
name: Mike Ounsworth
org: Entrust Limited
abbrev: Entrust
street: 2500 Solandt Road – Suite 100
city: Ottawa, Ontario
country: Canada
code: K2K 3G5
email: [email protected]
- ins: R. Kettlewell name: Richard Kettlewell org: Entrust Limited abbrev: Entrust country: United Kingdom email: [email protected]
- ins: J.P. Fiset name: Jean-Pierre Fiset organization: Crypto4A Technologies Inc. abbrev: Crypto4A street: 1550A Laperriere Ave city: Ottawa, Ontario country: Canada code: K1Z 7T2 email: [email protected]
- name: Hannes Tschofenig organization: University of Applied Sciences Bonn-Rhein-Siegx abbrev: H-BRS email: [email protected]
- fullname: Tirumaleswar Reddy organization: Nokia city: Bangalore region: Karnataka country: India email: "[email protected]"
- ins: M. Wiseman name: Monty Wiseman org: Beyond Identity country: USA email: [email protected]
normative: RFC2119: RFC9334: I-D.ietf-rats-eat: X.680: title: "Information technology -- Abstract Syntax Notation One (ASN.1): Specification of basic notation" author: org: ITU-T date: false target: https://www.itu.int/rec/T-REC-X.680
informative: RFC5912: RFC9344:
--- abstract
An Attestation Token provides a set of claims that describe the state and characteristics of an entity, such as a hardware security module, smartphone, IoT device, or network equipment. This claims set allows a relying party to assess the type and degree of trust it can place in the entity.
This document utilizes the claims defined for the Entity Attestation Token (EAT) and defines them in ASN.1 format and supports their encoding using Distinguished Encoding Rules (DER). EAT specified claims for use with both the CBOR Web Token (CWT) and the JSON Web Token (JWT). This new structure, referred to as the DER Web Token (DWT), is generated by an Attester as part of remote attestation procedures and serves as Evidence.
The document adheres to the Remote ATtestation procedureS (RATS) architecture, where Evidence is transmitted by an Attester and subsequently processed by a Verifier.
--- middle
Trusted execution environments, such as secure elements and hardware security modules (HSMs), have become widely used for providing a secure environment to house cryptographic key material and security-sensitive code. These environments support functions like signing and decryption services, secure boot, secure storage, and other critical security operations. Typically, these security functions are accessed through a narrow and well-defined interface and are used by operating system libraries and applications.
Increasingly, entities relying on these secure elements seek evidence that security-sensitive operations are truly being executed within a secure environment. This evidence may pertain to the secure element platform itself or to the storage and protection of cryptographic keys, or both. Such evidence is commonly referred to as remote attestation and is covered by the Remote ATtestation procedureS (RATS) architecture {{RFC9344}}. This document specifies an evidence data format defined in ASN.1 {{X.680}}, leveraging many data structures from the PKIX ASN.1 modules {{RFC5912}}. This approach offers a convenient format for secure elements and verifiers, particularly those designed for use within X.509 Public Key Infrastructures.
This specification re-uses the claims defined in {{I-D.ietf-rats-eat}}, describes them in ASN.1, and serializes them in DER format. While the encoding of these claims differs from what is defined in {{I-D.ietf-rats-eat}}, their semantics remain unchanged. This specification does not constitute an EAP profile, as described in Section 6 of {{I-D.ietf-rats-eat}}.
{::boilerplate bcp14-tagged}
This document re-uses the terms defined in {{RFC9334}} related to remote attestation. Readers of this document are assumed to be familiar with the following terms: Evidence, Claim, Attestation Result, Attester, Verifier, and Relying Party.
This specification was designed to meet the requirements published by the CA Browser Forum to convey properties about hardware security models, such as non-exportability, which must be enabled for storing publicly-trusted code-signing keys. There are, however, other use cases where remote attestation may also be used, such as
-
A Certification Authority receives a certificate signing request and wishes to verify that the subject public key was generated in an HSM (for example to satisfy CA/B Forum subscriber private key verification requirement). They may also wish to verify that the operations the HSM will allow for the corresponding private key are consistent with the purpose of the requested certificate.
-
A user of a Cloud Service Provider's 'Bring Your Own Key' service wishes to transfer their locally-generated key securely to the CSP's service by encrypting it under the CSP's public key. As part of their due diligence on the CSP's key they wish to verify (1) that it was generated by an HSM and (2) may only be used to unwrap the key into an HSM (i.e. unwrap permission but not decrypt permission).
-
An auditor of an identity provision service (or a competent end user) may wish to verify that keys representing end-user identities are held in an HSM and have permissions that are in line with the applicable regulations. For example, they may wish verify that the protection arrangements for assigned keys cannot be changed.
-
A manufacturer needs to provision configuration info, software, and credentials to a device from remote. With the help of remote attestation the manufacturer is provided enough information to verify that information is only sent to devices it has built.
-
Two HSM devices are establishing keys to perform secure exchange of information to establish a high availability cluster. As part of the establishment, an attestation message is sent between the devices to report on keys and policies. This allows the devices to confirm the origin of the keys and verify that policies are respected such a FIPS mode and other similar details.
This specification defines the following Evidence format, which contains a set of claims. To protect Evidence against modification, it is protected with a digital signature.
PkixEvidenceStatement ::= SEQUENCE {
tbsEvidence TBSEvidenceStatement
signatureValues SEQUENCE SIZE (1..MAX) OF BIT STRING,
relatedCertificates [0] IMPLICIT SEQUENCE of Certificate OPTIONAL
-- As defined in RFC 5280
}
TBSEvidenceStatement ::= SEQUENCE {
version INTEGER,
claims SEQUENCE SIZE (1..MAX) OF EVIDENCE-CLAIM,
signatureInfos SEQUENCE SIZE (1..MAX) OF SignatureInfo
}
EVIDENCE-CLAIM ::= TYPE-IDENTIFIER
-- TYPE-IDENTIFIER definition from X.681
TYPE-IDENTIFIER ::= CLASS
{
&id OBJECT IDENTIFIER UNIQUE,
&Type
}
WITH SYNTAX {&Type IDENTIFIED BY &id}
SignatureInfo ::= SEQUENCE {
signatureAlgorithm AlgorithmIdentifier,
sid [0] SignerIdentifier OPTIONAL
}
SignerIdentifier ::= SEQUENCE {
keyId [0] EXPLICIT OCTET STRING OPTIONAL,
subjectKeyIdentifier [1] EXPLICIT SubjectPublicKeyInfo OPTIONAL,
-- As defined in RFC 5280
certificate [2] EXPLICIT Certificate OPTIONAL,
-- As defined in RFC 5280
certHash [3] EXPLICIT CertHash OPTIONAL
}
CertHash ::= SEQUENCE {
hash AlgorithmIdentifier,
value OCTET STRING
}
-- There is bound to already exist an ASN.1 structure
-- for this somewhere.
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}version MUST be set to 1.
EDNOTE: Can we start our versions at some number to avoid versions that Crypto4A has already used?
-
The message to be signed is the
TBSEvidenceStatement, including theSignatureInfofor each of the signatures to be performed. -
Each signature is computed in parallel and placed into index of the
signatureValuesSEQUENCE that matches the position of the correspondingSignatureInfoin thesignatureInfossequence.
The signer MUST produce one signature per signatureInfo, it MUST NOT
omit signatures and MUST NOT produce a subset of the signatures listed in signatureInfos.
-
The message to be verified is the
TBSEvidenceStatement. -
For each
signatureInfo, the corresponding verification public key and signature algorithm is found according to the information contained in theSignatureInfofor that signature and any accompanying certificates or key material. -
For each signature, the message is verified using the value from the corresponding element of the
signatureValuesequence. -
The
PkixEvidenceStatementSHOULD be considered valid if and only if all signatures are valid; i.e. multiple signatures are to be treated as an AND mode. This item is a recommendation and not a hard requirement since verification policy is of course at the discretion of the Verifier.
EDNOTE: the major change here from the original Crypto4A QASM Attestation is that the original only includes the claims in the signature, whereas this includes everything, including the version, list of signature algorithms. This prevents possible attacks where those values are manipulated by attackers. We should debate whether the certificates should be protected by the signature. Pro: generally better for security to sign everything. Con: in some contexts, it may be difficult to have the certificates prior to signing, but that's ok because most evidence carrier formats also allow you to attach the signatures externally.
Since no claims are marked as MANDATORY, the sequence 'claims' may be constituted of differing claims from one instance to the next. This is expected as each evidence statement may be providing information to support different use cases.
Once an evidence statement is signed, the Attester is guaranteeing that all of the claims carried by the evidence statement are true.
It is important to note that multiple claims in the sequence may have the same 'id'. Implementers should ensure that this case is handled by verifying logic.
| Claim | Value | Section |
|---|---|---|
| Oemid | UTF8String | {{sect-deviceID}} |
| Hwmodel | UTF8String | {{sect-deviceID}} |
| Hwversion | UTF8String | {{sect-deviceID}} |
| Hwserial | UTF8String | {{sect-deviceID}} |
| Ueid | UTF8String | {{sect-ueid}} |
| Sueid | UTF8String | {{sect-sueid}} |
| EnvID | UTF8String | {{sect-envID}} |
| Swname | UTF8String | {{sect-swID}} |
| Swversion | UTF8String | {{sect-swID}} |
| Oemboot | BOOLEAN | {{sect-oemboot}} |
| Location | ??? | {{sect-location}} |
| Dbgstat | CHOICE | {{sect-dbgstat}} |
| Uptime | INTEGER | {{sect-uptime}} |
| Bootcount | INTEGER | {{sect-bootcount}} |
| Bootseed | BIT STRING | {{sect-bootseed}} |
| Dloas | SEQUENCE OF Dloa | {{sect-dloas}} |
| Endorsements | SEQUENCE of Endorsement | {{sect-endorsements}} |
| Manifests | ?? | {{sect-manifests}} |
| Measurements | ?? | {{sect-measurements}} |
| Measres | ?? | {{sect-measres}} |
| Submods | ?? | {{sect-submods}} |
| Iat | Time | {{sect-iat}} |
| Nonce | OCTET STRING | {{sect-nonce}} |
| Claim | OID | Status |
|---|---|---|
| Oemid | TBD | RECOMMENDED |
| Hwmodel | TBD | RECOMMENDED |
| Hwversion | TBD | RECOMMENDED |
| Hwserial | TBD | RECOMMENDED |
| Ueid | TBD | OPTIONAL |
| Sueid | TBD | OPTIONAL |
| EnvID | TBD | OPTIONAL |
| Swname | TBD | RECOMMENDED |
| Swversion | TBD | RECOMMENDED |
| Oemboot | TBD | RECOMMENDED |
| Location | TBD | OPTIONAL |
| Dbgstat | TBD | RECOMMENDED |
| Uptime | TBD | OPTIONAL |
| Bootcount | TBD | OPTIONAL |
| Bootseed | TBD | OPTIONAL |
| Dloas | TBD | OPTIONAL |
| Endorsements | TBD | OPTIONAL |
| Manifests | TBD | OPTIONAL |
| Measurements | TBD | OPTIONAL |
| Measres | TBD | OPTIONAL |
| Submods | TBD | OPTIONAL |
| Iat | TBD | RECOMMENDED |
| Nonce | TBD | OPTIONAL |
Devices assigned a Universal Entity ID compliant with RATS EAT SHOULD
provide this in the Ueid or Sueid claim. Devices with a traditional
human-readable serial number SHOULD provide this in the Hwserial claim.
Both MAY be provided.
The set {OemID, Hwmodel, Hwversion, Hwserial}, when provided, SHOULD
represent a universally unique identification of the device. Where
applicable, {OemID, Hwmodel, Hwversion} SHOULD match the way the
device is identified in relevant endorsements, such as published FIPS
or Common Criteria certificates.
The "ueid" claim conveys a UEID, which identifies an individual manufactured entity. This identifier is a globally unique and permanent identifier. See Section 4.2.1 of {{I-D.ietf-rats-eat}} for a description of this claim. Three types of UEIDs are defined, which are distinguished via a type field.
The ueid claim is defined as follows:
id-ce-evidence-ueid OBJECT IDENTIFIER ::=
{ id-ce TBD_evidence TBD_ueid }
claim_ueid ::= SEQUENCE {
type INTEGER ( RAND(1), EUI(2), IMEI(3),...),
value OCTET STRING
}
The "sueids" claim conveys one or more semi-permanent UEIDs (SUEIDs). An SUEID has the same format, characteristics and requirements as a UEID, but MAY change to a different value on entity life-cycle events while the ueid claim is permanent. An entity MAY have both a UEID and SUEIDs, neither, one or the other.
There MAY be multiple SUEIDs and each has a text string label the purpose of which is to distinguish it from others.
See Section 4.2.2 of {{I-D.ietf-rats-eat}} for a description of this claim.
The sueids claim is defined as follows:
id-ce-evidence-sueids OBJECT IDENTIFIER ::=
{ id-ce TBD_evidence TBD_sueids }
claim_sueids ::= SEQUENCE {
label OCTET STRING,
type INTEGER ( RAND(1), EUI(2), IMEI(3),...),
value OCTET STRING
}
The "oemid" claim identifies the Original Equipment Manufacturer (OEM) of the hardware.
See Section 4.2.3 of {{I-D.ietf-rats-eat}} for a description of this claim.
The value of this claim depends on the type of OEMID and three types of IDs are defined:
-
OEMIDs using a 128-bit random number. Section 4.2.3.1 of {{I-D.ietf-rats-eat}} defines this type.
-
an IEEE based OEMID using a global registry for MAC addresses and company IDs. Section 4.2.3.1 of {{I-D.ietf-rats-eat}} defines this type.
-
OEMIDs using Private Enterprise Numbers maintained by IANA. Section 4.2.3.3 of {{I-D.ietf-rats-eat}} defines this type.
The oemid claim is defined as follows:
id-ce-evidence-oemid OBJECT IDENTIFIER ::=
{ id-ce TBD_evidence TBD_oemid }
claim_oemid ::= SEQUENCE {
type INTEGER ( PEN(1), IEEE(2), RANDOM(3),...),
value OCTET STRING
}
Editor's Note: The value for the PEN is numeric. For the other two types it is a binary string.
The "hwmodel" claim differentiates hardware models, products and variants manufactured by a particular OEM, the one identified by OEM ID. It MUST be unique within a given OEM ID. The concatenation of the OEM ID and "hwmodel" give a global identifier of a particular product. The "hwmodel" claim MUST only be present if an "oemid" claim is present.
See Section 4.2.4 of {{I-D.ietf-rats-eat}} for a description of this claim.
The hwmodel claim is defined as follows:
id-ce-evidence-hwmodel OBJECT IDENTIFIER ::=
{ id-ce TBD_evidence TBD_hwmodel }
claim_hwmodel ::= OCTET STRING
The "hwversion" claim is a text string the format of which is set by each manufacturer. A "hwversion" claim MUST only be present if a "hwmodel" claim is present.
See Section 4.2.5 of {{I-D.ietf-rats-eat}} for a description of this claim.
The hwversion claim is defined as follows:
id-ce-evidence-hwversion OBJECT IDENTIFIER ::=
{ id-ce TBD_evidence TBD_hwwversion }
hwversion ::= OCTET STRING
EnvID EVIDENCE-CLAIM ::= UTF8String IDENTIFIED BY TBDThis claim MAY be used to identify a partition within a cryptographic device, or a logical environment that spans multiple cryptographic devices such as a Security World or a cloud tenant. The format of these identifiers will be vendor or environment specific.
Swname EVIDENCE-CLAIM ::= UTF8String IDENTIFIED BY TBD
-- semantics defined in rats-eat-4.2.6
Swversion EVIDENCE-CLAIM ::= UTF8String IDENTIFIED BY TBD
-- semantics defined in rats-eat-4.2.7SwName and Swversion together identify the device firmware and
SHOULD match the way the firmware is identified in relevant
endorsements, such as published FIPS or Common Criteria certificates.
Oemboot EVIDENCE-CLAIM ::= BOOLEAN IDENTIFIED BY TBD
-- semantics defined in rats-eat-4.2.8The "dbgstat" claim applies to entity-wide or submodule-wide debug facilities and diagnostic hardware built into chips. It applies to any software debug facilities related to privileged software that allows system-wide memory inspection, tracing or modification of non-system software like user mode applications.
See Section 4.2.9 of {{I-D.ietf-rats-eat}} for a description of this claim and the semantic of the values in the enumerated list.
The dbgstat claim is defined as follows:
Dbgstat EVIDENCE-CLAIM ::= CHOICE {
enabled [0] IMPLICIT NULL,
disabled [1] IMPLICIT NULL,
disabled-Since-Boot [2] IMPLICIT NULL,
disabled-Permanently [3] IMPLICIT NULL,
disabled-Fully-and-Permanently [4] IMPLICIT NULL
}
-- semantics defined in rats-eat-4.2.9Location EVIDENCE-CLAIM ::= ???? IDENTIFIED BY TBD
-- semantics defined in rats-eat-4.2.10Most HSMs will likely not know their own physical location, but cryptographic modules on mobile devices may.
The "uptime" claim contains the number of seconds that have elapsed since the entity or submodule was last booted.
Uptime EVIDENCE-CLAIM ::= INTEGER IDENTIFIED BY TBD
-- semantics defined in rats-eat-4.2.11The "bootcount" claim contains a count of the number times the entity or submodule has been booted. Support for this claim requires a persistent storage on the device.
Bootcount EVIDENCE-CLAIM ::= INTEGER IDENTIFIER BY TBD
-- semantics defined in rats-eat-4.2.12The "bootseed" claim contains a value created at system boot time that allows differentiation of attestation reports from different boot sessions of a particular entity (e.g., a certain UEID).
This value is usually public. It is not a secret and MUST NOT be used for any purpose that a secret seed is needed, such as seeding a random number generator.
Bootseed EVIDENCE-CLAIM ::= BIT STRING IDENTIFIED BY TBD
-- semantics defined in rats-eat-4.2.13The "dloas" claim conveys one or more Digital Letters of Approval (DLOAs). A DLOA is a document that describes a certification that an entity has received. Examples of certifications represented by a DLOA include those issued by Global Platform and those based on Common Criteria. The DLOA is unspecific to any particular certification type or those issued by any particular organization.
Dloas EVIDENCE-CLAIM ::= SEQUENCE SIZE (1..MAX) OF Dloa
Dloa ::= SEQUENCE IDENTIFIED BY TBD {
dloaRegistrar IA5STRING,
dloaPlatformLabel UTF8STRING,
dloaApplicationLabal [0] IMPLICIT UTF8String OPTIONAL
}
-- semantics defined in rats-eat-4.2.14This claim allows referencing third party endorsements; for example from the device vendor or a certification such as FIPS or Common Criteria. The content MAY be referenced by URI, or placed directly inline, but either way, the endorsement content or its URI MUST be known by the attester at the time that the evidence is generated.
Endorsements EVIDENCE-CLAIM ::= SEQUENCE SIZE (1..MAX) OF Endorsement
Endorsement ::= CHOICE IDENTIFIED BY TBD {
uri [0] IMPLICIT IA5String,
content [1] IMPLICIT OCTET STRING
}EDNOTE: this needs a bit of thought about what types of endorsements we will likely see, and whether OCTET STRING is the right format.
TODO -- rats-eat-4.2.15
TODO -- rats-eat-4.2.16
TODO -- rats-eat-4.2.17
TODO -- rats-eat-4.2.18
The time at which the evidence was created. Here we differ from
the iat claim in rats-eat-4.3.1 in that we use the PKIX time
format Time instead of the 64-bit CBOR time structure.
Iat EVIDENCE-CLAIM ::= TimeIt is recognized that many HSMs, especially if air-gapped, will
not have an accurate system clock. If the system is not anticipated
to have a reliable clock, then this claim SHOULD be omitted and
the Nonce claim used instead.
Intuse EVIDENCE-CLAIM ::= CHOICE IDENTIFIED BY TBD {
generic [1] IMPLICIT NULL,
registration [2] IMPLICIT NULL,
provisioning [3] IMPLICIT NULL,
certificateIssuance [4] IMPLICIT NULL,
proofOfPossession [5] IMPLICIT NULL
}
-- semantics defined in rats-eat-4.3.3Note: tags intentionally started at 1 to align with EAT. If the IANA registry of intended use claims is extended, then the this CHOICE MAY be extended using the same tag values as indicated in the EAT registry.
The "nonce" claim is used to provide freshness.
The Nonce claim is used to carry the challenge provided by the caller to demonstrate freshness of the generated token. The following constraints apply to the nonce-type:
- The length must be reasonable as it may be processed by end entities with limited resources. Therefore, it is RECOMMENDED that the length does not exceed 64 bytes.
- Only a single nonce value is conveyed.
The nonce claim is defined as follows:
Nonce EVIDENCE-CLAIM ::= OCTET STRING IDENTIFIED BY TBDSee Section 4.1 of {{I-D.ietf-rats-eat}} for a description of this claim.
This document does not provide a comprehensive list of claims. New claims, including proprietary ones, may be introduced in the future. Therefore, parsers MUST be prepared to encounter and handle unrecognized claims gracefully.
Generally, a verifier should begin with an appraisal policy outlining the specific claims to be evaluated, including any expected values. Any additional claims present in the evidence SHOULD be disregarded unless otherwise specified.
This specification re-uses the claims from the EAT specification and relies on the security protection offered by digital signatures. This digital signature is computed with the Attestation Key available on the device, see Section 12.1 of {{RFC9334}} for considerations regarding the generation, the use and the protection of these Attestation Keys. Since the Attester located at the end entity creates the Evidence with claims defined in this document. This document inherits the remote attestation architecture described in {{RFC9334}}. With the re-use of the claims from {{I-D.ietf-rats-eat}} the security and privacy considerations apply also to this document even though the encoding in this specification is different from the encoding of claims discussed by {{I-D.ietf-rats-eat}}.
Evidence contains information that may be unique to a device and may therefore allow to single out an individual device for tracking purposes. Deployments that have privacy requirements must take appropriate measures to ensure that claim values can only identify a group of devices and that the Attestation Keys are used across a number of devices as well.
To verify the Evidence, the primary need is to check the signature and the correct encoding of the claims. To produce the Attestation Result, the Verifier will use Endorsements, Reference Values, and Appraisal Policies. The policies may require that certain claims must be present and that their values match registered reference values. All claims may be worthy of additional appraisal.
TBD: OIDs for all the claims listed in this document.
--- back
This specification is the work of a design team created by the chairs of the LAMPS working group. This specification has been developed based on discussions in that design team.
The following persons, in no specific order, contributed to the work: Richard Kettlewell, Chris Trufan, Bruno Couillard, Jean-Pierre Fiset, Sander Temme, Jethro Beekman, Zsolt Rózsahegyi, Ferenc Pető, Mike Agrenius Kushner, Tomas Gustavsson, Dieter Bong, Christopher Meyer, Michael StJohns, Carl Wallace, Michael Ricardson, Tomofumi Okubo, Olivier Couillard, John Gray, Eric Amador, Johnson Darren, Herman Slatman, Tiru Reddy, Thomas Fossati, Corey Bonnell, Argenius Kushner, James Hagborg.
TBD: Full ASN.1 goes in here.