Add PK_Signature_Options#5489
Conversation
4276d00 to
31f25d1
Compare
This allows controlling all details of how signatures are created, without having to stuff values into the single parameters string which was previously available.
31f25d1 to
384e804
Compare
| * currently supported. In a future release, if Ed25519ctx was supported, | ||
| * then this function would start returning true for Ed25519 keys. | ||
| */ | ||
| virtual bool supports_context_data() const; |
There was a problem hiding this comment.
Is it - from a principle point of view - really the key that supports the context parameter or is it rather the signature scheme? In the case of the currently affected signature schemes (EdDSA, ML-DSA, SLH-DSA, and ML-DSA-composite), that doesn't seem to make a difference, since they tie the key to specific signature scheme. However, you never know, if it might make a difference in the future...
| oss << padding << "(" << hash << ")"; | ||
| return oss.str(); | ||
| Botan::PK_Signature_Options sig_options( | ||
| std::string_view key, std::string_view padding, std::string_view hash, bool use_der, std::string_view provider) { |
There was a problem hiding this comment.
Using string arguments is not a good approach in my view. But maybe for now it is the simplest option. However, in the future, we can add a type framework for the parameters and start to define further constructors for the PK_Signature_Options.
|
I did not perform a full review yet. But regarding the general approach, I think it is a great improvement. The new signature options type is a good thing in my view because it facilitates signature options to some degree already and lays a foundation for future improvemets. Further improvements could be typed signature parameters and possibly even compile-time validation of the parameter specification in the future. |
| * .with_der_encoded_signature() | ||
| * .with_context("Foo") | ||
| */ | ||
| class BOTAN_PUBLIC_API(3, 6) PK_Signature_Options { |
There was a problem hiding this comment.
Probably 3.12 and maybe final.
| PK_Signature_Options(PK_Signature_Options&& other) = default; | ||
| PK_Signature_Options& operator=(PK_Signature_Options&& other) = default; | ||
|
|
||
| PK_Signature_Options(const PK_Signature_Options&) = default; | ||
| PK_Signature_Options& operator=(const PK_Signature_Options& other) = default; | ||
| ~PK_Signature_Options(); |
There was a problem hiding this comment.
Rule-of-zero? The d'tor is currently defaulted in the cpp file, but there's no real reason for that, as none of the members would actually require that AFAICS.
3 participants
This allows controlling all details of how signatures are created, without having to stuff values into the single parameters string which was previously available.
The PR previously known as #5021 #4318