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

[Ballot comment]
Stephen and I spent a couple of billion nanoseconds on this. That's enough of them.

I do think that this document should be Informational. Any normative information is buried in an IANA Considerations section that I suspect will not be read after publication. Nothing requires that this be standards track, and the odds that it will advance are zero. The fact that it "Updates" a standards track document or that it is "changing a registry defined by a standards track document" does not require it to be standards track.

But the world will continue to spin. The number of bits spent on this has perturbed the spinning quite enough.

[Ballot comment]
In section 2.2, right after the caption for Table 1, the following text appears:

  Other options suggested for 0: PKIX-TA

It appears that this is what is actually in the table, so this text makes no sense.

[Ballot discuss]
This is a purely administrative point for the IESG. It will not hold up publication for even a nanosecond.

Let's make this "Informational", shall we? Nothing requires that this be standards track, and the odds that it will advance are zero. (And before you say that it "Updates" a standards track document or that it is "changing a registry defined by a standards track document", I'd like a citation of somewhere that says that you can't do that with an Informational document.)

If the IESG agrees and we change the status, I will clear immediately. If not, I will not stand in the way of publication at all and simply Abstain, no hard feelings at all.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dane-registry-acronyms-03.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which IANA must complete.

First, in the three registries contained in the DNS-Based Authentication of Named Entities (DANE) Parameters located at:

http://www.iana.org/assignments/dane-parameters/

the reference for each of the three registries will be changed from [RFC6698] to both [RFC6698] and [ RFC-to-be ].

Second, each one of the registries located at

http://www.iana.org/assignments/dane-parameters/

will have a new column added.  This new field will be called "Acronym."


Third, the three registries will be modified to add the Acronym field and will appear as follows:

TLSA Certificate Usages

+-------+----------+--------------------------------+-------------+
| 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]  |
+-------+----------+--------------------------------+-------------+

TLSA Selectors

+-------+---------+--------------------------+-------------+
| Value | Acronym | Short Description        | Reference  |
+-------+---------+--------------------------+-------------+
|  0  | Cert    | Full certificate        | [RFC6698]  |
|  1  | SPKI    | SubjectPublicKeyInfo    | [RFC6698]  |
| 2-254 |        | Unassigned              |            |
|  255  | PrivSel | Reserved for Private Use | [RFC6698]  |
+-------+---------+--------------------------+-------------+

TLSA Matching types

+-------+-----------+--------------------------+-------------+
| Value | Acronym  | Short Description        | Reference  |
+-------+-----------+--------------------------+-------------+
|  0  | Full      | No hash used            | [RFC6698]  |
|  1  | SHA2-256  | 256 bit hash by SHA2    | [RFC6698]  |
|  2  | SHA2-512  | 512 bit hash by SHA2    | [RFC6698]  |
| 3-254 |          | Unassigned              |            |
|  255  | PrivMatch | Reserved for Private Use | [RFC6698]  |
+-------+-----------+--------------------------+-------------+

IANA understands that these three actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Adding acronyms to simplify DANE conversations) to Proposed Standard


The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'Adding acronyms to simplify DANE conversations'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-01-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

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

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.

2. Review and Consensus

The short document was thoroughly reviewed in the WG. That very active discussion among many people led to some very deep 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. I do not believe that the wording in the current draft represents "rough consensus" but, at the same time, I don't see any of the other options as having noticeably more consensus.

3. Intellectual Property

I did not confirm that each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79 because that is unnecessary for this document. The document adds synonyms to an existing protocol.

4. Other Points

There is still wide disagreement about the meaning of self-signed certificates and what it means to be part of "PKIX". This disagreement comes from many WG members' discussions of security with people who use IETF security technologies, as well as some strong personal biases. The discussion in the WG was mostly thoughtful even when it was forceful. Given this, it is likely impossible to come up with names for the "certificate usage" that will make even most people happy.