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.

[cpu]

I believe the needed API surface has been added for client certificates and CRL based revocation. If there are specific needs outstanding I think it would be best to follow-up with more targeted issues.

access to fields/extensions in a certificate

This stands out as a place where there's likely room for improvement. In general I think both rustls and webpki have avoided exposing a great deal of certificate information. Making this viable for the -ffi bindings will likely require upstream work first, or accepting that a 3rd party solution would be needed to process the DER to extract required fields. I'd prefer to not start on that work until there's a documented use-case (outside of mod_tls, since it's now somewhat unmaintained).