On Wed, Dec 11, 2013 at 12:45:13AM +0100, Guido Witmond wrote:
> > The record should be named after what is specifies, which is a CA
> > required in your chain, not a trusted root. This was my objection
> > to the change from PKIX-CA to PKIX-TA. The change from PKIX-CA to
> > PKIX-TA is still wrong (even if I am willing to let it slide), as
> > it will perpetuate confusion by many people who don't understand
> > usage 0 or usage 2, but think they do.
>
> My misunderstanding. I believed it would specify my chosen CA for my
> domain, I understand it could be more specific than that: A certain
> subCA from that CA. Would it mean that that specific CA has *less*
> options to get coerced to issue a fake certificate for my domain?
[ EXACTLY. This is the misunderstanding I want to discourage by NOT
naming "0" DANE-TA, but that is exactly what is is NOT. My objection
to DANE-TA is looking stronger. Please REVERT it to DANE-CA, and
the draft can then move forward without reinforcing confusion. ]
Yes, one can exclude various reseller subordinate CAs, or other
intermediates issued by some trusted CA, and thus protect verifiers
of your domain for being fooled by certificates issued by unrelated
rogue intermediates. Provider your intermediate CA is not rogue,
you're safe(r).
> I left acronyms to those better able to decide. I just wanted to point
> out my ideas. Especially the idea to frame the acronyms in the mind-set
> of the end-user. Because I believe, that's the person we need to protect.
I agree. Thus my earlier posts suggesting we use name components
more familar to every-day users. This excludes "PKIX" (almost
nobody knows what that means), "TA" and "EE". The only proposed
name component that might mean something to people is "DANE" but
that applies to *all* the usages, they are all "DANE". So the
proposed names are somewhat memorable, but meaningless.
The following would be much better:
- LIMIT-ISSUING-AUTHORITY
- LIMIT-LEAF-ENTITY
- ASSERT-TRUSTED-ISSUER
- ASSERT-LEAF-ENTITY
but unless the author decides to propose a revision, perhaps we're
stuck with the broken names and any confusion they may entrench.
I encourage the author to boldly change the names if he has seen
any merit in my arguments. It is of course possible that I'm not
convincing anyone at all. That's fine, I have actual code to write
and test.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
