Modify EMSA::config_for_x509 to no longer require a private key#3142
Modify EMSA::config_for_x509 to no longer require a private key#3142
Conversation
Codecov ReportBase: 88.02% // Head: 88.03% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## master #3142 +/- ##
==========================================
+ Coverage 88.02% 88.03% +0.01%
==========================================
Files 599 600 +1
Lines 66361 67077 +716
Branches 6611 6703 +92
==========================================
+ Hits 58411 59050 +639
- Misses 5170 5198 +28
- Partials 2780 2829 +49
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
Yes, I'm pretty sure it will help. Thanks. I'll look deeper into it next week. Frankly, this got swamped by the sessions. |
reneme
left a comment
There was a problem hiding this comment.
This works well for #3125. The only small caveat: The TLS code uses "SHA-1" as a hash function name. And the sanity check in EMSA::config_for_x509() compare it to the result of HashFunction::name() which comes back as "SHA-160". For now, I just mapped the string accordingly.
Let's look into that in #3125 once this is merged.
In EMSA1 we always now set parameters to empty since that is the convention for DSA, ECDSA, etc. Previously if some other algorithm (eg RSA) was used, the parameters would be set. However the
sig_algo_and_padding_okcheck already prevented one from using EMSA1 padding with RSA, so there is no change to functionality as a result.