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

[Ilari Liusvaara <[e-mail]>]

On Wed, Feb 22, 2017 at 05:23:22PM +0000, David Benjamin wrote:
> 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.

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