In message <[email protected]>, Viktor Dukhovni writes
:
> On Sat, Dec 07, 2013 at 06:34:40PM -0800, John Gilmore wrote:
>
> > > Any (strong) objections?
> >
> > Yes, I object. If there is no consensus on acronyms, we should stick
> > with what is in the current RFC 6698, rather than forwarding an
> > acronym proposal for adoption as a standard, even though we can't
> > agree on what it should say. It's unnecessary, which probably
> > explains the paucity of responses, and divisive among those who did
> > respond. It should be abandoned.
>
> Perhaps the author is willing to take a look at the history of the
> thread, and propose one final set of names for the 4 usages that
> makes most sense to him. We can then object or concur with those
> without (yet again) proposing changes.
>
> I am not fundamentally opposed to human-readable TLSA RRs:
>
> ; _25._tcp.mx.example.com. IN TLSA 3 1 2
> _25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[
If anything other than numeric values appear in the records you
will break existing TLSA record parsers. Names are useful when
describing thing. They are no useful for portability and definitely
break the future proofing in the original presentation format.
For DNSKEY we display them as comments after the record. The record
itself purely numeric and future proof.
e.g.
; <<>> DiG 9.10.0a1 <<>> dnskey . +rrcomments
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7742
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;. IN DNSKEY
;; ANSWER SECTION:
. 4753 IN DNSKEY 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ; KSK;
alg = RSASHA256; key id = 19036
. 4753 IN DNSKEY 256 3 8
AwEAAYRU41/8smgAvuSojEP4jaj5Yll7WPaUKpYvnz2pnX2VIvRn4jsy
Jns80bloenG6X9ebJVy2CFtZQLKHP8DcKmIFotdgs2HolyocY1am/+33
4RtzusM2ojkhjn1FRGtuSE9s2TSz1ISv0yVnFyu+EP/ZkiWnDfWeVrJI SEWBEr4V ; ZSK; alg =
RSASHA256; key id = 59085
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Dec 09 11:52:43 EST 2013
;; MSG SIZE rcvd: 450
TLSA, like DNSKEY, will need tools to take certs etc. and generate
TLSA records. Those tools can use names but they emit records in
numeric form.
> ; _25._tcp.mx.example.com. IN TLSA 2 0 2
> _25._tcp.mx.example.com. IN TLSA TRUSTED-CA CERTIFICATE SHA2-512 {blob}
>
> ; _25._tcp.mx.example.com. IN TLSA 1 0 1
> _25._tcp.mx.example.com. IN TLSA VALID-LEAF PUBLIC-KEY SHA2-256 {blob}
>
> ; _25._tcp.mx.example.com. IN TLSA 0 1 0
> _25._tcp.mx.example.com. IN TLSA VALID-CA PUBLIC-KEY VALUE {blob}
>
> As much possible, the acronyms should avoid jargon unfamiliar to
> their intended audience and in a full TLSA record should ideally
> read like a complete sentence, as above.
>
> The dichotomy between "TRUSTED" (sufficient on its own) and "VALID"
> (not sufficient without external trust) is I think one reasonable
> way to communicate the usage values.
>
> Anyway, I think it is up to the author to propose a final revision,
> or as John suggests, give up.
>
> --
> Viktor.
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
