[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:
> 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!


    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 

> 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