Re: P-384 and ecdsa-with-SHA512: is it allowed?
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
Re: P-384 and ecdsa-with-SHA512: is it allowed?
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
Re: P-384 and ecdsa-with-SHA512: is it allowed?
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
Re: P-384 and ecdsa-with-SHA512: is it allowed?
On Sunday, February 10, 2019 at 6:33:19 AM UTC-5, Ryan Sleevi wrote: > On Sat, Feb 9, 2019 at 8:55 PM Corey Bonnell via dev-security-policy < > dev-security-policy@lists.mozilla.org> 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. > > > > Thanks, > > Corey > > > I don’t think you can read that policy, as written, and legitimately > interpret it as allowed. It’s literally not listed. > > > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > Thanks, Ryan, for weighing in. I suspected that such certificates would be prohibited but wanted confirmation. The motivation for my inquiry was that I discovered the following set of unexpired, unrevoked certificates which are signed with a P-384 sub-CA key using the ecdsa-with-SHA512 signature algorithm. Given that this hash/curve pair is not allowed, I believe that these certificates run afoul of Mozilla Root Store Policy: DigiCert crt.sh URL(s),notBefore,notAfter,issuer CN,issuer curve,sigAlg https://crt.sh/?id=252169572 (final),2017-11-08,2020-11-12,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=276033955 (precert); https://crt.sh/?id=498045339 (final),2017-12-11,2019-12-11,DigiCert ECC Extended Validation Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=323384439 (precert),2018-02-05,2019-02-20,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=323318776 (precert),2018-02-05,2019-02-20,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=354276341 (precert),2018-03-13,2020-03-20,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=358905399 (precert),2018-03-18,2019-05-22,DigiCert ECC Extended Validation Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=368911544 (precert),2018-03-28,2020-04-01,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=399193174 (precert); https://crt.sh/?id=402197763 (final),2018-04-16,2020-04-22,DigiCert ECC Extended Validation Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=399645531 (precert),2018-04-17,2020-04-22,DigiCert ECC Extended Validation Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402216416 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402398690 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402397877 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402398610 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402397769 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402398408 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402396037 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402397885 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402517328 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402217433 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402397974 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402217018 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server CA,P-384,ecdsa-with-SHA512 https://crt.sh/?id=402397004 (precert),2018-04-18,2020-03-26,DigiCert ECC Secure Server
Re: P-384 and ecdsa-with-SHA512: is it allowed?
On Sat, Feb 9, 2019 at 8:55 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> 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. > > Thanks, > Corey I don’t think you can read that policy, as written, and legitimately interpret it as allowed. It’s literally not listed. > ___ > 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
P-384 and ecdsa-with-SHA512: is it allowed?
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. Thanks, Corey ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
