Re: [TLS] Review of PR #209

[Andrei Popov <[e-mail]>]

> 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:[e-mail]] 
Sent: Wednesday, September 16, 2015 11:25 AM
To: Martin Thomson <[e-mail]>
Cc: Andrei Popov <[e-mail]>; [e-mail]
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 
> <[e-mail]> 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