On 24/02/17 04:52, Peter Bowen via Public wrote:
<snip>
Ryan,
I wasn’t aware that NIST had allocated identifiers for RSA using PKCS#1
v1.5 over SHA3 hashes. Given that this exists, that strikes out that issue.
I wasn't aware of these OIDs either. Thanks for the heads up!
However...
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
...that NIST page says nothing about the "parameters" field. For
RSA/SHA-3 and ECDSA/SHA-3 signatures, should the "parameters" field be...
1) omitted?
2) NULL?
3) some other value?
4) any value permitted (and ignored)?
There are a number of HSMs out there suitable for key protection for
this case already — almost every HSM I know about implements
the CKM_RSA_PKCS mechanism which allows signing arbitrary data. It
doesn’t care if it is a SHA-1, SHA-256, or SHA3-256 hash.
Indeed. Generating the hash of the TBSCertificate does not need to be
done inside an HSM. We (Comodo) only use HSMs to protect the CA private
keys and to perform the CKM_RSA_PKCS and CKM_ECDSA mechanisms.
Plugging in a software implementation of SHA-3 isn't yet as easy as I
want it to be - that is, OpenSSL doesn't support SHA-3 yet (see
https://github.com/openssl/openssl/issues/439).
All that is preventing the use of id-rsassa-pkcs1-v1_5-with-sha3-256,
id-rsassa-pkcs1-v1_5-with-sha3-384,
and id-rsassa-pkcs1-v1_5-with-sha3-512 is (1) the BRs and (2) lack
of implantation by browsers. When is Chrome planning to support these
algorithms?
Thanks,
Peter
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
