Can you do a print out of such a cert with say:
openssl x509 -in whatever.pem -text -noout
?
And perhaps an ASN.1 dump:
openssl asn1parse -i -in whatever.pem
I am curious as to what this extension looks like. It is not in rfc5280
and wonder if it was ever published in an rfc (which is the common
practice when pushing a new extension for common use).
BTW, I worked in the IETF PKIX workgroup back in the day...
On 10/29/24 22:28, Paul Kehrer via Cryptography-dev wrote:
Is there a published spec that defines the ASN.1 syntax for these
extensions (maybe from BSI)? We generally like to have a specification
that we can use as a source of truth. For x509 I don’t have any
objection to adding this assuming a spec exists.
-Paul
On Oct 29, 2024, at 6:54 PM, Oleg Höfling via Cryptography-dev
<cryptography-dev@python.org> wrote:
Dear devs,
there is an X509 extension named `Admissions`, supported e.g. by
OpenSSL (https://docs.openssl.org/master/man3/ADMISSIONS/) and
BouncyCastle
(https://people.eecs.berkeley.edu/~jonah/bc/index.html?org/bouncycastle/asn1/isismtt/x509/AdmissionSyntax.html).
Would you be interested in `cryptography` supporting it as well? This
is an extension that is used in german public healthcare and legal
sectors, and I am working for one of them :-) I really enjoy working
with `cryptography` for reading out and persisting X509 certificates,
but dealing with the `Admissions` extension requires me adding extra
dependencies and writing extra code using other libraries I do not
enjoy this much.
If you agree that it could be a viable addition to the project, I
would gladly contribute the necessary bits myself. I made a
proof-of-concept implementation for the Admissions extension in my
fork of `cryptography` to have something to discuss:
https://github.com/pyca/cryptography/compare/main...hoefling:cryptography:admission-extension?expand=1
Example script that creates a certificate with an admission extension
that has some dummy values:
https://gist.github.com/hoefling/fa290eb33b24a2e5405cf9cdeeda03bc
Of course, this is far from the state where it can be reviewed,
should be split into smaller patches, is missing tests and docs etc etc.
If you reject the idea, I would try and put the code in a separate
library that depends on `cryptography` and connect them together
somehow. I would be grateful for any advices on that matter - maybe
you already had a case with a third party extension for
`cryptography` being built.
Last but not least - I really enjoyed hacking the working prototype
together and fiddling with the Rust backend, kudos for having such a
clear and concise API design!
Kind regards,
Oleg
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev@python.org
https://mail.python.org/mailman/listinfo/cryptography-dev
