On Mon, Dec 02, 2013 at 03:05:39PM -0800, John Gilmore wrote:
> I propose that we reject the draft entirely and stick with numbers.
> If we can't agree on the acronyms, can we stop rearranging the deck
> chairs? A focus on making "running code" for the current DANE RFC
> would produce far more deployment than replacing numbers with words.
I never found the numbers to be an obstacle, and my focus is as
you suggest implementation. I am looking at (really) adding DANE
support to OpenSSL (the experimental code in 1.0.2 is IMHO not
satisfactory).
There is also an optional DANE interface in GnuTLS, it too is not
a production-quality DANE implementation. If any GnuTLS maintainers
are on the list, they should get in touch.
As for the acronyms, I took the draft introduction at its word,
which is to say that for this discussion I assumed that indeed some
implementors or server operators who need to generate TLSA records
do find the numbers confusing. Perhaps as John suggests numbers
are better than misleading acronyms, at least then people will read
the RFC, rather than guess incorrectly from the acronym.
So in the end acronyms would only be useful if they make operator
mistakes less likely:
0 - REQUIRED-CA
1 - REQUIRED-LEAF
2 - TRUSTED-CA
3 - MATCHING-LEAF
or perhaps :-)
0 - CA-LOVER
1 - CA-SLAVE
2 - CA-OWNER
3 - CA-HATER
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
