Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
updates
- rfc-6698 — The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
Extracted elements (7)
People were repeatedly confused about the numeric values and field order in TLSA records during discussions about adding DANE to new protocols. Descriptive acronyms were added to the IANA registry to reduce this confusion without changing the DANE protocol itself.
DANE parsers in applications and DNS software are expected to support parsing the acronyms for each TLSA field in addition to numeric values, enabling use of human-readable forms like 'PKIX-TA CERT SHA2-512' in place of '0 0 2'.
As acronyms are offered for human consumption, case does not matter. Software that parses TLSA records MUST handle upper-, mixed-, or lower-case characters as input when processing acronyms.
The TLSA Certificate Usages registry is updated with an acronym column. Values: 0=PKIX-TA (CA constraint), 1=PKIX-EE (Service certificate constraint), 2=DANE-TA (Trust anchor assertion), 3=DANE-EE (Domain-issued certificate), 255=PrivCert (Reserved for Private Use), 4-254 unassigned.
The TLSA Matching Types registry is updated with an acronym column. Values: 0=Full (No hash used), 1=SHA2-256 (256-bit hash by SHA2), 2=SHA2-512 (512-bit hash by SHA2), 255=PrivMatch (Reserved for Private Use), 3-254 unassigned.
The TLSA Selectors registry is updated with an acronym column. Values: 0=Cert (Full certificate), 1=SPKI (SubjectPublicKeyInfo), 255=PrivSel (Reserved for Private Use), 2-254 unassigned.
This document only changes registry fields and does not change the behavior of any protocol. The intent is to reduce confusion, which is expected to lead to better specification and operations.