Credential Confirmation with DNS
Internet-Draft draft-steele-spice-tlsa-cnf-00
Orie Steele
Transmute
orie@transmute.industries
09 June 2024
Security
Secure Patterns for Internet CrEdentials
Digital Credentials
TLS Authentication Record
Domain Binding
Confirmation Claim
Digital Crededentials on the Internet often JSON Web Token (JWT) and CBOR Web Token (CWT), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's digital credentials. This is accomplished by describing how to discover thumbprints for proof-of-possession keys, as described in RFC 7800 and RFC 8747, using TLSA Records as described in RFC 6698. This approach can be leveraged to develop revocation and assurance capabilities for digital credentials.
About This Document
The latest revision of this draft can be found at https://OR13.github.io/draft-steele-spice-tlsa-cnf/draft-steele-spice-tlsa-cnf.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-steele-spice-tlsa-cnf/.
Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (mailto:spice@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spice/. Subscribe at https://www.ietf.org/mailman/listinfo/spice/.
Source for this draft and an issue tracker can be found at https://github.com/OR13/draft-steele-spice-tlsa-cnf.
Introduction
JSON Web Token (JWT) and CBOR Web Token (CWT) based digital credential formats can express claims made by an Issuer (iss) and a Subject (sub). The confirmation claim (cnf) can be used to bind proof-of-possession keys to the Subject claim (sub), which can be a string or URI. In cases where the Subject is a URL, the JSON Web Key Thumbprint (jkt) or COSE Key Thumbprint (ckt) can be published to the Domain Name System (DNS). This document describes how digital credentials can leverage specifications developed to support Internet X.509 Public Key Infrastructure Certificate (PKIX), Transport Layer Security (TLS), DNS-Based Authentication of Named Entities (DANE), in order to enable conceptually similar functionality, based on JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE).
Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
JWT is described in [RFC7519], CWT is described in [RFC8392]. Confirmation claim cnf is described in [RFC7800] and [RFC8747]. JWT, CWT and CNF related claims such as iss, sub, and nonce are shared by both token formats. TLSA Resource Record and related terminology are described in [RFC6698].
This document does not introduce new terminology.
Confirmation Claim
This section provides a summary of the confirmation claim and its possible structures in JOSE and COSE, and does not alter or extend the definition of cnf in [RFC7800] or [RFC8747].
The confirmation claim is an object or map, supporting one or more confirmation methods.
The following informative example of a decoded JWT claimset is provided:
Confirmation claim in JOSE

{
  "iss": "https://iss.example",
  "sub": "https://vendor.example",
  "exp": 1361398824,
  "cnf": {
    "jwk":{
      "kty": "EC",
      "alg": "ES256",
      "crv": "P-256",
      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
    },
    // "jkt": "NzbLs...",
    // "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256:NzbLs..."
    // "x5t#S256": "bwcK0esc3ACC3DB2Y5_lESsXE8o..."
    // "jwe": "eyJhbGciOiJSU0EtT0FFUCIsImVuYyI6IkExMjhDQkMtSF..."
  },
  // ...
}

A similar example of a CWT claimset, is provided in Extended Diagnostic Notation (EDN), see [I-D.draft-ietf-cbor-edn-literals] for more details.
Confirmation claim in COSE

{
  /iss/ 1 : "coaps://iss.example",
  /sub/ 2 : "coaps://vendor.example",
  /exp/ 4 : 1361398824,
  /cnf/ 8 : {
    /COSE_Key/ 1 : h'deebd8afa...423da25ffff'
    /ckt .../
    /Encrypted_COSE_Key .../
  }
  ...
}

In order to be compatible with [RFC6698], the value of the confirmation claim must be reducible to a hash in a verifiable way.
For JWK and COSE_Key, the hash is produced according to [RFC9278] and [I-D.draft-ietf-cose-key-thumbprint] respectively. For JKT and CKT, the hash is already present, but must be converted to hexadecimal before use in TLSA Records. For JWE and Encrypted_COSE_Key, the key must be decrypted and then the process for JWK and COSE_Key is applied.
Key Binding
The confirmation claim can be used to establish key binding, as described in [I-D.draft-ietf-oauth-sd-jwt-vc], [I-D.draft-prorock-spice-cose-sd-cwt] and [I-D.draft-barnes-mls-userinfo-vc].
Publishing a confirmation key associated with a subject, and using globally unique identifiers to identify subjects has additional impact on privacy and traceability.
See this document's privacy considerations for additional details.
Confirmation Claim Record
This section describes the structure of the confirmation claim record.
As described in [RFC6698], there are several components of a TLSA record, including:
- TLSA Certificate Usages
- TLSA Selectors
- TLSA Matching Types
Until the associated IANA registries contain an entry specific to this draft, the value reserved for private use (255) MUST be used.
Similar to the process for deriving a prefxied DNS domain name as described in Section 3 of [RFC6698], the structure of the confirmation claim needs to be converted to a prefixed DNS domain name.
In JOSE, the string claim names are used, but in COSE the integer values are used.
For example:
The COSE credential claimset:
Example COSE Claimset

