On Wed, Feb 12, 2014 at 01:39:18PM -0700, Matt Miller wrote:
> >> Thank you for the feedback, Viktor. These comments make sense to
> >> me. We'll try to get an update out before the cutoff to address
> >> them.
> >
> > Thanks. You could mention that both name checks and key usage are
> > effectively handled by the TLSA record for DANE-EE(3). The TLSA
> > record binds the certificate or public key to the requested port
> > and protocol at the TLSA base domain, the binding is clearly for a
> > TLS server, so there is an implicit key usage of TLS server.
> > Finally, the RRSIG expiration date sets the expiration time of the
> > TLSA "pseudo-certificate". A requirement to ignore the
> > certificate content gives the publisher flexibility (e.g. same
> > certificate for multiple SRV hosts, ...).
> >
>
> Section 5 (after I change the "MAY" to a "MUST") already states that
> matching a DANE-EE(3) TLSA bypasses the rest of the certificate checks
> (paragraph 2), but the current wording might be too clumsy. I'll see
> what I can wordsmith to make it more explicit.
It is only a question of how much you feel it is appropriate to
provide a rationale for this requirement and in how much detail
you want to provide it.
> I could also add something about the RRSIG expiration, but isn't that
> already covered by RFC4035 ? 5.3.1 (bullet 5)?
I don't know that RFC 4035 specifically talks about imputing a TLS
server key expiration time from a DNS RRSIG expiration time, but
per the above comment, it is largely a question of whether you want
to explain why it is OK to ignore the "3 X Y" certificate content
and get everything you need from DNSSEC.
--
Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
