idnits 2.17.1 draft-mayrhofer-did-dns-01.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 (February 8, 2019) is 1902 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 274, but no explicit reference was found in the text == Unused Reference: 'RFC6117' is defined on line 280, but no explicit reference was found in the text == Unused Reference: 'RFC6335' is defined on line 285, 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 D. Klesev 4 Intended status: Standards Track nic.at GmbH 5 Expires: August 12, 2019 M. Sabadello 6 Danube Tech GmbH 7 February 8, 2019 9 The Decentralized Identifier (DID) in the DNS 10 draft-mayrhofer-did-dns-01 12 Abstract 14 This document specifies the use of the URI Resource Record Type to 15 publish Decentralized Identifiers (DIDs) in the DNS. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 12, 2019. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Use of the 'URI' RRType . . . . . . . . . . . . . . . . . . . 3 54 3.1. Owner Name Scoping, Target . . . . . . . . . . . . . . . 3 55 3.2. Weight, Priority . . . . . . . . . . . . . . . . . . . . 3 56 4. Location of the Records . . . . . . . . . . . . . . . . . . . 4 57 4.1. Host Names . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.2. Email Addresses (Experimental) . . . . . . . . . . . . . 4 59 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 6. Considered Alternatives . . . . . . . . . . . . . . . . . . . 4 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 10.1. draft-mayrhofer-did-dns-01 . . . . . . . . . . . . . . . 5 66 10.2. draft-mayrhofer-did-dns-00 . . . . . . . . . . . . . . . 5 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 69 11.2. Informative References . . . . . . . . . . . . . . . . . 6 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 Decentralized Identifiers (DIDs) [W3C-DID] use a Uniform Resource 75 Identifier (URI) scheme [RFC3986] to identify persons, organizations, 76 or things in decentralized infrastructure, such as blockchains and 77 distributed ledgers. 79 DIDs are structured around "methods", each method defining the syntax 80 of the method specific identifier and the operations on the 81 respective DIDs (See Section 3.2 of [W3C-DID] and [DID-METHODS]). 82 For many methods, the method specific identifier is not human- 83 friendly (for example, hash values referring to transactions on a 84 blockchain). Most DIDs are therefore inherently hard to memorize for 85 humans. 87 By referring to DIDs from the DNS, those hard to memorize identifiers 88 can be discovered via well known, human friendly and widely 89 established names. This document specifies how DIDs can be published 90 in the DNS for discovery on the base of host names and email 91 addresses. 93 Since DIDs use a URI scheme ('did'), this specification leverages the 94 existing URI DNS Resource Record Type (RRType) [RFC7553]. Records 95 are scoped using the '_did' global underscore node name, as described 96 in Section 3.1. 98 2. Terminology 100 "Owner name", "Priority", "Weight" and "Target" refer to the 101 respective fields of the URI RRType, as specified in Section 4 of 102 RFC7553. 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described in BCP 107 14 [RFC2119] [RFC8174] when, and only when, they appear in all 108 capitals, as shown here. 110 3. Use of the 'URI' RRType 112 DIDs use an URI scheme ('did:'), so the most suitable option to 113 publish DIDs in the DNS is the use of the 'URI' RRType. During the 114 development of this document, various alternatives were considered, 115 see Section 6 for a list. 117 o When Decentralized Identifiers (DIDs) are published in the DNS, 118 the 'URI' RRType MUST be used. 120 3.1. Owner Name Scoping, Target 122 [I-D.ietf-dnsop-attrleaf] describes the advantages of scoping an 123 existing RRType over the definition (and complex deployment) of a new 124 RRType. The "URI" RRType is specifically mentioned as one example 125 where scoping is particularly useful (and part of the design). 127 When DIDs are published in the DNS 129 o the records MUST be scoped by setting the global (highest-level) 130 underscore name of the URI RRset to '_did' (0x5F 0x64 0x69 0x64), 132 o and the Target field of all records in the RRset MUST contain a 133 URI of the 'did:' URI scheme. 135 3.2. Weight, Priority 137 The semantics of the Weight and Priority fields remain. When a 138 client encounters a DID method it does not support, it SHOULD 139 consider the respective DID "unreachable" for the purpose of record 140 selection, and proceed to the URI with the next-lowest-numbered 141 Priority, in accordance with Section 4.2 of RFC 7553. 143 4. Location of the Records 145 4.1. Host Names 147 In order to discover the set of DIDs associated with a Host Name, a 148 client prepends the given Host Name with the '_did' global underscore 149 name to create the Owner name, and then queries the resulting Query 150 Name for the URI RRType set. 152 4.2. Email Addresses (Experimental) 154 To discover DIDs associated with email addresses, the (experimental) 155 model from DNS-Based Authentication of Named Entities (DANE) Bindings 156 for OpenPGP [RFC7929] is used. A client prepares the email address 157 following the procedure outlined in Section 5 in RFC7929, except that 158 the second left-most label in step 5 of that procedure MUST be 159 replaced with the label sequence '_mailto._did' instead to form the 160 Query Name. Subsequently, the client performs a DNS query for the 161 URI RRType (rather than the OPENPGPKEY RRType described in said 162 section). 164 5. Example 166 The following example is a URI Resource Record which refers from the 167 host name "example.net" to a Decentralized Identifier using the 'sov' 168 method: 170 _did.example.net. IN URI 100 10 "did:sov:1234abcd" 172 6. Considered Alternatives 174 During the development of this document, the following alternatives 175 were considered: A dedicated RRType, TXT records, an Enumservice, 176 Well-Known URIs, direct registration in the Service Name Registry. 177 Updating the URI specification was found to be the option with the 178 highest likeliness of interoperability combined with the lowest 179 effort in standardization and implementation/deployment. 181 7. Acknowledgements 183 Acknowledgements will be added here. 185 8. IANA Considerations 187 Per [I-D.ietf-dnsop-attrleaf] IANA is requested to add the 188 following entry to the DNS Underscore Global Scoped Entry 189 Registry: 191 +---------+-------------+-----------+ 192 | RR Type | _NODE NAME | REFERENCE | 193 +---------+-------------+-----------+ 194 | URI | _did | {THISRFC} | 195 +---------+-------------+-----------+ 197 Table 1: Underscore Global Registry Entry Registration for '_did' 199 Note to RFC Editor: Please replace the above "{THISRFC}" text with 200 a reference to this document's RFC number. 202 Note that IANA has already created a provisional URI scheme 203 registration for the 'did:' scheme itself. 205 9. Security Considerations 207 Most of the considerations outlined in the base specification of the 208 URI RRType (RFC7553) also apply to the DID use case - particularly 209 the concerns around downgrade attacks when the record is not signed 210 with the help of DNSSEC. Note that the DID resolving process itself 211 (out of scope of this document) can provide additional security 212 information (such as a backreference to the DNS domain name). 214 Including a DID in the DNS allows to correlate that DID with DNS 215 information, and is therefore NOT RECOMMENDED for DIDs which are 216 supposed to be private. 218 10. Changes 220 [Note to RFC Editors: This whole section is to be removed before 221 publication] 223 10.1. draft-mayrhofer-did-dns-01 225 o email addresses further scoped with '_mailto._did' 227 o Changed protocol registration to attrleaf drafts 229 o Made clear requirements regarding use of the URI scheme 231 o Added privacy aspect to security considerations 233 10.2. draft-mayrhofer-did-dns-00 235 o Initial version 237 11. References 239 11.1. Normative References 241 [I-D.ietf-dnsop-attrleaf] 242 Crocker, D., "DNS Scoped Data Through "Underscore" Naming 243 of Attribute Leaves", draft-ietf-dnsop-attrleaf-16 (work 244 in progress), November 2018. 246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 247 Requirement Levels", BCP 14, RFC 2119, 248 DOI 10.17487/RFC2119, March 1997, 249 . 251 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 252 Identifier (URI) DNS Resource Record", RFC 7553, 253 DOI 10.17487/RFC7553, June 2015, 254 . 256 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 257 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 258 May 2017, . 260 [W3C-DID] W3C, W3C., "Decentralized Identifiers (DIDs) v0.11", July 261 2018, . 263 11.2. Informative References 265 [DID-METHODS] 266 W3C, W3C., "DID Method Registry", June 2018, 267 . 269 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 270 Resource Identifier (URI): Generic Syntax", STD 66, 271 RFC 3986, DOI 10.17487/RFC3986, January 2005, 272 . 274 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 275 Uniform Resource Identifiers (URI) Dynamic Delegation 276 Discovery System (DDDS) Application (ENUM)", RFC 6116, 277 DOI 10.17487/RFC6116, March 2011, 278 . 280 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 281 Registration of Enumservices: Guide, Template, and IANA 282 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 283 2011, . 285 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 286 Cheshire, "Internet Assigned Numbers Authority (IANA) 287 Procedures for the Management of the Service Name and 288 Transport Protocol Port Number Registry", BCP 165, 289 RFC 6335, DOI 10.17487/RFC6335, August 2011, 290 . 292 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 293 (DANE) Bindings for OpenPGP", RFC 7929, 294 DOI 10.17487/RFC7929, August 2016, 295 . 297 Authors' Addresses 299 Alexander Mayrhofer 300 nic.at GmbH 301 Karlsplatz 1/2/9 302 Vienna 1010 303 Austria 305 Email: alex.mayrhofer.ietf@gmail.com 307 Dimitrij Klesev 308 nic.at GmbH 309 Karlsplatz 1/2/9 310 Vienna 1010 311 Austria 313 Email: dimitrij.klesev@nic.at 315 Markus Sabadello 316 Danube Tech GmbH 317 Annagasse 8/1/8 318 Vienna 1010 319 Austria 321 Email: markus@danubetech.com