Open icing opened 3 years ago
I'll link a relevant webpki issue again here: Support client certificates that identify a person, not a server.
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.
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:
Offering client certificates without these mechanisms would result in poor security.
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
andwebpki
offer here, there are 2 areas where functionality seems to be lacking:Point 2 is the hairy one, I guess. Without it, any client certificate authentication seems to be pointless and dangerous.
rustls
useswebpki
'scert.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 extendingmod_md
for this, but this is not trivial.Do we want to do this?