High Assurance DIDs 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 23 January 2025.¶

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

Table of Contents

1. Introduction

In the ever-evolving digital world, the need for secure and verifiable identities is paramount. DIDs have emerged as a promising solution, providing a globally unique, persistent identifier that does not require a centralized registration authority. However, like any technology, DIDs face challenges in terms of authenticity, discoverability, and portability.¶

This is where the Domain Name System (DNS), a well-established and globally distributed internet directory service, comes into play. By leveraging the existing DNS infrastructure, we can enhance the verification process of DIDs. Specifically, we can use Transport Layer Security Authentication (TLSA) and Uniform Resource Identifier (URI) DNS records to add an additional layer of verification and authenticity to DIDs.¶

TLSA records in DNS allow us to associate a certificate or public key with the domain name where the record is found, thus providing a form of certificate pinning. URI records, on the other hand, provide a way to publish mappings from hostnames to URIs, such as DIDs.¶

By storing crucial information about a DID, such as the DID itself and its Public Key Infrastructure (PKI) in these DNS records, we can provide a verifier with a simple yet effective method to cross-validate and authenticate a DID. This not only ensures the authenticity of the DID document but also allows for interaction with material signed by the DID without access to the DID document itself.¶

In essence, the integration of DIDs with DNS, specifically through the use of TLSA and URI records, provides a robust solution to some of the challenges faced by DIDs, paving the way for a more secure and trustworthy digital identity landscape.¶

2. Conventions and Definitions

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. Securing a DID using the DNS

Much like presenting two pieces of ID to provide a higher level of assurance when proving your identity or age, replicating important information about a DID into a different domain (like the DNS) enables a similar form of cross validation. This enhances the initial trust establishment between the user and the DID document, as the key information can be compared and verified across two segregated sets of infrastructure. This also acts as a form of ownership verification in a similar way to 2FA, as the implementer must have control over both the DNS zone and the DID document to properly duplicate the relevant information.¶

+----------------+     +----------------+
|                |     |                |
|   DNS Server   |     |   Web Server   |
|                |     |                |
|   +-------+    |     |   +-------+    |
|   |  DID  |<---+-----+-->|  DID  |    |
|   +-------+    |     |   +-------+    |
|   +-------+    |     |   +-------+    |
|   |  PKI  |<---+-----+-->|  PKI  |    |
|   +-------+    |     |   +-------+    |
|                |     |                |
+----------------+     +----------------+

The diagram above illustrates how a web server storing the DID document, and the DNS server storing the URI and TLSA records shares and links the key information about the DID across two independent sets of infrastructure.¶

{"dnsValidationDomain": "example.ca"}

4. Role of DNSSEC for Assurance and Revocation

It is RECOMMENDED that all the participants in this digital identity ecosystem enable DNSSEC signing for the DNS instances they operate. See [RFC9364].¶

DNSSEC provides cryptographic assurance that the DNS records returned in response to a query are authentic and have not been tampered with. This assurance within the context of the _did URI and _did TLSA records greatly strengthens the mechanism to ensure the integrity of the DID and its public keys. DNSSEC vastly reduces the possible attack vectors in which the repudiated DID information in the DNS can be tampered with.¶

Within this use-case, DNSSEC also provides revocation checks for both DIDs and their public keys. In particular, a DNS query for a specific _did URI record or _did TLSA record can return an NXDOMAIN [RFC8020] response if the DID or public key has been revoked. This approach can simplify the process of verifying the current validity of DIDs and public keys by reducing the need for complex revocation mechanisms or implementation specific technologies.¶

5. Digital Signature and Proof Value of the DID Document

Digital signatures ensure the integrity of the DID Document, and by extent the public keys, authentication protocols, and service endpoints necessary for initiating trustworthy interactions with the identified entity. The use of digital signatures in this context provides a robust mechanism for verifying that the DID Document has not been tampered with and indeed originates from the correct entity.¶

In accordance with W3C specifications, we propose including a data integrity proof such as those outlined in [dataIntegrityProofECDSA] and [dataIntegrityProofEdDSA], with the mandatory inclusions of the "created" and "expires" fields. The inclusion of which acts as a lifespan for the document, similar to the TTL for a DNS record. Depending on the use case and security requirements, a longer or shorter expiry period would be used as necessary.¶

"proof": {
   "type": "DataIntegrityProof",
   "cryptosuite": "ecdsa-jfc-2019",
   "created": "2023-10-11T15:27:27Z",
   "expires": "2099-10-11T15:27:27Z",
   "proofPurpose": "assertionMethod",
   "verificationMethod": "did:web:trustregistry.ca#key-1",
}

The data integrity proof SHOULD be signed using a verificationMethod that has an associated TLSA record to allow for the verification of the data integrity proof using pki material contained outside of the DID document. This provides an added layer of authenticity, as the PKI information contained in the DID document would need to be repudiated across 2 different domains, the resource hosting the DID document and its associated DNS domain.¶

6. Verification Process

Using the new DNS records and proof object in the DID document, we enable a more secure and higher assurance verification process for the DID. It is important to note that while not strictly necessary, DNSSEC verification SHOULD be performed each time a DNS record is resolved to ensure their authenticity.¶

