<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>

<rfc number="7218" category="std" submissionType="IETF" consensus="yes"
  ipr="trust200902" updates="6698">

  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>


  <?rfc toc="yes" ?>
  <?rfc symrefs="yes" ?>
  <?rfc sortrefs="yes"?>
  <?rfc iprnotified="no" ?>
  <?rfc strict="yes"?>
  <?rfc compact="yes" ?>
   <?rfc subcompact="no" ?>
   <?rfc rfcedstyle="yes" ?>


  <front>
    <title abbrev="Adding Acronyms to DANE Registries">
      Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities
      (DANE)
    </title>
     
      <author fullname="Olafur Gudmundsson" initials="O." surname="Gudmundsson">
	<organization>Shinkuro Inc.</organization>
	<address>
	  <postal>
	    <street>4922 Fairmont Av, Suite 250</street>
	    <city>Bethesda</city>
	    <region>MD</region>
	    <code>20814</code>
	    <country>USA</country>
	  </postal>
	  <email>ogud@ogud.com</email>
	</address>
      </author>
      <date month="April" year="2014"/>
      
      <area>Security</area>
      
      <workgroup>DANE</workgroup>
      
<!-- [rfced] Please insert any keywords (beyond those that appear in 
the title) for use on http://www.rfc-editor.org/search.
-->

<keyword>example</keyword>


      <abstract>
	<t>Experience has shown that people get confused when 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
	by RFC 6698.
	</t> 
      </abstract>
  </front>

  <middle>
    <section title="Introduction"> 
      <t> During discussions on how to add DNS-Based Authentication of Named
      Entities (DANE) <xref target="RFC6698"/> 
	technology to new protocols and services, people were repeatedly 
	confused as to what the numeric values stood for and even 
	the order of the fields of a TLSA record (note that TLSA is not an acronym
	 but a name).
	This document updates the IANA registry definition for the TLSA
	record to add a column containing an acronym for each specified field, in
	order to reduce confusion.
	This document does not change the DANE protocol in any way. 
      </t> 
      <t>It is expected that DANE parsers in applications and DNS
	software can adopt parsing the acronyms for each field.
      </t> 
      
      
<!-- removed as asked in WGLC 
    <section title="Requirements notation">
	<t>
	  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	  this document are to be interpreted as described in
	  <xref target="RFC2119" />.
	</t>
      </section> 
-->
    </section>   <!-- End introduction -->
    
    
    <section title="IANA Considerations">
      <t> This document applies to the "DNS-Based Authentication of Named
	Entities (DANE) Parameters" registry located at 
	&lt;http://www.iana.org/assignments/dane-parameters&gt;.
	IANA has added a column with an acronym
	to each of the sub-registries. </t> 
      <t> <xref target="RFC6698"/> and this document are 
	the referenced documents for the three sub-registries. </t> 
      <t> As these acronyms are offered for human consumption, case
      does not matter; it is expected that software that parses TLSA
      records will handle upper-, mixed-, or lower-case use as input.
<!-- [rfced] We wonder whether "characters" would be better than "use" in the
following:

Original:
   As these acronyms are offered for human consumption, case does not
   matter, it is expected that software that parses TLSA records will
   handle upper, mixed or lower case use as input.

Perhaps:
   As these acronyms are offered for human consumption, case                   
   does not matter; it is expected that software that parses TLSA                  
   records will handle upper-, mixed-, or lower-case characters as input.
-->
      </t>
      
      <section title="TLSA Certificate Usages Registry"> 
	<!-- Value,Short Description,Reference
	     0,CA constraint,[RFC6698]
	     1,Service certificate constraint,[RFC6698]
	     2,Trust anchor assertion,[RFC6698]
	     3,Domain-issued certificate,[RFC6698]
	     4-254,Unassigned,
	     255,Reserved for Private Use,[RFC6698] -->      
	<t> The reference for this registry has been updated to include both
	[RFC6698] and this document.</t>
	<texttable anchor="Usages" title="TLSA Certificate Usages"> 
	  <ttcol align='center'> Value</ttcol>
	  <ttcol align='left'> Acronym</ttcol>
	  <ttcol align='left'> Short Description</ttcol>
	  <ttcol align='left'> Reference</ttcol>
<!-- PKIX-CA vs PKIX-TA  Jame and Victor for, Victor flippflooped  XXX -->
	  <c>0</c> <c>PKIX-TA</c>     <c>CA constraint</c>            <c><xref target="RFC6698"/> </c>
	  <c>1</c> <c>PKIX-EE</c>   <c>Service certificate constraint</c><c><xref target="RFC6698"/> </c>
	  <c>2</c> <c>DANE-TA</c>     <c>Trust anchor assertion</c><c><xref target="RFC6698"/> </c>
	  <c>3</c> <c>DANE-EE</c>  <c>Domain-issued certificate</c><c><xref target="RFC6698"/> </c>
	  <c>4-254</c> <c> </c>       <c>Unassigned</c>     <c> </c>
	  <c>255</c> <c>PrivCert</c>  <c>Reserved for Private Use</c><c><xref target="RFC6698"/>  </c>
	</texttable>
