Credential Confirmation with DNS

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 11 December 2024.¶

Copyright Notice

Copyright (c) 2024 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

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).¶

2. 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.¶

3. 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:¶

{
  "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.¶

{
  /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.¶

4. 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:¶

{
  /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:¶

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

The following informative example of an answer is provided:¶

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

The JOSE credential 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:¶

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

The following informative example of an answer is provided:¶

;; ...
;; 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.¶

5. Usage

6. 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.¶

7. 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.¶

8. 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.¶

9. IANA Considerations

This document has no IANA actions.¶

10. 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".¶

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¶

Author's Address