Re: [dane] On the PKIX-TA / PKIX-CA question? [ One week WGLC ]

[Viktor Dukhovni <[e-mail]>]

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}[

    ; _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.