On Wed, Jul 29, 2015 at 08:17:28AM -0700, Barry Leiba wrote:
> NEW
> DANE TLSA records validated by
> DNSSEC can be used to augment or replace the use of trusted public
> END
Thanks, done.
> NEW
> [RFC6698] defines three TLSA record fields, the first with 4 possible
> values, the second with 2, and the third with 3.
> END
Thanks, done.
> NEW
> When a server supports SNI but is not configured with a certificate
> chain that exactly matches the client's SNI extension, the server
> SHOULD respond with another certificate chain (a default or closest
> match). This is because clients might support more than one server
> name, but can only put a single name in the SNI extension.
> END
Thanks, done.
> -- Section 4 --
>
> Protocol designers need to carefully consider which set of DANE
> certificate usages to support.
>
> I'm not sure why this (and the next sentence) is referring to "protocol
> designers". Is this not aimed at implementation/deployment choices? If
> that's not correct, who are the targets for this advice?
This should likely say "application protocol designers". The point
being that the use of DANE TLSA RRs in a particular application
(as with e.g. SMTP) can be defined (more specifically than in
RFC6698 and this draft) by an application-specific standard.
> I also find this section to be rather hard to follow -- I can't clearly
> figure out what the advice really is. Can you do a little reorganization
> here, separating the advice out from the explanation of why? I don't
> care whether you put the explanation first or the advice first, but it
> would help to have one paragraph that says, clearly and without fuss,
> what the recommendation is. This applies to the subsections as well.
Will try to clarify, this will take more time. Should the two
smaller changes above be pushed as -15, while section 4 is polished?
--
Viktor.
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane
