One document matched: draft-ietf-dane-registry-acronyms-00.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-00"
     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 show 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. 
	</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 what the numeric values stand for and even 
	the order of the fields of a TLSA record.
	This document updates the IANA registry definition for TLSA
	record to add a column with 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 parser's in applications and DNS
	software MAY adopt parsing the acronyms for each field, installed
	base MAY NOT get updated.
      </t> 
 
      
      <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 the parses TLSA
      records will handle any case use in the input> The expectation is 
      that by using the acronyms in production systems fewer bad TLSA
      records will be published. 
      </t>
      
      <section title="TLSA Certificate Usages"> 
	<!-- 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] -->      
	<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>
	  <c>0</c> <c>PKIX-CA</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> Note: should the short description be updated to be more
	expressive ? </t> 
	<t> Other options suggested for 0: PKIX-TA</t> 
      </section> 
      <section title="TLSA Selectors">
	<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"> 
	
	<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="RFC6698"/>  </c>
	  <c> 2 </c> <c>SHA2-512</c> <c>512 bit hash by SHA2 </c> <c> <xref target="RFC6698"/>  </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> TLSA records using/displaying the acronyms: 
	<vspace/>
	_666._tcp.first.example. TLSA PKIX-CA CERT SHA2-512 {blob}  
	<vspace/>
	_666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob}  
      </t> 
      <t> Acronym use in a specification example: "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 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. </t>
    </section> 
  </middle>
  <back>
    <references title="Normative References">
      <?rfc include='reference.RFC.2119'?>
      <?rfc include='reference.RFC.6698'?>
    </references>
    
    <!--    <references title="Informative References">
	    </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>
    </section>
  </back>
</rfc>