Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: allow EndEntityCert to verity different kind of TLS certs #254

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

flavio
Copy link

@flavio flavio commented Feb 8, 2022

This is a draft PR, I'm looking for feedback about it.

What is this PR solving

I'm currently working on Rust bindings for Sigstore.

In this scenario I have a CA issuing certificates that can be used to perform Sigstore-related operations. These certificates do not have the extended key attributes of Server/Client auth. Let's call them "signing certificates".

Given one of these "signing certificate", I need to verify it against a set of CAs (and eventually intermediate certs).

It looks like EndEntityCert can help me, thanks to its verify_is_valid... methods.

Unfortunately, given my "signing certificates" do not have neither the EKU_SERVER_AUTH nor the EKU_CLIENT_AUTH, all the currently available verification method fail.

What is PR introducing

This PR defines a new method inside of EndEntityCert that can be used to verify a certificate using custom extended key usages. The API takes a bit of inspiration from the one offered by Go's standard library crypto/x509/Certificate.Verify.

Most important of all, this method is just a tiny wrapper over the methods already defined inside of the crate.

Open questions

If we really want to go ahead with this new method, it would probably make sense to allow users to define custom KeyPurposeId objects.
If that's the case, I wonder what could be the UX for that. Eventually it would also possible to leverage the const-oid crate... 🤔

Closing thoughts

I would really appreciate to have this functionality (or something you think would be better suited) to be offered by this crate.

I searched a lot, but I couldn't find any other crate able to satisfy this use case (not with a community, popularity, usage, maintenance level comparable to webpki).

Thanks for this awesome crate!

Do not limit verification only to certificates that have either the
Server/Client Auth extended key usages.

Signed-off-by: Flavio Castelli <[email protected]>
@flavio
Copy link
Author

flavio commented Feb 10, 2022

ping @briansmith - sorry about the direct notification, can you provide some feedback please? 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant