"Certificate extension has incorrect criticality" error when verifying X.509 certificate used for timestamping #12124
Comments
|
The current behavior comes from the CABF requirement (https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.1.1.pdf) which is the primary profile we have implemented. @woodruffw what do you think -- should we loosen the default handling, or is this better handled by #11800? |
Hmm, I think this could go either way: based on the x509-limbo results, checking for a non-critical EKU is not widely done. So IMO there would be no harm in relaxing this criticality check. More generally however, I'd be surprised if the current validator APIs work at all with RFC 3161 certs -- this is likely just the first thing to fail. Validating TSRs more generally will probably fail, since a lot of TSAs have wildly non-compliant X.509 setups 🙂 @kislyuk you might want to check out https://github.com/trailofbits/rfc3161-client -- that's a full-fledged RFC 3161 client implementation, including TSR validation. It uses the PyCA Cryptography Rust APIs under the hood, although it currently still depends on OpenSSL (via Rust bindings) for the chain building part because of the path validation API limitations mentioned above. |
|
Ah, that's a good point. It suggests the right path is really the
profiles API.
…On Sun, Dec 8, 2024 at 7:22 PM William Woodruff ***@***.***> wrote:
@woodruffw <https://github.com/woodruffw> what do you think -- should we
loosen the default handling, or is this better handled by #11800
<#11800>?
Hmm, I think this could go either way: based on the x509-limbo results
<https://x509-limbo.com/testcases/webpki/#webpkiekuee-critical-eku>,
checking for a non-critical EKU is not widely done. So IMO there would be
no harm in relaxing this criticality check.
More generally however, I'd be surprised if the current validator APIs
work at all with RFC 3161 certs -- this is likely just the first thing to
fail. Validating TSRs more generally will probably fail, since a lot of
TSAs have wildly non-compliant X.509 setups 🙂
@kislyuk <https://github.com/kislyuk> you might want to check out
https://github.com/trailofbits/rfc3161-client -- that's a full-fledged
RFC 3161 client implementation, including TSR validation. It uses the PyCA
Cryptography Rust APIs under the hood, although it currently still depends
on OpenSSL (via Rust bindings) for the chain building part because of the
path validation API limitations mentioned above.
—
Reply to this email directly, view it on GitHub
<#12124 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAAGBCDBBLTKUQOFJSAOT32ETPDBAVCNFSM6AAAAABTHWM232VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMRWGUZTQNRRHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
--
All that is necessary for evil to succeed is for good people to do nothing.
|
|
Thanks, where can I find more details on the profiles API? @woodruffw thanks for the link to the Trail of Bits RFC3161 client, that looks very relevant. It does carry the warning "This project is an alpha version and should not be used in production." which is fine but the reason I'm asking is that I'm the maintainer of https://github.com/pyauth/tsp-client - another RFC3161 implementation - which does have some production users and has been relying on the validation routines in PyOpenSSL, which have now been deprecated and removed. I certainly stand to learn from your efforts in https://github.com/trailofbits/rfc3161-client, but more generally, I think it would be very useful if Cryptography could provide an opinionated but configurable API with tightly controlled defaults but with the ability to adjust them, now that direct access has been removed in PyOpenSSL. Would the profiles API help with that?
This (or the ability to configure this) would allow me to proceed past the current error - I would really appreciate this change. Aside from extension policy handling, I do have the rest of TSR validation working in a standalone manner, so I don't expect further issues although I haven't been able to check yet. |
I think @alex is referring to #11165 et al., which is currently informing the implementation of new APIs for configuring extension policies.
We need to tweak that warning 😅 -- it's in production now, although we won't consider the APIs themselves stable until we do a 1.0 release. @DarkaMaul mind opening a PR on rfc3161-client to mark this as beta instead of alpha + update the classifiers as necessary?
Understood! I'll take a look at making these changes to the verifier tonight or tomorrow. |
|
Please guys, I have a problem if anyone can help! I'm working on a certificate project on Python with the cryptography library, but for some reason, when I install it, the module x509 is missing. I tried virtual environment, upgrading Python, and upgrading the library, but the problem still persists. |
|
Your comment has nothing to do with this issue. If you need help, please file a separate issue with sufficient details. |
I am trying to use Cryptography to verify X.509 certificates used for TSP (RFC 3161) timestamping. This functionality is now particularly in demand since access to the OpenSSL verification routines has been removed from pyOpenSSL.
The following certificate is distributed by DigiCert with TSP signatures:
When attempting to verify this cert with Cryptography, I always get the following error:
How can I use Cryptography to verify TSP certificates?
The text was updated successfully, but these errors were encountered: