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

UnrecognizedExtension: APIs for (basic) DER unpacking #9283

Open
woodruffw opened this issue Jul 24, 2023 · 6 comments
Open

UnrecognizedExtension: APIs for (basic) DER unpacking #9283

woodruffw opened this issue Jul 24, 2023 · 6 comments

Comments

@woodruffw
Copy link
Contributor

Opening to gather interest/appetite before I send a patch.

Background

Sigstore generates and uses X.509v3 certificates that contain custom extensions; these custom extensions contain values that are (generally) encoded as UTF8Strings. It would be nice to be able to consume these extension values directly via Cryptography's APIs, without having to use pyasn1 or another dependency to unpeel the DER encoding on the extension values.

Status quo

At the moment, UnrecognizedExtension provides value as a raw view into the (usually) DER-encoded extension value.

Proposal

Add some APIs for common (primitive) extension value retrievals: UTF8String is the main one I'm personally interested in, but there are probably a few others that would be generally useful (UTCTime, GeneralizedTime, IA5String, etc.).

My first thought was to have these as value_as_X APIs, e.g.:

# property: str
ext.value_as_utf8string

...but that's pretty ugly.

Alternatives considered

  • Support the Sigstore extension types directly in Cryptography? I'm not sure if this is of interest to you as an upstream.
  • Do this in a third-party library that re-uses rust-asn1. I'll probably do this if neither of the above ideas is appealing to you.
@reaperhulk
Copy link
Member

We’ve had some past discussions about exposing the imperative DER API for consumers. I’m generally positive on that effort (as it’d remove another reason to use pyopenssl and/or pyasn1). I think that hypothetical API would cover this reasonably well too?

@woodruffw
Copy link
Contributor Author

We’ve had some past discussions about exposing the imperative DER API for consumers. I’m generally positive on that effort (as it’d remove another reason to use pyopenssl and/or pyasn1). I think that hypothetical API would cover this reasonably well too?

Yep, I think it would!

@alex
Copy link
Member

alex commented Jul 26, 2023

There'll be a substantial design effort involved in figuring out a public DER API, but it can be done.

@Nothing4You
Copy link

just leaving OtherName here as search keyword

@reaperhulk
Copy link
Member

@woodruffw are you still interested in this? 😄

@woodruffw
Copy link
Contributor Author

@woodruffw are you still interested in this? 😄

I am, but it's pretty far down on the priority set at the moment (I still need it for sigstore-python, but it won't become an urgent need until they deprecate the previous thing I rely on) 😅

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

No branches or pull requests

4 participants