Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

[Viktor Dukhovni <[e-mail]>]

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.