One document matched: draft-ietf-dane-registry-acronyms-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" ".//reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-dane-registry-acronyms-04"
     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" ?>


  <front>
    <title abbrev="Adding acronyms to DANE registries">
      Adding acronyms to simplify DANE conversations
    </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 />
      
      <area>Security</area>
      
      <workgroup>DANE</workgroup>
      
      <abstract>
	<t>Experience has shown that people get confused using the three
	numeric fields 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 RFC6698.
	</t> 
      </abstract>
  </front>

  <middle>
    <section title="Introduction"> 
      <t> During discussions on how to add DANE <xref target="RFC6698"/> 
	technology to new protocols/services people repeatedly have
	got confused as to what the numeric values stand for and even 
	the order of the fields of a TLSA record (TLSA is not an acronym
	 but a name).
	This document updates the IANA registry definition for TLSA
	record to add a column with 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 "DNS-Based Authentication of Named
	Entities (DANE) Parameters" located at 
	"http://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml". 
	Each one of the Sub-registries will add a column with an acronym
	for that field. </t> 
      <t> <xref target="RFC6698"/> and this document are both to be
	the reference 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.
      </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> Update reference for this registry to include both
	[RFC6698] and [RFC-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> Update reference for this registry to include both
	[RFC6698] and [RFC-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> Update reference for this registry to include both
	[RFC6698] and [RFC-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 below </t> 
      <section title="TLSA records using/displaying the acronyms: ">
	<t>
	  <vspace/>
	  _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 and lead to better specification and operations.</t> 
  </section>

  <section title="Acknowledgements"> 
      <t>Scott Schmit offered real good suggestions to decrease the 
	possibility of confusion. Viktor Dukhovni provided comments
	from expert point of view. Jim Schaad, Wes Hardaker and Paul
	Hoffman provided feedback during WGLC. 
	Dan Romascanu and Tobias Gondrom provided pointed out few
	defects in 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>
    <section title="Document history"> 
      <t>[RFC Editor: Please remove this section before publication ]</t>
      
      <t> 00 Initial version </t> 
      <t> 01 Updated version based on some comments ready for
      WGLC </t>
      <t> 00 WG version almost identical to 01 </t>
      <t> 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 
      </t> 
      <t> 02 WG version PKIX-CA ==> PKIX-TA </t> 
      <t> 03 IETF submission version, abstract needed to mention
      RFC6698.</t>
      <t> 04 Addressed all comments received during IETF last call</t>
    </section>
    </back>
</rfc>