[cabfpub] SHA-1 Collision Found
Rob Stradling
rob.stradling at comodo.com
Fri Feb 24 12:33:52 UTC 2017
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
More information about the Public
mailing list