On Fri, Dec 06, 2013 at 03:00:17PM -0500, Warren Kumari wrote:
> > The sample size of responses seems too small to reach a meaningful
> > consensus.
>
> Unfortunately both too small, and not all in agreement.
>
> I'm going to extend this LC to Wednesday and suggest that, if we
> don't get consensus on this we simply stick with what is in the
> current (draft-ietf-dane-registry-acronyms-02) document.
I think the main audience for the short names is server administrators
too busy to read RFCs. Until I joined this group, I'd never seen
the terms "EE" and "TA" and had only a vague notion of what "PKIX"
was about. Rather, I had a decent working knowledge of root,
intermediate and leaf certificates and public keys.
So if I rewind the clock back 8 months, to where I knew nothing
about DANE and was not steeped in related IETF TLS slang, I would
note that none of the components of the proposed acronyms will
connect to concepts familar to system administrators deploying
DANE.
To make the acronyms less confusing than the numbers, we need to
use words people already understand:
0 - LIMIT-ISSUER
1 - LIMIT-LEAF
2 - TRUST-CA
3 - FIXED-LEAF
These are I think not only more clear, but use more familiar terms.
The first two limit (or constrain) the chain to have an acceptable
issuer or leaf certificate. The last two specify a trusted CA or
a fixed leaf certificate that are sufficient to verify the chain.
> We don't need these names / acronyms to be perfect, simply clearer
> / easier to remember than the ordinals.
>
> Any (strong) objections?
Returning to the origin acronyms, I for one still prefer PKIX-CA
to PKIX-TA, but I won't change my code to do the wrong thing should
the final name be misleading. I can't make a similar assurance
about server administrators provisioning TLSA recrods.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
