> 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. I don't necessarily buy Martin's argument that signature_algorithms covers this adequately. But I would argue that the application will only volunteer certs if it has out-of-band knowledge that client auth is required, and also knows exactly which cert is required. Otherwise, CertificateRequest should be used. Cheers, Andrei -----Original Message----- From: Ilari Liusvaara [mailto:ilari.liusva...@elisanet.fi] Sent: Wednesday, September 16, 2015 11:25 AM To: Martin Thomson <martin.thom...@gmail.com> Cc: Andrei Popov <andrei.po...@microsoft.com>; tls@ietf.org Subject: Re: [TLS] Review of PR #209 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
