On Sat, Mar 02, 2013 at 10:05:57PM +0200, Ilari Liusvaara wrote:
> 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:
> >
> > > 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.
I honestly have no idea what you mean, but it sure seems that you
are talking about trust chain validation, where-as the question in
this thread is about the necessity (or lack there-of) of checking
the certificate name (subjectAltName or CN).
The certificate is in this context already presumed trusted by some
means (whether DANE EE or TA, trust assertion or constraint), the
question that remains to be settled is whether the server certificate
is the *right* certificate or an unrelated trusted certificate.
I posit that with certificate usage 1/3 this question is moot, the
DANE EE data is sufficient to bind the certificate to the service,
and no name checks should be required.
The text in 6698 is perhaps ambiguous on this point, and the text
in draft-srv seems to suggest a contrary interpretation that I
believe needs to be corrected.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