The process below outlines the general steps required to complete the higher assurance did verification process;¶

1. Verification of the DID: The user verifies the DID is represented as a URI record in the associated domain.¶

   1. In the case of did:web, the domain and record name to be queried is indicated by the last segment of the did. In example, did:web:example.ca would translate to a URI record with the name _did.example.ca.¶

   2. In the case of other did methods, the domain and record name to be queried is indicated by the "dnsValidationDomain" property. In example, {"dnsValidationDomain": "example.ca"} would translate to a URI record with the name _did.example.ca.¶

2. Verification of the PKI: The user verifies the verificationMethod/s in the DID document are represented as TLSA record/s in the associated domain.¶

   1. The domain and record name for the TLSA record to be queried is determined identically to steps 1.a or 1.b.¶

      1. Note: The matching of the TLSA record content and verificationMethod may require some conversion, as TLSA records store key material as hex encoded DER format, and this representation is not supported by [verificationMethod]. However, there are many well supported cryptography libraries in a variety of languages that facilitate the conversion process.¶

3. Verification of the DID document's integrity: The user verifies the "proof" object to ensure the integrity of the DID document.¶

   1. This can be accomplished by using either the [verificationMethod] directly from the DID document, or using the key material stored in the TLSA record. Using the TLSA record would provide a higher level of assurance as this confirms the key material is being accurately represented across 2 different domains, both at the DID document level and the DNS level.¶

      1. Note: Unlike with matching the verificationMethod and TLSA record in step 2, DER is a widely supported encoding format for key material enabling a verifier to directly use the TLSA record content to verify the signature without having to convert the key back to its representation in the verificationMethod.¶

Note: The order of the steps presented does not specify a required order for verification. As a general rule (and depending on the use case) the 3 verification steps outlined above may be performed in any order as best fits the verifier's needs. In example, a verifier may arrive at the DID document during a credential verification process, in which case it makes sense to peform step 3 before steps 1 and 2. Alternatively, a verifier may arrive at the DID document after exploring an organization's domain, in which case it may make more sense to perform steps 1 and 2 prior to step 3. So long as the 3 steps are performed together, the same level of assurance is achieved irrespective of their order.¶

7. Control Requirements

This section defines a simple framework to define a set of technical controls that can be implemented and mapped into levels of assurance for did:web identifiers. To assist in decision-making and implementation, The controls are ordered in increasing level of security assurance and are grouped into levels of assurance from LOW- to HIGH+ - Issuing Authority is the entity accountable for the did:web identifier. - Issuing Service is the entity responsible for operating the did:web identifier infrastructure. In many cases the Issuing Authority may delegate elements of providing a high assurance did:web identifier to an Issuing Service that may be a commercial provider. In the simplest case, the Issuing Authority can be regarded as the same as the Issuing Service. Note that Controls 9, 10, and 11 CANNOT BE DELEGATED to an Issuing Service¶

11 technical controls are defined. These controls would be implemented in order of precedence for an increasing level of security assurance. (e.g., Control No. N would need to be implemented before implementing Control No. N+1)¶

In addition to the technical controls specified in the table it is advisable to add in DANE (DNS-based Authentication of Named Entities) [RFC6698] to secure TLS communications. TLS uses certificates to bind keys to names, which are published by public "Certification Authorities" (CAs). It is important to realize that the public CA model is fundamentally vulnerable because it allows any CA to issue a certificate for any domain name. Thus, a compromised CA can issue a fake replacement certificate which could be used to subvert TLS-protected websites. DANE offers the option to use the DNSSEC infrastructure to store and sign keys and certificates that are used by a TLS-protected website. The keys are bound to names in the Domain Name System (DNS), instead of relying on arbitrary keys and names issued in a potentially compromised certificate.¶

8. Levels of Assurance

Many trust frameworks specify levels of assurance to assist in determining which controls must be implemented.¶

The following table is not a definitive mapping to trust framework levels of assurance. It is intended to assist in determining mappings by grouping the controls within a range from LOW- to HIGH+ relating to the appropriate risk level. Note that controls are additive in nature. (i.e.,, controls of the preceding level must be fulfilled).¶

9. Security Considerations

TODO Security¶

10. IANA Considerations

Per [RFC8552], IANA is requested to add the following entries to the "Underscored and Globally Scoped DNS Node Names" registry:¶

+---------+------------+-------------------------------------------+
| RR Type | _NODE NAME | Reference                                 |
+---------+------------+-------------------------------------------+
| TLSA    | _did       | [draft-ietf-high-assurance-dids-with-dns] |
| URI     | _did       | [draft-mayrhofer-did-dns-01]              |
+---------+------------+------------------------------------------+.

11. References

Appendix A. W3C Considerations

1. We propose the inclusion of an optional data integrity proof for the DID document, as outlined in [dataIntegrityProofECDSA] and [dataIntegrityProofEdDSA].¶

2. We propose the inclusion of the optional "dnsValidationDomain" property to the [didSpecRegistries] as outlined in section 3.2.¶

Acknowledgments

TODO acknowledge.¶

Authors' Addresses