On Tuesday, February 12, 2019 at 3:15:09 PM UTC-5, Wayne Thayer wrote: > 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 > >
I didn't report this issue to Digicert's problem reporting mechanism as I believe this is not a mis-issuance under the Baseline Requirements, but rather a violation specific to Mozilla Root Store Policy (section 6.1.5 of the Baseline Requirements does not mandate any curve/hash pairs). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
