On 12/10/13 23:58, Viktor Dukhovni wrote: > On Tue, Dec 10, 2013 at 11:10:29PM +0100, Guido Witmond wrote: > >> DANE can only specify *intent*. Intent of the domain owner what they >> choose for their certificate source. > > The intent of the holder of the current zone signing key. > >> Without *verification* that intent is worthless. > > The intent is conveniently verified by an RRSIG generated by the > zone signing public key.
Which could be changed by a malicious Register. Ie. That's what needs to be verified by both the domain owner and the end user. > Arguing against the DANE security model has no bearing on the acronyms. I'm arguing to propose names that the matches the End Users' expectation. That might lead to some smart domain owners to consider how their TLSA-records are received. Can't protect against Stupid, regrettably. >> IMHO, the naming should reflect the source of the certificate: >> 0: Global trusted CA; > > Except that the record value is not a global trusted CA. Rather > its value is a CA constraint on the chain from some trusted CA > requiring the presence of some intermediate at or below such a CA. > > 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? >> 1: End certificate in a chain from a Global trusted CA; > > Sure. But I don't see an acronym here... > >> 2: My own CA; ( from the perspective of the domain owner) > > Your own trust-anchor. > >> 3: My own Certificate; (same perspective) > > Still no actual acronym. 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. Regards, Guido.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
