-
Notifications
You must be signed in to change notification settings - Fork 65
Support RSA PKCS#1 signatures with absent parameters #346
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
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #346 +/- ##
=======================================
Coverage 97.91% 97.91%
=======================================
Files 20 20
Lines 4470 4470
=======================================
Hits 4377 4377
Misses 93 93 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
727e1fd
to
d8649d3
Compare
They're still |
They're in a non-pub Lines 91 to 104 in 0ac75b1
|
I thought we relied on |
They're pub API from this crate in the form of an impl SignatureVerificationAlgorithm, and you can get the value out via |
Oops, I was looking at tip-of-main |
RFC4055 says on sha256WithRSAEncryption and company: > When any of these four object identifiers appears within an > AlgorithmIdentifier, the parameters MUST be NULL. Implementations > MUST accept the parameters being absent as well as present. The latter clause is implemented in this commit. The algorithm identifiers live here rather than pki-types, as they _must not_ be used to originate new certificates. Putting them in pki-types would mean they appear in a public API, whereas here they are kept private and restricted to verifying existing signatures.
d8649d3
to
1178545
Compare
RFC4055 says on sha256WithRSAEncryption and company:
The latter clause is implemented in this commit.
The algorithm identifiers live here rather than pki-types, as they must not be used to originate new certificates. Putting them in pki-types would mean they appear in a public API, whereas here they are kept private and restricted to verifying existing signatures.
--
For ecosystem background, go entirely ignores parameters for these algorithms: https://cs.opensource.google/go/go/+/refs/tags/go1.24.3:src/crypto/x509/x509.go;l=425-431 (which is strictly weaker than the RFC requires; go would seemingly be happy if the parameters were a UTF8STRING containing the complete works of Shakespeare.)
re rustls/rustls#2448