Signature verification pre-"release"

[ionut-arm]

One of the main uses for the Parsec service is signature generation and verification. When it comes to generation, we normally perform a series of checks on the inputs to the operation, perform the signature, and send it back to the client if successful. However, another type of check that we could perform would be a post-signing, pre-"release" (i.e., release of the signature to the client): simply verify the signature using the public part of the key that was just used to sign. For example, this step is suggested in FIPS 186-4 as "signatory may optionally verify the digital signature using the signature verification process and the associated public key".

This verification step can be added conditionally (through a configuration). An issue may exist in PKCS11 if the token does not support public key operations - this new configuration option cannot be independent of the one switching on software public-key ops.

[tarcieri]

FWIW the notion of signature "middleware" is something we've previously discussed adding to the RustCrypto signature crate.

I can't find a specific tracking issue for this, although somewhere I have a rough implementation in a local branch.

The pattern I was implementing was roughly modeled after tower::Service (sans Futures), where a caller calls a generic "next" middleware in a pipeline, handling the return value from the call to the next middleware with middleware-specific logic.

[ionut-arm]

Thank you for the idea and insight! It would, indeed, make more sense to make this a middleware over the Parsec providers instead of implementing it in each one individually. I was thinking we could defer the verification to the client libraries, but it seems more consistent with the Parsec value proposition to do it at service level (instead of asking for each client library to implement it).

If we do go ahead and add this feature, we could always perform the tests in software (by using some implementation underneath signature, for example) - my only worry there is in packaging the service for some distros like Fedora, where non-FIPS-certified implementations are a no-no. I guess we could have a Cargo feature to remove this check for those distros. Funny how that requirement could end up resulting in worse security... :)