Implement PKCS#11 3.0 MessageSign API #270
Conversation
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
Signed-off-by: Jakub Jelen <jjelen@redhat.com>
| @@ -1,6 +1,6 @@ | |||
| // Copyright 2025 Contributors to the Parsec project. | |||
| // SPDX-License-Identifier: Apache-2.0 | |||
| //! Encrypting data | |||
| //! Decrypting messages | |||
There was a problem hiding this comment.
Sorry, did not write it right the first time :)
| use cryptoki_sys::*; | ||
| use std::convert::TryInto; | ||
|
|
||
| impl Session { |
There was a problem hiding this comment.
Could we re-organize the methods here to split single-part and multi-part?
There was a problem hiding this comment.
I was starting from the sign/verify API, which was in a single file. The semantics is also interleaved as we need to initialize the operation first and then call either one-shot or multipart operations, which really does not make a good split as for both of the ways, we need the operation initialization.
No. This is PKCS#11 3.0 API, which is not present in SoftHSM.
I hope we will get some implementation in kryoptic in foreseeable future, but we got stuck with the oasis-tcs/pkcs11#16 as it is not clear to neither of us what mechanisms should this API be usable with and in what semantics. I will probably change it back to draft for now. To be able to write some tests, we will need some new parameters and some mechanisms to use with this API. Adding unusable API makes no sense. |
|
For the record (until I will forget), I discussed today with Bob why these functions are in the PKCS#11 specs and if there is some use case or mechanism that could use them and there really is not so it really does not make sense to implement them (too late!). That said, I do not think this should be merged before we will have some use case. So keeping as a draft now, but I am also ok with closing it. I will just pull the fix in the decryption header to separate PR. |
This is separated from #264 as it really does not depends on the 3.2 API.
Currently, this API is not implemented by any of the software tokens we have this tracked for kryoptic in latchset/kryoptic#74 but given that this really does not add new functionality, it is still quite a low priority.
For that reason, I do not have any test coverage there (but our understanding is that we should be able to use this API with existing mechanisms, just without passing any parameters to the
sign_message_begin(), which would make it more handy to have the possibility to pass theparamoptional (or just defineMessageParam::None. Thoughts?