TLS Client Auth

[Andrei-Popov]

Based on the TLS1.3 client authentication discussion at the TLS WG meeting, this PR:

1. Allows the server to send CertificateRequest at any time after the handshake is complete.
2. Allows the server to narrow down the list of acceptable client certificates by optionally specifying a list of certificate extension OIDs with their allowed values.

[martinthomson]

NewSessionTicket needs to follow the client's Finished. For one, the client's CertificateVerify won't appear in every exchange.

[ekr]

I think we should at this point relax the rule and say you can generate a NewSessionTicket whenever.

[Andrei-Popov]

Yes, I’d be fine with relaxing the rule.

From: ekr [mailto:notifications@github.com]
Sent: Tuesday, August 18, 2015 8:07 AM
To: tlswg/tls13-spec tls13-spec@noreply.github.com
Cc: Andrei Popov Andrei.Popov@microsoft.com
Subject: Re: [tls13-spec] TLS Client Auth (#209)

In draft-ietf-tls-tls13.mdhttps://github.com//pull/209#discussion_r37309486:

@@ -3103,6 +3135,11 @@ it in the "pre_shared_key" extension in its ClientHello

({{pre-shared-key-extension}}) and supplying a suitable PSK cipher

suite.

+The server MAY also send a NewSessionTicket message after the handshake is

+complete, following the client CertificateVerify message. This allows the

I think we should at this point relax the rule and say you can generate a NewSessionTicket whenever.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/209/files#r37309486.

[ekr]

Closed so we can split into two.