OpenSSL determines which certificate to use during ClientHello processing, but it has a mode where, if intermediates were not explicitly configured and only a leaf, it path-builds right before sending the Certificate message. But I don't see any reason why it can't be changed to compute this earlier.
In general, we already require one know the certificate chain before sending ServerHello. The cipher suite depends on the leaf key type, so that must be selected already. If there are SCTs to deliver for any intermediates, the server must know which intermediates will be sent. If one wishes to consider intermediates' signature algorithms when selecting a leaf, they must be known too. If there are are other reasons we'd want to allow sending either hash or contents (Caching a long-lived intermediate but sending a new short-lived leaf? Looks like it's all-or-nothing right now. I dunno, I haven't been paying attention to cached-info yet and assume this is well-trodden ground by now.), the length still should not be a distinguisher. If needed, negotiating the extension can tweak the syntax of Certificate message or something. David On Mon, Jul 11, 2016 at 11:35 AM Eric Rescorla <e...@rtfm.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
