idnits 2.17.1 draft-mayrhofer-did-dns-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2020) is 1318 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC6116' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC6117' is defined on line 314, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 319, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7553 -- Possible downref: Non-RFC (?) normative reference: ref. 'W3C-DID' Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Mayrhofer 3 Internet-Draft nic.at GmbH 4 Intended status: Standards Track D. Klesev 5 Expires: March 13, 2021 6 M. Sabadello 7 Danube Tech GmbH 8 September 9, 2020 10 The Decentralized Identifier (DID) in the DNS 11 draft-mayrhofer-did-dns-04 13 Abstract 15 This document specifies the use of the URI Resource Record Type to 16 publish Decentralized Identifiers (DIDs) in the DNS. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 13, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Use of the 'URI' RRType . . . . . . . . . . . . . . . . . . . 3 55 3.1. Owner Name Scoping, Target . . . . . . . . . . . . . . . 3 56 3.2. Weight, Priority . . . . . . . . . . . . . . . . . . . . 3 57 4. Location of the Records . . . . . . . . . . . . . . . . . . . 4 58 4.1. Host Names . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Email Addresses (Experimental) . . . . . . . . . . . . . 4 60 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 6. Considered Alternatives . . . . . . . . . . . . . . . . . . . 4 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 10.1. draft-mayrhofer-did-dns-04 . . . . . . . . . . . . . . . 6 67 10.2. draft-mayrhofer-did-dns-03 . . . . . . . . . . . . . . . 6 68 10.3. draft-mayrhofer-did-dns-02 . . . . . . . . . . . . . . . 6 69 10.4. draft-mayrhofer-did-dns-01 . . . . . . . . . . . . . . . 6 70 10.5. draft-mayrhofer-did-dns-00 . . . . . . . . . . . . . . . 6 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 11.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Decentralized Identifiers (DIDs) [W3C-DID] use a Uniform Resource 79 Identifier (URI) scheme [RFC3986] to identify persons, organizations, 80 or things in decentralized infrastructure, such as blockchains and 81 distributed ledgers. 83 DIDs are structured around "methods", each method defining the syntax 84 of the "method specific identifier" and the operations on the 85 respective DIDs (See Section 3.2 of [W3C-DID] and [DID-METHODS]). 86 For many methods, the method specific identifier is not human- 87 friendly (such as hash values, referring to transactions on a 88 blockchain). Most DIDs are therefore inherently hard to memorize for 89 humans. 91 By referring to DIDs from the Domain Name System (DNS), those hard to 92 memorize identifiers can be discovered via well known, human friendly 93 and widely established names. This document specifies how DIDs can 94 be published in the DNS for discovery on the base of host names and 95 email addresses. 97 Since DIDs use a URI scheme ('did'), this specification leverages the 98 existing URI DNS Resource Record Type (RRType) [RFC7553]. Records 99 are scoped using the '_did' global underscore node name, as described 100 in Section 3.1. 102 2. Terminology 104 "Owner name", "Priority", "Weight" and "Target" refer to the 105 respective fields of the URI RRType, as specified in Section 4 of RFC 106 7553. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Use of the 'URI' RRType 116 DIDs use an URI scheme ('did:'), so the most suitable option to 117 publish DIDs in the DNS is the use of the 'URI' RRType. During the 118 development of this document, various alternatives were considered, 119 see Section 6 for a list. 121 o When Decentralized Identifiers (DIDs) are published in the DNS, 122 the 'URI' RRType MUST be used. 124 3.1. Owner Name Scoping, Target 126 [RFC8552] describes the advantages of scoping an existing RRType over 127 the definition (and complex deployment) of a new RRType. The "URI" 128 RRType is specifically mentioned as one example where scoping is 129 particularly useful (and part of the design). 131 When DIDs are published in the DNS 133 o the records MUST be scoped by setting the global (highest-level) 134 underscore name of the URI RRset to '_did' (0x5F 0x64 0x69 0x64), 136 o and the Target field of all records in the RRset MUST contain a 137 URI of the 'did:' URI scheme. 139 3.2. Weight, Priority 141 The semantics of the Weight and Priority fields remain. When a 142 client encounters a DID method it does not support, it SHOULD 143 consider the respective URI "unreachable" for the purpose of record 144 selection, and proceed to the record with the next-lowest-numbered 145 Priority, in accordance with Section 4.2 of RFC 7553. 147 4. Location of the Records 149 4.1. Host Names 151 In order to discover the set of DIDs associated with a Host Name, a 152 client prepends the given Host Name with the '_did' global underscore 153 name to create the Owner name, and then queries the resulting Query 154 Name for the URI RRType set. 156 4.2. Email Addresses (Experimental) 158 To discover DIDs associated with email addresses, the (experimental) 159 model from DNS-Based Authentication of Named Entities (DANE) Bindings 160 for OpenPGP [RFC7929] is used. A client prepares the email address 161 following the procedure outlined in Section 5 in RFC7929 the form the 162 Query Name, but in step 5 MUST use the string '_mailto._did' instead 163 of '_openpgpkey' as the second left-most label. Subsequently, the 164 client performs a DNS query, but MUST use the URI RRType as Query 165 Type (rather than the OPENPGPKEY RRType described in said section). 167 5. Example 169 The following example is a URI Resource Record which refers from the 170 host name "example.net" to a Decentralized Identifier using the 'sov' 171 method: 173 _did.example.net. IN URI 100 10 "did:sov:1234abcd" 175 6. Considered Alternatives 177 During the development of this document, the following alternatives 178 were considered: A dedicated RRType, TXT records, an Enumservice, 179 Well-Known URIs, direct registration in the Service Name Registry. 180 Using the URI RRType was found to be the option with the least impact 181 on existing specifications and highest interoperability potential. 182 Support for URI RRTypes is widespread in DNS software, which means 183 that implementation and deployment of the proposed protocol should be 184 possible without any changes to underlying infrastructure. 186 Furthermore, the Identifiers and Discovery Working Group of the 187 Decentralized Identity Foundation (DIF) is considering a .well-known 188 URL based approach to discovering DIDs from web sites. 190 7. Acknowledgements 192 Acknowledgements will be added here. 194 8. IANA Considerations 196 Per [RFC8552] IANA is requested to add the following entry to the 197 DNS Underscore Global Scoped Entry Registry: 199 +---------+-------------+-----------+ 200 | RR Type | _NODE NAME | REFERENCE | 201 +---------+-------------+-----------+ 202 | URI | _did | {THISRFC} | 203 +---------+-------------+-----------+ 205 Table 1: Underscore Global Registry Entry Registration for '_did' 207 Note to RFC Editor: Please replace the above "{THISRFC}" text with 208 a reference to this document's RFC number. 210 Note that IANA has already created a provisional URI scheme 211 registration for the 'did:' scheme itself. 213 9. Security Considerations 215 Most of the considerations outlined in the base specification of the 216 URI RRType (RFC7553) also apply to the DID use case - particularly 217 the concerns around downgrade attacks when the record is not signed 218 with the help of DNSSEC. Note that the DID resolving process itself 219 (out of scope of this document) can provide additional security 220 information. The "Linked Domain Service Endpoint" of a DID document 221 can be used to back-reference to the Domain which was originally used 222 to discover that DID. Such a "closed loop" (similar to verifying DNS 223 reverse lookups against their corresponding forward lookups) would 224 increase the confidence in non-DNSSEC scenarios. 226 Including a DID in the DNS allows for correlation of that DID with 227 DNS information (and potentially registration information of that DNS 228 name). Therefore DIDs which are supposed to be private SHOULD NOT be 229 added to the DNS. 231 10. Changes 233 [Note to RFC Editors: This whole section is to be removed before 234 publication] 236 10.1. draft-mayrhofer-did-dns-04 238 o Reworded "Alternatives" 240 o Added text about backreference using DID's Linked Domain Service 241 Endpoint. 243 10.2. draft-mayrhofer-did-dns-03 245 o Updated DID spec to v1.0 document 247 o Minor editorial changes to make text more clear. 249 10.3. draft-mayrhofer-did-dns-02 251 o Updated attrleaf reference to RFC8552 253 o Changed author information for D. Klesev 255 o Added sentence on .well-known discovery scheme 257 10.4. draft-mayrhofer-did-dns-01 259 o email addresses further scoped with '_mailto._did' 261 o Changed protocol registration to attrleaf drafts 263 o Made clear requirements regarding use of the URI scheme 265 o Added privacy aspect to security considerations 267 10.5. draft-mayrhofer-did-dns-00 269 o Initial version 271 11. References 273 11.1. Normative References 275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 276 Requirement Levels", BCP 14, RFC 2119, 277 DOI 10.17487/RFC2119, March 1997, 278 . 280 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 281 Identifier (URI) DNS Resource Record", RFC 7553, 282 DOI 10.17487/RFC7553, June 2015, 283 . 285 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 286 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 287 May 2017, . 289 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 290 Records through "Underscored" Naming of Attribute Leaves", 291 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 292 . 294 [W3C-DID] W3C, W3C., "Decentralized Identifiers (DIDs) v1.0", 295 February 2020, . 297 11.2. Informative References 299 [DID-METHODS] 300 W3C, W3C., "DID Method Registry", June 2018, 301 . 303 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 304 Resource Identifier (URI): Generic Syntax", STD 66, 305 RFC 3986, DOI 10.17487/RFC3986, January 2005, 306 . 308 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 309 Uniform Resource Identifiers (URI) Dynamic Delegation 310 Discovery System (DDDS) Application (ENUM)", RFC 6116, 311 DOI 10.17487/RFC6116, March 2011, 312 . 314 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 315 Registration of Enumservices: Guide, Template, and IANA 316 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 317 2011, . 319 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 320 Cheshire, "Internet Assigned Numbers Authority (IANA) 321 Procedures for the Management of the Service Name and 322 Transport Protocol Port Number Registry", BCP 165, 323 RFC 6335, DOI 10.17487/RFC6335, August 2011, 324 . 326 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 327 (DANE) Bindings for OpenPGP", RFC 7929, 328 DOI 10.17487/RFC7929, August 2016, 329 . 331 Authors' Addresses 333 Alexander Mayrhofer 334 nic.at GmbH 335 Karlsplatz 1/2/9 336 Vienna 1010 337 Austria 339 Email: alex.mayrhofer.ietf@gmail.com 341 Dimitrij Klesev 343 Email: dimitrij.klesev@gmail.com 345 Markus Sabadello 346 Danube Tech GmbH 347 Annagasse 8/1/8 348 Vienna 1010 349 Austria 351 Email: markus@danubetech.com