Thanks Corey and Jakob, I opened a bug for this: https://bugzilla.mozilla.org/show_bug.cgi?id=1527423
Corey, did you report this via DigiCert's problem reporting mechanism? Thanks, Wayne On Mon, Feb 11, 2019 at 8:01 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
