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 <watsonbl...@gmail.com> wrote: > On Mon, Jul 11, 2016 at 7:27 AM, Sean Turner <s...@sn3rd.com> 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
