idnits 2.17.1 draft-mayrhofer-did-dns-02.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 (August 25, 2019) is 1703 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 287, but no explicit reference was found in the text == Unused Reference: 'RFC6117' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 298, 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: February 26, 2020 6 M. Sabadello 7 Danube Tech GmbH 8 August 25, 2019 10 The Decentralized Identifier (DID) in the DNS 11 draft-mayrhofer-did-dns-02 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 February 26, 2020. 35 Copyright Notice 37 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 4 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 65 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 10.1. draft-mayrhofer-did-dns-02 . . . . . . . . . . . . . . . 5 67 10.2. draft-mayrhofer-did-dns-01 . . . . . . . . . . . . . . . 6 68 10.3. draft-mayrhofer-did-dns-00 . . . . . . . . . . . . . . . 6 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 71 11.2. Informative References . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 Decentralized Identifiers (DIDs) [W3C-DID] use a Uniform Resource 77 Identifier (URI) scheme [RFC3986] to identify persons, organizations, 78 or things in decentralized infrastructure, such as blockchains and 79 distributed ledgers. 81 DIDs are structured around "methods", each method defining the syntax 82 of the method specific identifier and the operations on the 83 respective DIDs (See Section 3.2 of [W3C-DID] and [DID-METHODS]). 84 For many methods, the method specific identifier is not human- 85 friendly (for example, hash values referring to transactions on a 86 blockchain). Most DIDs are therefore inherently hard to memorize for 87 humans. 89 By referring to DIDs from the DNS, those hard to memorize identifiers 90 can be discovered via well known, human friendly and widely 91 established names. This document specifies how DIDs can be published 92 in the DNS for discovery on the base of host names and email 93 addresses. 95 Since DIDs use a URI scheme ('did'), this specification leverages the 96 existing URI DNS Resource Record Type (RRType) [RFC7553]. Records 97 are scoped using the '_did' global underscore node name, as described 98 in Section 3.1. 100 2. Terminology 102 "Owner name", "Priority", "Weight" and "Target" refer to the 103 respective fields of the URI RRType, as specified in Section 4 of 104 RFC7553. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 3. Use of the 'URI' RRType 114 DIDs use an URI scheme ('did:'), so the most suitable option to 115 publish DIDs in the DNS is the use of the 'URI' RRType. During the 116 development of this document, various alternatives were considered, 117 see Section 6 for a list. 119 o When Decentralized Identifiers (DIDs) are published in the DNS, 120 the 'URI' RRType MUST be used. 122 3.1. Owner Name Scoping, Target 124 [RFC8552] describes the advantages of scoping an existing RRType over 125 the definition (and complex deployment) of a new RRType. The "URI" 126 RRType is specifically mentioned as one example where scoping is 127 particularly useful (and part of the design). 129 When DIDs are published in the DNS 131 o the records MUST be scoped by setting the global (highest-level) 132 underscore name of the URI RRset to '_did' (0x5F 0x64 0x69 0x64), 134 o and the Target field of all records in the RRset MUST contain a 135 URI of the 'did:' URI scheme. 137 3.2. Weight, Priority 139 The semantics of the Weight and Priority fields remain. When a 140 client encounters a DID method it does not support, it SHOULD 141 consider the respective DID "unreachable" for the purpose of record 142 selection, and proceed to the URI with the next-lowest-numbered 143 Priority, in accordance with Section 4.2 of RFC 7553. 145 4. Location of the Records 147 4.1. Host Names 149 In order to discover the set of DIDs associated with a Host Name, a 150 client prepends the given Host Name with the '_did' global underscore 151 name to create the Owner name, and then queries the resulting Query 152 Name for the URI RRType set. 154 4.2. Email Addresses (Experimental) 156 To discover DIDs associated with email addresses, the (experimental) 157 model from DNS-Based Authentication of Named Entities (DANE) Bindings 158 for OpenPGP [RFC7929] is used. A client prepares the email address 159 following the procedure outlined in Section 5 in RFC7929, except that 160 the second left-most label in step 5 of that procedure MUST be 161 replaced with the label sequence '_mailto._did' instead to form the 162 Query Name. Subsequently, the client performs a DNS query for the 163 URI RRType (rather than the OPENPGPKEY RRType described in said 164 section). 166 5. Example 168 The following example is a URI Resource Record which refers from the 169 host name "example.net" to a Decentralized Identifier using the 'sov' 170 method: 172 _did.example.net. IN URI 100 10 "did:sov:1234abcd" 174 6. Considered Alternatives 176 During the development of this document, the following alternatives 177 were considered: A dedicated RRType, TXT records, an Enumservice, 178 Well-Known URIs, direct registration in the Service Name Registry. 179 Updating the URI specification was found to be the option with the 180 highest likeliness of interoperability combined with the lowest 181 effort in standardization and implementation/deployment. 183 Furthermore, the Identifiers and Discovery Working Group of the 184 Decentralized Identity Foundation (DIF) is considering a .well-known 185 URL based approach to discovering DIDs from web sites. 187 7. Acknowledgements 189 Acknowledgements will be added here. 191 8. IANA Considerations 193 Per [RFC8552] IANA is requested to add the following entry to the 194 DNS Underscore Global Scoped Entry Registry: 196 +---------+-------------+-----------+ 197 | RR Type | _NODE NAME | REFERENCE | 198 +---------+-------------+-----------+ 199 | URI | _did | {THISRFC} | 200 +---------+-------------+-----------+ 202 Table 1: Underscore Global Registry Entry Registration for '_did' 204 Note to RFC Editor: Please replace the above "{THISRFC}" text with 205 a reference to this document's RFC number. 207 Note that IANA has already created a provisional URI scheme 208 registration for the 'did:' scheme itself. 210 9. Security Considerations 212 Most of the considerations outlined in the base specification of the 213 URI RRType (RFC7553) also apply to the DID use case - particularly 214 the concerns around downgrade attacks when the record is not signed 215 with the help of DNSSEC. Note that the DID resolving process itself 216 (out of scope of this document) can provide additional security 217 information (such as a backreference to the DNS domain name). 219 Including a DID in the DNS allows to correlate that DID with DNS 220 information, and is therefore NOT RECOMMENDED for DIDs which are 221 supposed to be private. 223 10. Changes 225 [Note to RFC Editors: This whole section is to be removed before 226 publication] 228 10.1. draft-mayrhofer-did-dns-02 230 o Updated attrleaf reference to RFC8552 232 o Changed author information for D. Klesev 234 o Added sentence on .well-known discovery scheme 236 10.2. draft-mayrhofer-did-dns-01 238 o email addresses further scoped with '_mailto._did' 240 o Changed protocol registration to attrleaf drafts 242 o Made clear requirements regarding use of the URI scheme 244 o Added privacy aspect to security considerations 246 10.3. draft-mayrhofer-did-dns-00 248 o Initial version 250 11. References 252 11.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 260 Identifier (URI) DNS Resource Record", RFC 7553, 261 DOI 10.17487/RFC7553, June 2015, 262 . 264 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 265 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 266 May 2017, . 268 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 269 Records through "Underscored" Naming of Attribute Leaves", 270 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 271 . 273 [W3C-DID] W3C, W3C., "Decentralized Identifiers (DIDs) v0.11", July 274 2018, . 276 11.2. Informative References 278 [DID-METHODS] 279 W3C, W3C., "DID Method Registry", June 2018, 280 . 282 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 283 Resource Identifier (URI): Generic Syntax", STD 66, 284 RFC 3986, DOI 10.17487/RFC3986, January 2005, 285 . 287 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 288 Uniform Resource Identifiers (URI) Dynamic Delegation 289 Discovery System (DDDS) Application (ENUM)", RFC 6116, 290 DOI 10.17487/RFC6116, March 2011, 291 . 293 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 294 Registration of Enumservices: Guide, Template, and IANA 295 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 296 2011, . 298 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 299 Cheshire, "Internet Assigned Numbers Authority (IANA) 300 Procedures for the Management of the Service Name and 301 Transport Protocol Port Number Registry", BCP 165, 302 RFC 6335, DOI 10.17487/RFC6335, August 2011, 303 . 305 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 306 (DANE) Bindings for OpenPGP", RFC 7929, 307 DOI 10.17487/RFC7929, August 2016, 308 . 310 Authors' Addresses 312 Alexander Mayrhofer 313 nic.at GmbH 314 Karlsplatz 1/2/9 315 Vienna 1010 316 Austria 318 Email: alex.mayrhofer.ietf@gmail.com 320 Dimitrij Klesev 322 Email: dimitrij.klesev@gmail.com 323 Markus Sabadello 324 Danube Tech GmbH 325 Annagasse 8/1/8 326 Vienna 1010 327 Austria 329 Email: markus@danubetech.com