I agree with Watson's assessment here. This seems like the wrong design choice.
I'm not familiar with OpenSSL's cert selection, but I don't believe that the issue that this change is intended to address applies to NSS, for two reasons: 1. NSS does cert selection during client hello processing [0]. http://searchfox.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#9569 2. Unless I misunderstand the design of cached-info, all the server needs to have is the digest of the serialized chain and it could store that at the time that it configures the cert (or first uses it). This seems like quite a small burden. I believe the prior design was superior. -Ekr On Mon, Jul 11, 2016 at 8:07 AM, Watson Ladd <[email protected]> wrote: > On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner <[email protected]> wrote: > > Hi, > > > > Just wanted to remind everybody that we’ve got two non-TLS1.3 items > we’re looking for WG input on: > > > > - Before 12 July, we’d like to know your thoughts about progressing > draft-ietf-tls-pwd (Watson and ekr responded): > > https://mailarchive.ietf.org/arch/msg/tls/WrNa7PXTZn2ZhfmoQDA_pnUVuN4 > > > > - Before 14 July, we’d like to know your thoughts on the proposed AUTH48 > proposed changes (nobody has commented on this): > > https://mailarchive.ietf.org/arch/msg/tls/aBvqMG7t8qkO5rPt-xaMHipuBVk > > I don't like the AUTH48 changes. I understand the need for changing to > MAY, but the proposed method of distinguishing offends my > sensibilities. Overloading the length field is just ugly. > > > > > spt > > _______________________________________________ > > TLS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
