client certs (yes/no/how)

[icing]

Lets develop some understanding if, and if yes how we want client certificates to work in crustls and the basic methods/struct that we want to have for it.

Looking at what rustls and webpki offer here, there are 2 areas where functionality seems to be lacking:

1. access to certificate details, to identify the cert (subject/email)
2. revocations checks

Point 2 is the hairy one, I guess. Without it, any client certificate authentication seems to be pointless and dangerous. rustls uses webpki's cert.verify_is_valid_tls_client_cert() and that checks the trust chain signatures only. So, there would need to be some mechanism to let the application do revocation checks on a signature-checked certificate chain (the intermediaries might need checking as well).

As an application example: mod_tls would not want to implement parsing and evaluating CLRs, I guess. OCSP could be added by extending mod_md for this, but this is not trivial.

Do we want to do this?

[djc]

I'll link a relevant webpki issue again here: Support client certificates that identify a person, not a server.

[jsha]

I'm in favor of crustls implementing client certificates to the extent that rustls does. But if there's work still to be done on the rustls side to make them reach the functionality that people are likely to need, let's hold off on the crustls implementation since the APIs are likely to change.

[icing]

To document the state of the discussion:

Support for client certificates in server side TLS depends on the availability of a revocation mechanism. To make that work for a rustls-ffi server application, one would need:

• access to fields/extensions in a certificate
• the issuer chain that was used to verify trust in a client certificate (needed to construct an OCSP query)
• a CRL parsing + evaluation function, since common deployments use this for client certificates.

Offering client certificates without these mechanisms would result in poor security.