On Mon, Aug 24, 2015 at 09:56:50PM -0400, Paul Wouters wrote:
> >>Not having read the TLS 1.3 draft, in IKE parties can send a hash of the
> >>CAs they trust, so unless you receive a hash of a known CA to you, you
> >>can withold your own certificate from being sent.
> >>
> >>Is a similar mechanism not planned for TLS 1.3?
> >
> >This would break DANE, unless the mechanism also allowed the client
> >to send a TLSA RRset instead, with the server then needing code to
> >figure out which chains match which TLSA RRs. This is I think too
> >complex.
>
> If you publish your public key in DNS you would also just always
> send your public key over TLS. There is no privacy issue there,
> so no reason to withhold it.
Not sure how this comports with your original proposal. What would
a client have to send to convince the server to not withold its
certificate? What does witholding it mean anyway, the client needs
the public key at least if the server signs the key exchange. Is
there something here worth pursuing in the context of TLS?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
