On 12/10/13 22:13, Richard Barnes wrote: > I'm a little confused, since I see a message from Warren on 6 Dec saying > that the call would be extended until tomorrow. I admit that I have not > been following this discussion closely, though. > > In case the window for comments / proposals is still open, my only > insight here is that usages 0/1 are very much like the "pinning" work > being done in draft-ietf-websec-key-pinning, so it might be helpful to > re-use that term here. For 2/3, it seems like people I've talked to > understand the verbs "assert" (since that's what the domain holder is > doing) or "trust" (since that's what the recipient is being asked to do). > > 0 - PIN-CA > 1 - PIN-EE > 2 - ASSERT-CA or TRUST-CA > 3 - ASSERT-EE or TRUST-EE > > So that's my favorite color for the bike shed.
To add my own color: DANE can only specify *intent*. Intent of the domain owner what they choose for their certificate source. Without *verification* that intent is worthless. 1. The owner of the domain must regularly validate that their chosen DNS-registrar still publishes the owners' intent, preferably with something like Perspectives that registers and remembers historic measurements. 2. People doing a lookup for the current value of TLSA records should validate these against the Perspectives history. When it matches, it's OK. When there is a mismatch, there is a problem. The only solution for the resolver is to fail fast and for the user to twitter about it. Make it public and let the community resolve the problem. It could be lousy DNS-registrar, the domain owner looks for a better one. It could be a MitM-device, the end user learns of its existence. In short, without *verification* DANE doesn't do so much. With verification, it's a big leap ahead. CT protects in the 0/1 cases, Perspectives in the 2/3 cases. IMHO, the naming should reflect the source of the certificate: 0: Global trusted CA; 1: End certificate in a chain from a Global trusted CA; 2: My own CA; ( from the perspective of the domain owner) 3: My own Certificate; (same perspective) Cheers, Guido.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
