WIP: allow EndEntityCert to verity different kind of TLS certs
#254
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Do not limit verification only to certificates that have either the Server/Client Auth extended key usages. Signed-off-by: Flavio Castelli <[email protected]>
|
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
EndEntityCertcan help me, thanks to itsverify_is_valid...methods.Unfortunately, given my "signing certificates" do not have neither the
EKU_SERVER_AUTHnor theEKU_CLIENT_AUTH, all the currently available verification method fail.What is PR introducing
This PR defines a new method inside of
EndEntityCertthat 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 librarycrypto/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
KeyPurposeIdobjects.If that's the case, I wonder what could be the UX for that. Eventually it would also possible to leverage the
const-oidcrate... 🤔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!