{
  /iss/ 1 : "coaps://iss.example",
  /sub/ 2 : "coaps://vendor.example",
  /cnf/ 8 : {
    /COSE_Key/ 1 : h'deebd8afa...423da25ffff'
  }
  ...
}

Produces the following prefixed DNS domain name:

_1_8.vendor.example

The following command can be run to retrieve the confirmation claim record:
Example cnf query

dig server.ns.vendor.example. _1_8.vendor.example. TLSA

The following informative example of an answer is provided:
Example cnf query answer

;; ...
;; ANSWER SECTION:
_1_8.vendor.example.    300  IN  TLSA  255 255 255 123533...66AAF8

The JOSE credential claimset:
Example JOSE Claimset

{
  "iss": "https://iss.example",
  "sub": "https://vendor.example",
  "exp": 1361398824,
  "cnf": {
    "jwk":{
      "kty": "EC",
      "alg": "ES256",
      "crv": "P-256",
      "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
      "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA"
    },
  },
}

Produces the following prefixed DNS domain name:

_jwk_cnf.vendor.example

The following command can be run to retrieve the confirmation claim record:
Example cnf query

dig server.ns.vendor.example. _jwk_cnf.vendor.example. TLSA

The following informative example of an answer is provided:
Example cnf query answer

;; ...
;; ANSWER SECTION:
_jwk_cnf.vendor.example.    300  IN  TLSA  255 255 255 12353...6AAF8

In both of the preceeding examples, the claimset contained a key, but the tlsa cnf record contained a thumbprint.
In order to match the claimset confirmation method to the hash retrieved from the cnf record, the process described in Section 1 MUST be followed.
Section 5 of [ADEM] describes a mechanism for embedding a key identifier in certificate logs which enables several useful properties for digital credentials. In particular, the organization identifiers associated with a digitial emblem can be discovered through distribution of certificate transparency logs. This approach could be extended to feeds of related credential information, by replacing the key identifier with a merkle root for another transparency system. Enabling the holder of a digital emblem to disclose several credentials, potentially with distinct trust chains, which can be useful in cross border scenarios. Future work from the IETF SCITT or KEY TRANS working groups could provide useful building blocks for extending Certificate Transparency based discoverability of digital credentials.
TODO: Consider merkle root instead of single key thumbprint, confirm multiple keys with a single record.
TODO: Consider relationship to Key Transparency, Metadata & Capability Discovery, Certificate Transparency.
TODO: Consider BBS / accumulator alternatives to set membership with merkle proofs.
Usage
Before Issuance
The issuer needs to first authenticate the subject, and establishing that they control a confirmation key.
There are several established mechanisms which might be relevant to this step, including [RFC9449] and [I-D.draft-ietf-oauth-attestation-based-client-auth].
At this stage the issuer SHOULD perform the following additional actions:
- Resolve the subject's confirmation claim record as described in Section 2
- Confirm the record contains a thumbprint which matches confirmation claim as described in Section 1
This step is not always required, because of the timing and availability issues associated with setting the confirmation claim record.
After Verification
After verifying the presentation of a digital credential which included a confirmation claim, the verifier has confirmed the issuer's signature matches their public key, and that the subject's confirmation key is in their possession.
Additional validation checks MUST be performed first, including reviewing the valid from and valid until related claims, and checking the
At this stage the verifier SHOULD perform the following additional actions:
- Convert the verified claim set to the confirmation claim record, and resolve it as described in Section 2.
- Verify that the confirmation claim record contains a hash that matches the confirmation claim in the credential as described in Section 1.
Revocation
This section builds on the After Verification process described above, and applies it to the concrete use case of Subject initiated credential revocation.
In the event that a device or service controlling the proof-of-possession key for a credential is stolen or compromised, the subject can revoke the confirmation claim the issuer commited to, by deleteing the associated confirmation record.
After deleting the record, the subject can contact the issuer and obtain a fresh credential with a new confirmation key, and add a new confirmation record to their domain name.
Due to the timeing and availability constraints of the DNS, verifiers can still be deceived by presentations of the stolen credential.
The utility of this subject directed revocation depends on the responsiveness and realtime revocation capabilities of the issuer.
For example, if an issuer could revoke the credential in 5 minutes, and the DNS takes 30 minutes to update, the issuer should be contacted to revoke the credential first.
However, if the issuer can only revoke credentials in a 24 hour window, and the DNS takes 30 minutes to propagate the subject's revocation of the credential, the subject should revoke the credential first, and then contact the issuer.
Assurance
This section builds on the Before Isssunace process described above, and applies it to the concrete use case of providing the issuer with increased assurance that a subject identified with a URL and presenting a given public key, controls the associated domain, and the associated private key.
In this case, the DNS enables the subject to publish and unpublish the thumbprint of the public key they wish to use for digital credentials on the associated domain.
This approach could be extended to other protocols, and is inspired by similar approaches to demonstrating control of resources or proving possession for example Automated Certificate Management Environment (acme) and DNS-Based Authentication of Named Entities (DANE).
Digital Emblems
One use case for confirming credentials via DNS is enabling digital emblems or badges. [I-D.draft-haberman-digital-emblem-ps] describes the challenge of recognizing if a person, organization, vehicle, or asset is recognized or protected under international laws. [ADEM] proposes a JSON Web Token based solution to this challenge similar to the approach described in this draft. Using confirmation methods with digital emblems can help protect them against forgery or theft, by requiring an attacker to gain control of both the digital infrastructure where the emblem is published and any cryptographic key material associated with the confirmation method for the credential. This specification currently extends the TLSA record for digital credential use cases, however it is possible that more fit for purpose DNS Resource Record (RR) types might be created to support digitial emblems in the future.
Privacy Considerations
As noted in Section 5 of [RFC7800], A proof-of-possession key can be used as a correlation handle if the same key is used with multiple parties. Thus, for privacy reasons, it is recommended that different proof-of-possession keys be used when interacting with different parties.
By publishing the confirmation key thumbprint, a domain operator is intentionaly enabling this type of correlation.
Resolving confirmation key thumbprints at the time of verification reveals timing information related to credential processing.
TODO: additional privacy considerations.
Security Considerations
The security considerations of [RFC7519], [RFC8392], [RFC7800], [RFC8747], and [RFC6698] apply.
After verification of a credential which includes a confirmation claim or a key binding token, it is essential that the verifier confirm the key is still published under the domain associated with the subject. Prior to the issuance or digital credentials it is essential that the issuer obtain proof that the subject of the credential controls the associated proof of possession key.
TODO: additional security considerations.
Internationalization Considerations
This specification is not limited to URLs that rely on HTTPS.
Considerations for international domain names in [UTS46] and [RFC5895] both apply.
For example: ☕.example becomes xn--53h.example when converting from a subject identifier to a TLSA record.
TODO: additional i18n considerations.
IANA Considerations
This document has no IANA actions.
Implementation Status
Note to RFC Editor: Please remove this section as well as references to [BCP205] before AUTH48.
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [BCP205]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to [BCP205], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".
Transmute Prototype
Organization: Transmute Industries Inc
Name: https://github.com/transmute-industries/jwt.vc
Description: An application demonstrating the concepts is available at https://jwt.vc
Maturity: Prototype
Coverage: The current version ('main') implements a post verification check similar to the one described in this document.
License: Apache-2.0
Implementation Experience: No interop testing has been done yet. The code works as proof of concept, but is not yet production ready.
Contact: Orie Steele (orie@transmute.industries)
Acknowledgments
TODO acknowledge.
Thanks to the authors of the following drafts:
- [I-D.draft-vesco-vcauthtls-01]
- [I-D.draft-carter-high-assurance-dids-with-dns]
- [I-D.draft-latour-dns-and-digital-trust]
- [I-D.draft-mayrhofer-did-dns]
- [I-D.draft-barnes-mls-userinfo-vc]
- [I-D.draft-ietf-oauth-sd-jwt-vc]
- [I-D.draft-prorock-spice-cose-sd-cwt]
--back
References
Normative References
[RFC7519]

JSON Web Token (JWT)
M. Jones
J. Bradley
N. Sakimura
May 2015
RFC 7519
DOI 10.17487/RFC7519
[RFC8392]

CBOR Web Token (CWT)
M. Jones
E. Wahlstroem
S. Erdtman
H. Tschofenig
May 2018
RFC 8392
DOI 10.17487/RFC8392
[RFC7800]

Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)
M. Jones
J. Bradley
H. Tschofenig
April 2016
RFC 7800
DOI 10.17487/RFC7800
[RFC8747]

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
M. Jones
L. Seitz
G. Selander
S. Erdtman
H. Tschofenig
March 2020
RFC 8747
DOI 10.17487/RFC8747
[RFC6698]

