On Sat, Mar 02, 2013 at 06:20:39PM +0000, Viktor Dukhovni wrote:
> On Sat, Mar 02, 2013 at 10:53:39AM +0200, Ilari Liusvaara wrote:
> 
> > > However, I do believe that the same (subject name checking) policy
> > > should apply for both certificate usage "3" and "1".
> > 
> > I think you are mixing up usages 1 and 2 or something.
> 
> I am quite sure I am not.
> 
> In both usage 3 and usage 1 the TLSA RR specify the end-entity
> (leaf) certificate deployed on the server.  Once a particular
> certificate is explicitly bound to the server via a TLSA RR, there
> is no point in comparing the server name with the content of the
> certificate, we already have a binding and name checks can only
> fail with no security gain (snatch defeat from jaws of victory).
> One simple design rule I try to adhere to is: "don't fail when
> success is an option".

Ah, if one has universal RP trust anchor[1], then the path validation
rules simplify to:

-Usages 0/2: Validate up to DANE pin / trust anchor.
-Usages 1/3: Validate nothing.

[1] Eseentially meaning any certificate (or any CA certificate)
is treated as trust anchor.

-Ilari
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane

Reply via email to