DANEInternet Engineering Task Force (IETF) O. GudmundssonInternet-DraftRequest for Comments: 7218 Shinkuro Inc. Updates: 6698(if approved) February 14,April 2014Intended status:Category: Standards TrackExpires: August 18, 2014ISSN: 2070-1721 AddingacronymsAcronyms tosimplify DANE conversations draft-ietf-dane-registry-acronyms-04Simplify Conversations about DNS-Based Authentication of Named Entities (DANE) Abstract Experience has shown that people get confusedusingwhen discussing the three numeric fields of the TLSA record. This document specifies descriptive acronyms for the three numeric fields in the TLSA records. This document updates the format of the IANA registry created byRFC6698.RFC 6698. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany 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 August 18, 2014.http://www.rfc-editor.org/info/rfc7218. Copyright Notice Copyright (c) 2014 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 (http://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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. IANAconsiderationsConsiderations . . . . . . . . . . . . . . . . . . . . . 2 2.1. TLSA Certificate Usages Registry . . . . . . . . . . . .23 2.2. TLSA Selectors . . . . . . . . . . . . . . . . . . . . . 3 2.3. TLSA MatchingtypesTypes . . . . . . . . . . . . . . . . . . . 3 3. Examples ofusageUsage . . . . . . . . . . . . . . . . . . . . . . 4 3.1. TLSArecords using/displayingRecords Using/Displaying theacronyms:Acronyms . . . . . . . 4 3.2. AcronymuseUse in aspecification example:Specification Example . . . . . . . . . 4 4. SecurityconsiderationsConsiderations . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 6.1. Normative References . . . . . . . . . . . . . . . . . . 4 6.2. Informative References . . . . . . . . . . . . . . . . .4 Appendix A. Document history . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .5 1. Introduction During discussions on how to addDANEDNS-Based Authentication of Named Entities (DANE) [RFC6698] technology to newprotocols/servicesprotocols and services, people were repeatedlyhave gotconfused as to what the numeric valuesstandstood for and even the order of the fields of a TLSA record(TLSA(note that TLSA is not an acronym but a name). This document updates the IANA registry definition for the TLSA record to add a columnwithcontaining an acronym for each specified field, in order to reduce confusion. This document does not change the DANE protocol in any way. It is expected that DANE parsers in applications and DNS software can adopt parsing the acronyms for each field. 2. IANAconsiderationsConsiderations This document applies to the "DNS-Based Authentication of Named Entities (DANE) Parameters" registry located at"http://www.iana.org/assignments/dane- parameters/dane-parameters.xhtml". Each one of the Sub-registries will add<http://www.iana.org/ assignments/dane-parameters>. IANA has added a column with an acronymfor that field.to each of the sub-registries. [RFC6698] and this document areboth to bethereferencereferenced documents for the three sub-registries. As these acronyms are offered for human consumption, case does notmatter,matter; it is expected that software that parses TLSA records will handleupper, mixedupper-, mixed-, orlower caselower-case use as input. 2.1. TLSA Certificate Usages RegistryUpdateThe reference for this registry has been updated to include both [RFC6698] and[RFC-this-document]this document. +-------+----------+--------------------------------+-------------+ | Value | Acronym | Short Description | Reference | +-------+----------+--------------------------------+-------------+ | 0 | PKIX-TA | CA constraint | [RFC6698] | | 1 | PKIX-EE | Service certificate constraint | [RFC6698] | | 2 | DANE-TA | Trust anchor assertion | [RFC6698] | | 3 | DANE-EE | Domain-issued certificate | [RFC6698] | | 4-254 | | Unassigned | | | 255 | PrivCert | Reserved for Private Use | [RFC6698] | +-------+----------+--------------------------------+-------------+ Table 1: TLSA Certificate UsagesOther options suggested for 0: PKIX-TA2.2. TLSA SelectorsUpdateThe reference for this registry has been updated to include both [RFC6698] and[RFC-this-document]this document. +-------+---------+--------------------------+-------------+ | Value | Acronym | Short Description | Reference | +-------+---------+--------------------------+-------------+ | 0 | Cert | Full certificate | [RFC6698] | | 1 | SPKI | SubjectPublicKeyInfo | [RFC6698] | | 2-254 | | Unassigned | | | 255 | PrivSel | Reserved for Private Use | [RFC6698] | +-------+---------+--------------------------+-------------+ Table 2: TLSA Selectors 2.3. TLSA Matchingtypes UpdateTypes The reference for this registry has been updated to include both [RFC6698] and[RFC-this-document]this document. +-------+-----------+--------------------------+-------------+ | Value | Acronym | Short Description | Reference | +-------+-----------+--------------------------+-------------+ | 0 | Full | No hash used | [RFC6698] | | 1 | SHA2-256 | 256 bit hash by SHA2 | [RFC6234] | | 2 | SHA2-512 | 512 bit hash by SHA2 | [RFC6234] | | 3-254 | | Unassigned | | | 255 | PrivMatch | Reserved for Private Use | [RFC6698] | +-------+-----------+--------------------------+-------------+ Table 3: TLSA MatchingtypesTypes 3. Examples ofusageUsage Two examplesbeloware described below. 3.1. TLSArecords using/displayingRecords Using/Displaying theacronyms:Acronyms _666._tcp.first.example. TLSA PKIX-TA CERT SHA2-512 {blob} _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} 3.2. AcronymuseUse in aspecification example:Specification Example Protocol FOO only allows TLSA records using PKIX-EE and DANE-EE, with selectorSPKISPKI, and using SHA2-512. 4. SecurityconsiderationsConsiderations This document only changes registry fields and does not change the behavior of any protocol. The hope is to reduceconfusion andconfusion, which would lead to better specification and operations. 5. Acknowledgements Scott Schmit offeredrealreally good suggestions to decrease the possibility of confusion. Viktor Dukhovni provided comments from the expert point of view. Jim Schaad, WesHardakerHardaker, and Paul Hoffman provided feedback during WGLC. Dan Romascanu and Tobias Gondromprovidedpointed out a few defectsinduring the IESG last call. 6. References 6.1. Normative References [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. 6.2. Informative References [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.Appendix A. Document history [RFC Editor: Please remove this section before publication ] 00 Initial version 01 Updated version based on some comments ready for WGLC 00 WG version almost identical to 01 01 WG version result of WG last call one possible issue remains PKIX- CA ==> PKIX-TA no clear message if that change should be made 02 WG version PKIX-CA ==> PKIX-TA 03 IETF submission version, abstract needed to mention RFC6698. 04 Addressed all comments received during IETF last callAuthor's Address Olafur Gudmundsson Shinkuro Inc. 4922 Fairmont Av, Suite 250 Bethesda, MD 20814 USAEmail:EMail: ogud@ogud.com