The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
P. Hoffman
J. Schlyter
August 2012
RFC 6698
DOI 10.17487/RFC6698
[RFC9278]

JWK Thumbprint URI
M. Jones
K. Yasuda
August 2022
RFC 9278
DOI 10.17487/RFC9278
[I-D.draft-ietf-cose-key-thumbprint]

CBOR Object Signing and Encryption (COSE) Key Thumbprint
Kohei Isobe
SECOM CO., LTD.
Hannes Tschofenig
Orie Steele
Transmute
23 October 2023
Internet-Draft draft-ietf-cose-key-thumbprint-04
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC7942]

Improving Awareness of Running Code: The Implementation Status Section
Y. Sheffer
A. Farrel
July 2016
BCP 205
RFC 7942
DOI 10.17487/RFC7942
[RFC5895]

Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008
P. Resnick
P. Hoffman
September 2010
RFC 5895
DOI 10.17487/RFC5895
[RFC9449]

OAuth 2.0 Demonstrating Proof of Possession (DPoP)
D. Fett
B. Campbell
J. Bradley
T. Lodderstedt
M. Jones
D. Waite
September 2023
RFC 9449
DOI 10.17487/RFC9449
[I-D.draft-ietf-oauth-attestation-based-client-auth]

OAuth 2.0 Attestation-Based Client Authentication
Tobias Looker
MATTR
Paul Bastian
31 May 2024
Internet-Draft draft-ietf-oauth-attestation-based-client-auth-03
[I-D.draft-ietf-cbor-edn-literals]

CBOR Extended Diagnostic Notation (EDN): Application-Oriented Literals, ABNF, and Media Type
Carsten Bormann
Universität Bremen TZI
18 May 2024
Internet-Draft draft-ietf-cbor-edn-literals-09
[I-D.draft-vesco-vcauthtls-01]

Transport Layer Security (TLS) Authentication with Verifiable Credential (VC)
Andrea Vesco
LINKS Foundation
Leonardo Perugini
LINKS Foundation
16 February 2024
Internet-Draft draft-vesco-vcauthtls-01
[I-D.draft-carter-high-assurance-dids-with-dns]

High Assurance DIDs with DNS
Jesse Carter
CIRA
Jacques Latour
CIRA
Mathieu Glaude
Northern Block
Tim Bouma
Digital Governance Council
23 May 2024
Internet-Draft draft-carter-high-assurance-dids-with-dns-04
[I-D.draft-latour-dns-and-digital-trust]

Leveraging DNS in Digital Trust: Credential Exchanges and Trust Registries
Jesse Carter
CIRA
Jacques Latour
CIRA
Mathieu Glaude
NorthernBlock
11 April 2024
Internet-Draft draft-latour-dns-and-digital-trust-02
[I-D.draft-mayrhofer-did-dns]

The Decentralized Identifier (DID) in the DNS
Alexander Mayrhofer
nic.at GmbH
Dimitrij Klesev
Markus Sabadello
Danube Tech GmbH
9 June 2021
Internet-Draft draft-mayrhofer-did-dns-05
[I-D.draft-barnes-mls-userinfo-vc]

UserInfo Verifiable Credentials as MLS Credentials
Richard Barnes
Cisco
Suhas Nandakumar
Cisco
13 March 2023
Internet-Draft draft-barnes-mls-userinfo-vc-00
[I-D.draft-ietf-oauth-sd-jwt-vc]

SD-JWT-based Verifiable Credentials (SD-JWT VC)
Oliver Terbu
MATTR
Daniel Fett
Authlete Inc.
Brian Campbell
Ping Identity
4 March 2024
Internet-Draft draft-ietf-oauth-sd-jwt-vc-03
[I-D.draft-prorock-spice-cose-sd-cwt]

Selective Disclosure CWTs (SD-CWT)
Michael Prorock
mesur.io
Orie Steele
Transmute
21 March 2024
Internet-Draft draft-prorock-spice-cose-sd-cwt-00
[UTS46]

UTS46
n.d.
[I-D.draft-haberman-digital-emblem-ps]

Problem Statement for Digitized Emblems
Brian Haberman
Johns Hopkins University Applied Physics Lab
Tommy Jensen
Microsoft
Bill Woodcock
PCH
21 May 2024
Internet-Draft draft-haberman-digital-emblem-ps-02
[ADEM]

An Authenticated Digital EMblem - Core Specification
n.d.