Skip to main content

Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
RFC 7218

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    dane mailing list <>,
    dane chair <>
Subject: Protocol Action: 'Adding acronyms to simplify DANE conversations' to Proposed Standard (draft-ietf-dane-registry-acronyms-04.txt)

The IESG has approved the following document:
- 'Adding acronyms to simplify DANE conversations'
  (draft-ietf-dane-registry-acronyms-04.txt) as Proposed Standard

This document is the product of the DNS-based Authentication of Named
Entities Working Group.

The IESG contact persons are Stephen Farrell and Sean Turner.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

   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.  This document
   updates the format of the IANA registry created by RFC6698.

Working Group Summary

    This document is a small update to RFC 6698, the specification 
    for the DNS-Based Authentication of Named Entities (DANE) 
    Transport Layer Security (TLS) Protocol, also known by its DNS
    RRset name, TLSA. The revision has one narrow purpose: to 
    give the three numeric fields in the RRtype definition mnemonic 
    names. This is meant to allow easier discussion of TLSA, particular 
    for the "certificate usage" field that specifies what type of public key 
    is in the TLSA record. Because this draft updates a standards track 
    RFC, the draft is meant to be a proposed standard as well.

    The short document was thoroughly reviewed in the WG. That 
    very active discussion among many people led to some very deep 
    (but pointless:-) divisions in the WG about what the "certificate 
    usage" fields should be called. The WG chairs called rough 
    consensus, but a significant number of people in the WG 
    disagreed that there was consensus at all. It should be noted 
    that the WG has consensus that some terminology is better 
    than just having the numbers in RFC 6698; however, there are 
    strong opinions for three or four different sets of terminology. The
    shepherd does not believe that the wording in the current draft 
    represents "rough consensus" but, at the same time, he doesn't 
    see any of the other options as having noticeably more consensus.
    The responsible AD is ok with that, as are the chairs. There is
    consensus that impercted words are better than numbers.

Document Quality

    There are DANE tools, not sure if this has been coded up in
    those. AD thinks he recalls one developer who said he'd add
    this but only after we stop futzing with different names.


   Paul Hoffman is the document shepherd; Stephen Farrell is the responsible AD.

RFC Editor Note

   Please delete the text "Other options suggested for 0: PKIX-TA"
   from section 2.1 - its a bit of hanging text in the xml file that
   should be gone or commented out. The authors may do for
   you before auth-48.

RFC Editor Note