On Tue, Jul 04, 2017 at 12:14:42PM -0400, Viktor Dukhovni wrote: > > > On Jul 4, 2017, at 11:33 AM, Shumon Huque <shu...@gmail.com> wrote: > > > > Yes, in fact the previous sentence to the one you quoted did say this more > > or less: " ... return a serialized authentication chain in the Certificate > > message associated with the end entity certificate being validated ". I > > would propose rewording that a bit and removing the last quoted sentence > > entirely: > > > > Servers receiving a "dnssec_chain" extension in the ClientHello, and > > which are capable of being authenticated via DANE, SHOULD return a > > serialized authentication chain in the extension block of the > > Certificate > > message containing the end entity certificate being validated, using the > > format described below. > > Why the end-entity certificate, and not the final certificate > sent by the server? With anything but DANE-EE(3) the TLSA > records can't be processed against the server's certificate > message until *all* the server certificates have been received.
Well, the optimal would be the certficiate record pertrains to. However, since RRsets are atomic, this is not possible. > So instead of squirreling away the DNS data while waiting for > all the server certificates to arrive, it may make more sense > to receive the TLSA records (and associated signatures, CNAMEs, > DNAMEs, ...) once all the server certificates have been received. > > Of course either way one still buffers all the server certificates, > so buffering the TLSA records is not a major issue. It's just that > I don't see a compelling argument for sending the TLSA records with > the EE certificate. Perhaps send them with any of the server > certificates, it probably makes no difference which... The entiere Certificate message should be loaded into memory anyway. And one definitely does not want to merge records. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