<!--	<t> Other options suggested for 0: PKIX-TA</t>  -->
      </section> 
      <section title="TLSA Selectors">
	<t> The reference for this registry has been updated to include both
	[RFC6698] and this document.</t>
	<texttable anchor="Selectors" title="TLSA Selectors"> 
	  <ttcol align='center'> Value</ttcol>
	  <ttcol align='left'> Acronym</ttcol>
	  <ttcol align='left'> Short Description</ttcol>
	  <ttcol align='left'> Reference</ttcol>
	  <c>0</c> <c> Cert</c> <c> Full certificate</c><c><xref target="RFC6698"/>  </c>
	  <c>1</c> <c> SPKI</c> <c>SubjectPublicKeyInfo</c><c><xref target="RFC6698"/>  </c>
	  <c> 2-254</c><c></c><c>Unassigned</c><c></c>
	  <c> 255</c><c>PrivSel</c><c>Reserved for Private Use</c><c><xref target="RFC6698"/>  </c>
	</texttable>
	<!--
	    Value,Short Description,Reference
	    0,Full certificate,[RFC6698]
	    1,SubjectPublicKeyInfo,[RFC6698]
	    2-254,Unassigned,
	    255,Reserved for Private Use,[RFC6698]
	  --> 
      </section> 
      
      <section title="TLSA Matching Types"> 
	<t> The reference for this registry has been updated to include both
	[RFC6698] and this document.</t>
	
	<texttable anchor="Matching" title="TLSA Matching Types"> 
	  <ttcol align='center'> Value</ttcol>
	  <ttcol align='left'> Acronym</ttcol>
	  <ttcol align='left'> Short Description</ttcol>
	  <ttcol align='left'> Reference</ttcol>
	  <c> 0 </c> <c> Full</c> <c> No hash used</c> <c> <xref target="RFC6698"/>  </c>
	  <c> 1 </c> <c>SHA2-256</c> <c> 256 bit hash by SHA2</c><c> <xref target="RFC6234"/>  </c>
	  <c> 2 </c> <c>SHA2-512</c> <c>512 bit hash by SHA2 </c> <c> <xref target="RFC6234"/>  </c>
	  <c> 3-254</c> <c> </c> <c> Unassigned </c> <c> </c> 
	  <c>255</c> <c>PrivMatch</c> <c>Reserved for Private Use</c> <c><xref target="RFC6698"/>  </c>
	</texttable>
	
	<!--	
		Value,Short Description,Reference
		0,No hash used,[RFC6698]
		1,SHA-256,[RFC6234]
		2,SHA-512,[RFC6234]
		3-254,Unassigned,
		255,Reserved for Private Use,[RFC6698]
	  -->
      </section>
  </section> 
    <section title="Examples of Usage"> 
      <t> Two examples are described below. </t> 
      <section title="TLSA Records Using/Displaying the Acronyms">
	<t>
	  _666._tcp.first.example.  TLSA PKIX-TA CERT SHA2-512 {blob}  
	  <vspace/>
	  _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob}  
	</t> 
      </section>
      <section title="Acronym Use in a Specification Example"> 
	<t>
	  Protocol FOO only allows
	TLSA records using PKIX-EE and DANE-EE, with selector SPKI, and
	using SHA2-512. </t>
<!--      <t> Sides example: "In the case of FOO for practical cases you
	can treat PKIX-CA == DANE-TE" (see talk at IETF-87 on DANE for
	email)  </t>  -->
    </section>
  </section> 
    
  <section title="Security Considerations"> 
    <t> This document only changes registry fields and does
      not change the behavior of any protocol. The hope is to reduce
      confusion, which would lead to better specification and operations.</t> 
  </section>

  <section title="Acknowledgements"> 
      <t>Scott Schmit offered really good suggestions to decrease the 
	possibility of confusion. Viktor Dukhovni provided comments
	from the expert point of view. Jim Schaad, Wes Hardaker, and Paul
	Hoffman provided feedback during WGLC. 
	Dan Romascanu and Tobias Gondrom pointed out a few
	defects during the IESG last call. 
      </t>
  </section> 
</middle>
  <back>
    <references title="Normative References">
<!--      <?rfc include='reference.RFC.2119'?> -->
      <?rfc include='reference.RFC.6698'?>
    </references>
    
<references title="Informative References">
  <?rfc include="reference.RFC.6234"?>
	    </references>
    </back>
</rfc>
