Support client certificates that identify a person, not a server

[briansmith]

Now we don't have an API that lets a TLS server validate a user client certificate. So, for example, if I try to authenticate to a website using my smartcard that contains a certificate for my own person, the server cannot validate the certificate if it uses webpki for certificate validation.

This would probably require much better GeneralName support in webpki.

[ghost]

Interesting! I didn't think this there was a big difference, At least in all cases I tested and where the certificates were X.509v3 it worked fine with the AllowAnyAuthenticatedClient from rustls. The only problem I ran into was when the client cert was X.509v1, which was supported by nginx and other servers using openssl, but not by my rustls server using webpki client certificate verification.

[briansmith]

Interesting! I didn't think this there was a big difference, At least in all cases I tested and where the certificates were X.509v3 it worked fine with the AllowAnyAuthenticatedClient from rustls. The only problem I ran into was when the client cert was X.509v1, which was supported by nginx and other servers using openssl, but not by my rustls server using webpki client certificate verification.

You are just assuming that anybody with a valid certificate is authorized. If you needed more fine-grained access control then you'd see that more stuff is missing.

It is probably true that V1 certificate support are probably needed for personal certificates.

[ghost]

Ah yes. After the cert is verified with webpki, I use the x509parser crate to obtain the email address etc. it is issued to. It would be really awesome if I could use webpki to do the same in one go.

[briansmith]

The first step of this would be addressing #219.

[jsha]

Why is v1 certificate support required for personal certificates? Is there common software or a popular CA that generate such certificates?

[ghost]

From my experience a modern openssl will give you v1 certificates unless you explicitly enable any extensions. But I still think the goals of supporting v1 certificates and extracting/matching on the subject info should be two seperate goals, even though both are especially interesting for user certificates.
In my use case it for example it would be useful to have either one without the other, since I control all user certificates used with my application.

[briansmith]

Why is v1 certificate support required for personal certificates? Is there common software or a popular CA that generate such certificates?

It is maybe not so much "required" but if Directory Names are being used for validation then the Subject of the certificate is a valid Directory Name and so no extensions would be necessary according to X.509 rules, as a missing EKU means "any EKU" and likewise for most other "missing" extensions.

Regardless, I intend to fix #219 very shortly now, before spending effort on this issue, so there's not much point in worrying about whether #219 strictly blocks this.

I expect #249, about providing a configuration API, will block this. Which forms of names to accept would be a new configuration parameter.