On Wed, Sep 16, 2015 at 10:48:27AM -0700, Martin Thomson wrote: > On 16 September 2015 at 08:30, Ilari Liusvaara > <ilari.liusva...@elisanet.fi> wrote: > > Problem with pulling client auth out of the handshake is that it > > complicates applications that can't change identities involved with > > active connection. > > Why would that be unsupported here? The server can still send > CertificateRequest immediately after its Finished. That looks exactly > like it does today, only the order has changed. > > > As then the application needs to ensure that the authentication > > occurs between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you > have no problem. I think that claim is reasonable, but I'm happy to > discuss it.
I think it is the attesting (even of present in-flight requests) that is the problem, not not attesting something. > > CertificateRequest contains the permitted signature algorithms > > for the PoP signature, which TLS library needs to verify before > > dumping the certificate chain on application (which can then > > figure out things like trust anchors). > > > > Without CertificateRequest, one has little idea what algorithms > > are acceptable there. > > Arguably, signature_algorithms covers that adequately. Though I'll > grant that certificate chain validation often happens in a separate > component to the TLS stuff. The extension? IIRC, that is what _client_ can verify. This is about what _server_ can verify. Or the equivalent of current field that specifies that? That's inside CertificateRequest, which would be optional. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
