On 10/02/2019 02:55, Corey Bonnell wrote: > Hello, > Section 5.1 of the Mozilla Root Store Policy > (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > specifies the allowed set of key and signature algorithms for roots and > certificates that chain to roots in the Mozilla Root Store. Specifically, the > following hash algorithms and ECDSA hash/curve pairs are allowed: > > • Digest algorithms: SHA-1 (see below), SHA-256, SHA-384, or SHA-512. > • P‐256 with SHA-256 > • P‐384 with SHA-384 > > Given this, if an End-Entity certificate were signed using a subordinate CA’s > P-384 key with ecdsa-with-SHA512 as the signature algorithm (which would be > reflected in the End-Entity certificate's signatureAlgorithm field), would > this violate Mozilla policy? As I understand it, an ECDSA signing operation > with a P-384 key using SHA-512 would be equivalent to using SHA-384 (due to > the truncation that occurs), so I am unsure if this would violate the > specification above (although the signatureAlgorithm field value would be > misleading). I believe the same situation exists if a P-256 key is used for a > signing operation with SHA-384. > > Any insight into whether this is allowed or prohibited would be appreciated. >
Using the same DSA or ECDSA key with more than one hash algorithm violates the cryptographic design of DSA/ECDSA, because those don't include a hash identifier into the signature calculation. It's insecure to even accept such signatures, as it would make the signature checking code vulnerable to 2nd pre-image attacks on the hash algorithm not used by the actual signer to generate signatures. It would also be vulnerable to cross-hash pre-image attacks that are otherwise not considered weaknesses in the hash algorithms. Furthermore the FIPS essentially (if not explicitly) require using a shortened 384-bit variant of SHA-512 as input to P-384 ECDSA, and the only approved such shortened version is, in fact, SHA-384. Using the same P-384 ECDSA key pair with both SHA-384 and SHA-3-384 might be within some readings of the FIPS, but would still be vulnerable to the issue above (imagine a pre-image weakness being found in either hash algorithm, all signatures with such a key would then become suspect). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
