Re: [pkcs11] Proposal: CKM_ECDSA_FIPS_186_4

[Michael StJohns <msj@nthpermutation.com>]

Same set of objections.  If the module is in FIPS mode it has to behave this way, otherwise it doesn't necessarily.

The only way this would make sense is if you wanted to be able to use both CKM_ECDSA and CKM_ECDSA_FIPS_186_4 in the same mode.  In FIPS mode, you couldn't use CKM_ECDSA (unless it behaved like the FIPS version), in non-FIPS mode, you could use either for FIPS curves.

Also, for a while there NIST was prohibiting raw or component signatures in FIPS 140-2 mode.  So CKM_ECDSA_FIPS_186_4 would actually need to be the complete family of SHA2 signature functions.

CKM_ECDSA_FIPS_SHA224, CKM_ECDSA_FIPS_SHA256, etc.

That seems to have eased, but it is possible that big iron versions (e.g. NOT smart cards) will require complete signatures rather than permitting separate computations of hash and signature.  Unclear at this point.

I'd vote yes to add CKM_ECDSA_SHA224, _SHA256, SHA384, _SHA512 and the other variants, but I probably would vote no on this current proposal due to the above comments.

Mike





On 7/31/2013 5:18 PM, Oscar K So Jr. wrote:

Proposal: CKM_ECDSA_FIPS_186_4

FIPS-186-4 algorithms:
http://www.ofr.gov/OFRUpload/OFRData/2013-17396_PI.pdf

This mechanism is equivalent to: CKM_ECDSA

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php