Subject: [TLS] stapling OCSP/CT for client cert?

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Feb 2017 17:07:20 +0000

Any thoughts on being able to staple OCSP (or CT) data to a client cert once requested by the server?

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz

---

From: David Benjamin <[email-masked]>
Date: Wed, 22 Feb 2017 17:23:22 +0000

Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take
all of four characters to fix. See this table:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2

One of the nice things about using TLS-style extensions in
CertificateRequest is any ClientHello => (Server)Certificate extensions
naturally extend to CertificateRequest => (Client)Certificate extensions.

On Wed, Feb 22, 2017 at 12:13 PM Salz, Rich <[email-masked]> wrote:

Any thoughts on being able to staple OCSP (or CT) data to a client cert
once requested by the server?

--

Member, OpenSSL Dev Team

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Feb 2017 17:54:05 +0000

https://github.com/tlswg/tls13-spec/pull/880

I knew it was easy to fix, wasn’t sure if folks wanted it.  Gives me a reason to join the contributors list.
Very useful in peer-to-peer situations.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 22 Feb 2017 22:28:38 +0200

> naturally extend to CertificateRequest => (Client)Certificate extensions.

That got me to review the message assignments of extensions. I found
several problematic definitions:

1) Client_certificate_url (CH, EE):

This is related to client certificate, but it also has more
serious problem: It uses its own handshake type in way that
is seemingly ill-defined in context of TLS 1.3.

2) User_mapping (CH, EE):

This is pretty special in TLS 1.2, by being three-pass,
instead of the usual two-pass. It also has its own message
in TLS 1.2. How exactly is that supposed to work in TLS 1.3,
is the SupplementalData really supposed to become the first
message in client 2nd flight (that should be specified) or
is the message supposed to be chucked inside certificate
extension (which would need adding CT to message assignments
for the extension).

3) Cert_type (CH, EE):

This is related to either client or server certificate. However,
cert_type is older extension that was superceded by
client_certificate_type and server_certificate_type. Deprecate?

4) Client_certificate_type (CH, EE):

This extension is about client certificates, which would logically
imply assignment of CR, CT.

This comes rather important if there ever will be certificate type
that make sense to mix and match with X.509 certificates from client
context. E.g. Subcertificates implemented as certificate type.

-Ilari