On Wed, Feb 12, 2014 at 10:32:03AM -0700, Matt Miller wrote:
> > DANE-EE(3) CU records need to have meaningful semantics for the
> > publisher. For example for a publisher to use the same
> > certificate for many SRV hosts or without worrying about using a
> > matching name, the use of non-use of name checks must be specified
> > precisely.
> > Therefore I would suggest that the "MAY be ignored" in the second
> > paragraph of section 5, should be changed to "MUST be ignored".
> > Otherwise, the published TLSA records have unknown semantics.
>
> 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, ...).
There will be some overlap between the SRV draft and the SMTP draft.
I expect that's not a problem, provided they agree.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
