Re: [pkcs11] Groups - Post Quantum Signatures Multipart solution 2 uploaded

[Robert Relyea <rrelyea@redhat.com>]

On 5/4/23 10:36 AM, Robert Relyea wrote:

>       
>       Submitter's message
>       The second option is to create a new C_VerifySignatureInit which
>       includes the signature. If we add this function, I've suggested
>       that all Mechanisms that support C_VerifyInit also support
>       C_VerifySignatureInit(). The only difference is when the signature
>       is supplied.
>

The advantage of this proposal is the C_VerifySignatureInit() is more general (mechanisms that don't need the signature initially can still support this. It could even be an advantage to RSA multipart operations where we can fail C_VerifySignatureInit() immediately when the signature doesn't match the mechanism (you can decrypt the RSA block and verify that the hashes match the hash in the mechanism, for instance).

Adding just C_VerifySignatureInit is simple, but generates some of the same issues as the mechanism parameter of option 1:

>       
>       This one comes with some suboptions: how do we handle that the
>       signature is passed to C_VerifySignatureInit() and C_Verify() and
>       C_VerifyFinal().
>       
>       We can ignore the one passed in C_Verify/C_VerifyFinal.
>     
    This is probably the simplest to implement, but could be confusing
    to the application writer that doesn't read the spec clearly.
>       We can require the one passed in C_Verify/C_VerifyFinal to be
>       NULL.
>     
    This one basically immitates supplying the full set of
    C_VerifySignature functions. If we just adopt C_VerifySignature,
    this is the option that makes the most sense to me.
>       We can require the one passed in C_Verify/C_VerifyFinal to match
>       the signature passed in C_VerifySignatureInit (with and without
>       enforcement)
>     
    This one matches the proposed optimal solution in option 1. The
    without enforcement case puts the least pressure on tokens, but
    could lead to weird, undetected errors in the application.
>       We must be explicit on this semantic in the spec.
>       
>       We have the same options in the previous case, but in that case
>       the signature is a mechanism parameter, so it's more of a side
>       thing.
>       
>       We could also make a full set:
>       C_VerifySignatureInit(), C_VerifySignatureUpdate,
>       C_VerifySignature() and C_VerifySignatureFinal(). In that case the
>       latter 2 would not take signatures, bypassing the whole thing
>     
    This one may just be the cleanest operation, at the cost of a lot
    more functions. In this case if we adopt both option 1 and option 2,
    option 1 is free to have it's own signature matching semantic.

Note: we can adopt both option 1 (mechanism parameters) and option 2 (C_VerifySignatureInit). In that case we should make sure handling of the two sources of signatures is the same.
-- Mr. Robert Relyea

Document Name: Post Quantum Signatures Multipart solution 2

---

Description
Add a new C_VerifySignatureInit() function which includes the signature.
Download Latest Revision
Public Download Link

---

Submitter: Mr. Robert Relyea
Group: OASIS PKCS 11 TC
Folder: Working Drafts
Date submitted: 2023-05-04 10:36:11