idnits 2.17.1 draft-mayrhofer-did-dns-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC7553, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC7553, updated by this document, for RFC5378 checks: 2008-02-18) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 6, 2018) is 2089 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) ** Downref: Normative reference to an Informational RFC: RFC 7553 -- Possible downref: Non-RFC (?) normative reference: ref. 'W3C-DID' Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 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 Updates: 7553 (if approved) nic.at GmbH 5 Intended status: Standards Track M. Sabadello 6 Expires: February 7, 2019 Danube Tech GmbH 7 August 6, 2018 9 The Decentralized Identifier (DID) in the DNS 10 draft-mayrhofer-did-dns-00 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 February 7, 2019. 34 Copyright Notice 36 Copyright (c) 2018 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. The '_did' Service Parameter for the URI RRType . . . . . . . 3 54 3.1. Owner Name . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Weight, Priority . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 5 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 63 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 64 10. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 10.1. draft-mayrhofer-did-dns-00 . . . . . . . . . . . . . . . 5 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 5 68 11.2. Informative References . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 71 1. Introduction 73 Decentralized Identifiers (DIDs) [W3C-DID] use a Uniform Resource 74 Identifier (URI) scheme [RFC3986] to identify persons, organizations, 75 or things in decentralized infrastructure, such as blockchains and 76 distributed ledgers. 78 DIDs are structured around "methods", each method defining the syntax 79 of the method specific identifier and the operations on the 80 respective DIDs (See Section 3.2 of [W3C-DID] and [DID-METHODS]). 81 For most methods, the method specific identifier content is not 82 human-friendly (for example, hash values referring to transactions on 83 a blockchain). Most DIDs are therefore inherently hard to memorize 84 for humans. 86 By referring to DIDs from the DNS, those hard to memorize identifiers 87 can be discovered via well known, human friendly and widely 88 established names. This document specifies such a protocol, and 89 describes how DIDs can be discovered on the basis of host names and 90 email addresses. 92 Since DIDs use a URI scheme ('did'), this specification leverages the 93 existing URI DNS Resource Record Type [RFC7553] for that purpose. 94 However, the original specification of the URI RRType limits the 95 possible values for the service parameters of the Owner name, 96 effectively disallowing the DID use case described above. 98 In order to allow inclusion of DIDs in the DNS, this document updates 99 RFC7553 to allow the string '_did' as a service parameter in the 100 Owner name of the URI RRType. For a detailed discussion, see 101 Section 3. 103 2. Terminology 105 "Owner name", "Priority", "Weight" and "Target" refer to the 106 respective fields of the URI RRType, as specified in Section 4 of 107 RFC7553. 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described in BCP 112 14 [RFC2119] [RFC8174] when, and only when, they appear in all 113 capitals, as shown here. 115 3. The '_did' Service Parameter for the URI RRType 117 As described in Section 1, RFC 7553 limits the set of strings allowed 118 as service parameters in the Owner name of the URI RRType. Valid 119 strings have to be registered in either the "Service Name and 120 Transport Protocol Port Number Registry" [RFC6335] or the 121 "Enumservice Registrations" registry [RFC6117]. However, both 122 registries are unsuitable for DIDs because: 124 o DIDs are not tied to a specific transport protocol, hence a 125 registration in the Service Name registry is not possible (See 126 Section 8.1.1. of RFC6335). 128 o Enumservice registrations apply to E.164 Number Mapping (ENUM) 129 [RFC6116] only, while the use case for DIDs in the DNS extends 130 beyond that limited scope. 132 3.1. Owner Name 134 Given the considerations above, it is believed that the most 135 effective way to allow for DIDs in the URI RRType is extending the 136 set of allowed service parameters used in the Owner name as follows: 138 o In addition to the choices listed in Section 4.1 of RFC7553, the 139 service parameter of the Owner name in the URI RRType MAY be set 140 to '_did' (without quotes). 142 o When '_did' is used as service parameter in a URI DNS record, the 143 Target field MUST contain a URI of the 'did:' URI scheme. 145 3.2. Weight, Priority 147 The semantics of the Weight and Priority fields remain. When a 148 client encounters a DID method it does not support, it SHOULD 149 consider the respective DID "unreachable" for the purpose of record 150 selection, and proceed to the URI with the next-lowest-numbered 151 Priority. See Section 4.2 of RFC 7553. 153 4. Location of the Records 155 4.1. Host Names 157 In order to discover the set of DIDs associated with a Host Name, a 158 client prepends the given Host Name with the '_did' Service Parameter 159 to create the Owner name, and then queries for the URI RRType set 160 (RRSet) of the resulting Query Name. 162 4.2. Email Addresses (Experimental) 164 To discover DIDs associated with email addresses, the (experimental) 165 model from DNS-Based Authentication of Named Entities (DANE) Bindings 166 for OpenPGP [RFC7929] is used. A client prepares the email address 167 following the procedure outlined in Section 5 in RFC7929, except that 168 the second left-most label in step 5 of that procedure MUST be set to 169 '_did' instead. Subsequently, the client performs a DNS query for 170 the URI RRType (rather than the OPENPGPKEY RRType described in said 171 section). 173 5. Example 175 The following example is a URI Resource Record which refers from the 176 host name "example.net" to a Decentralized Identifier using the 'sov' 177 method: 179 _did.example.net. IN URI 100 10 "did:sov:1234abcd" 181 6. Considered Alternatives 183 During the development of this document, the following alternatives 184 were considered: A dedicated RRType, TXT records, an Enumservice, 185 Well-Known URIs, direct registration in the Service Name Registry. 186 Updating the URI specification was found to be the option with the 187 highest likeliness of interoperability combined with the lowest 188 impact on standardization and implementation. 190 7. Acknowledgements 192 Acknowledgements will be added here. 194 8. IANA Considerations 196 In order to prevent unintended name space collisions, IANA is 197 requested to reserve the string 'did' (0x64 0x69 0x64) in the Service 198 Name and Transport Protocol Port Number Registry. The reason that a 199 reservation (rather than an assignment) is requested is because 200 according to Section 8.1.1. of RFC6335, a transport protocol is 201 REQUIRED with such a registration. However, DIDs are not related to 202 a specific transport protocol, and so a reservation (if possible) 203 seems to be the only way. 205 Note that IANA has already created a provisional URI scheme 206 registration for the 'did' scheme itself. 208 9. Security Considerations 210 Most of the considerations outlined in the base specification of the 211 URI RRType (RFC7553) also apply to the DID use case - particularly 212 the concerns around downgrade attacks when the record is not signed 213 with the help of DNSSEC. Note that the DID resolving process itself 214 (out of scope of this document) can provide additional security 215 information (such as a backreference to the DNS domain name). 217 10. Changes 219 [Note to RFC Editors: This whole section is to be removed before 220 publication] 222 10.1. draft-mayrhofer-did-dns-00 224 Initial version 226 11. References 228 11.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, 232 DOI 10.17487/RFC2119, March 1997, 233 . 235 [RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource 236 Identifier (URI) DNS Resource Record", RFC 7553, 237 DOI 10.17487/RFC7553, June 2015, 238 . 240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 242 May 2017, . 244 [W3C-DID] W3C, W3C., "Decentralized Identifiers (DIDs) v0.11", July 245 2018, . 247 11.2. Informative References 249 [DID-METHODS] 250 W3C, W3C., "DID Method Registry", June 2018, 251 . 253 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 254 Resource Identifier (URI): Generic Syntax", STD 66, 255 RFC 3986, DOI 10.17487/RFC3986, January 2005, 256 . 258 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 259 Uniform Resource Identifiers (URI) Dynamic Delegation 260 Discovery System (DDDS) Application (ENUM)", RFC 6116, 261 DOI 10.17487/RFC6116, March 2011, 262 . 264 [RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA 265 Registration of Enumservices: Guide, Template, and IANA 266 Considerations", RFC 6117, DOI 10.17487/RFC6117, March 267 2011, . 269 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 270 Cheshire, "Internet Assigned Numbers Authority (IANA) 271 Procedures for the Management of the Service Name and 272 Transport Protocol Port Number Registry", BCP 165, 273 RFC 6335, DOI 10.17487/RFC6335, August 2011, 274 . 276 [RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities 277 (DANE) Bindings for OpenPGP", RFC 7929, 278 DOI 10.17487/RFC7929, August 2016, 279 . 281 Authors' Addresses 283 Alexander Mayrhofer 284 nic.at GmbH 285 Karlsplatz 1/2/9 286 Vienna 1010 287 Austria 289 Email: alex.mayrhofer.ietf@gmail.com 291 Dimitrij Klesev 292 nic.at GmbH 293 Karlsplatz 1/2/9 294 Vienna 1010 295 Austria 297 Email: dimitrij.klesev@nic.at 299 Markus Sabadello 300 Danube Tech GmbH 301 Annagasse 8/1/8 302 Vienna 1010 303 Austria 305 Email: markus@danubetech.com