Re: P-521 Certificates
On Tuesday, January 8, 2019 at 3:12:26 PM UTC-5, Wayne Thayer wrote: > Thanks Corey, Ryan, and Jonathan. > > In one of the bugs that Ryan created, the CA stated that it's not clear if > or when Mozilla requires revocation of these P-521 certificates. I believe > the answer is that we do not require revocation. Our policy (section 6) > explicitly requires CAs to abide by the BR revocation rules (section > 4.9.1.1), but these certificates do not meet any of those requirements. > > - Wayne > > On Tue, Jan 8, 2019 at 11:30 AM Jonathan Rudenberg via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: > > > (Posting in a personal capacity as I am no longer employed by Trustwave) > > > > > > Mozilla Root Store Policy section 5.1 > > > ( > > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > > > > > prohibits the use of P-521 keys in root certificates included in the > > > Mozilla trust store, as well as in any certificates chaining to these > > > roots. This prohibition was made very clear in the discussion on this > > > list in 2017 at > > > > > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC8/fsKobHABAwAJ. > > > > > > > > Below is a list of unexpired, unrevoked certificates which contain P-521 > > > public keys (grouped by CA Owner and ordered by notBefore): > > > > I've created https://misissued.com/batch/43/ to track these. > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > I’d like to follow-up on this discussion with a list of another 63 unique, valid Sectigo-issued P-521 SPKI certificates that have been issued since I reported the first batch back in January. According to Sectigo [1], a patch was deployed on January 8th to prevent issuance of certificates with P-521 SPKIs, but there must have been a problem with the deployment or a regression was introduced, as all these certificates have a notBefore date of several weeks after January 8th: Sectigo "crt.sh URL(s)", notBefore, notAfter, "subject CN", "issuer CN" "https://crt.sh/?id=1153301077 (precert); https://crt.sh/?id=1153303683 (final)", 2019-01-29, 2020-01-29, *.012919020120149.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1159765604 (precert); https://crt.sh/?id=1159768069 (final)", 2019-01-30, 2020-01-30, vpn.catest.net, "Gandi Standard SSL CA 2" "https://crt.sh/?id=1166099013 (precert); https://crt.sh/?id=1166156646 (final)", 2019-02-03, 2021-02-02, sso.aust.ae, "GlobeSSL DV Certification Authority 2" "https://crt.sh/?id=1172672983 (precert); https://crt.sh/?id=1172675064 (final)", 2019-02-05, 2020-02-05, *.020519020223240.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1173393341 (precert); https://crt.sh/?id=1173396153 (final)", 2019-02-05, 2020-02-05, *.020519060222541.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1194624767 (precert); https://crt.sh/?id=1194625305 (final)", 2019-02-11, 2021-02-10, im-ec.angelo.edu, "InCommon ECC Server CA" "https://crt.sh/?id=1194625403 (precert); https://crt.sh/?id=1194625563 (final)", 2019-02-11, 2021-02-10, im-ec.angelo.edu, "InCommon ECC Server CA" "https://crt.sh/?id=1194625375 (precert); https://crt.sh/?id=1194625597 (final)", 2019-02-11, 2021-02-10, im-ec.angelo.edu, "InCommon ECC Server CA" "https://crt.sh/?id=1203447331 (precert); https://crt.sh/?id=1203448393 (final)", 2019-02-14, 2020-02-14, *.021419180252278.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1203465736 (precert); https://crt.sh/?id=1203465915 (final)", 2019-02-14, 2020-02-14, *.021419180252278.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1221647998 (precert); https://crt.sh/?id=1221648175 (final)", 2019-02-21, 2020-02-21, *.022119020213378.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1221642108 (precert); https://crt.sh/?id=1221644541 (final)", 2019-02-21, 2020-02-21, *.022119020213378.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=123290 (precert); https://crt.sh/?id=1232911335 (final)", 2019-02-26, 2020-02-26, test-september.merck.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1235318031 (precert); https://crt.sh/?id=1235318034 (final)", 2019-02-27, 2020-02-27, *.022719020237488.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1260274146 (precert); https://crt.sh/?id=1260274133 (final)", 2019-03-07, 2020-03-06, *.030719020323283.vfidev.com, "COMODO ECC Organization Validation Secure Server CA" "https://crt.sh/?id=1263239685 (precert);
Re: P-521 Certificates
Jakob Bohm via dev-security-policy writes: >On 11/01/2019 13:04, Peter Gutmann wrote: >> Jason via dev-security-policy writes: >> >>> I would say that the problem here would be that a child certificate can't >>> use >>> a higher cryptography level than the issuer >> >>Why not? If the issuer uses strong-enough crypto, what difference does it >>make what the child uses? > >Really? If the CA key is weaker than the child key, an attacker can break >the CA key and sign a fake certificate with less effort than breaking the >child key directly You've apparently missed the fact that I said "strong-enough crypto". The attacker can't break either the issuer key or the child key, no matter how much stronger the child key may be than the issuer. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521 Certificates
On 11/01/2019 13:04, Peter Gutmann wrote: > Jason via dev-security-policy writes: > >> I would say that the problem here would be that a child certificate can't use >> a higher cryptography level than the issuer > > Why not? If the issuer uses strong-enough crypto, what difference does it > make what the child uses? > > Peter. > Really? If the CA key is weaker than the child key, an attacker can break the CA key and sign a fake certificate with less effort than breaking the child key directly (for modern crypto that "easier" is the difference between degrees of resistance to future cryptanalytic attacks, thus often involving some guesswork). This obviously is less effective for encryption public keys than signature public keys, as faking a new certificate doesn't provide access to data encrypted to the real certificate. It is also ineffective if the certificate is checked against additional criteria than the CA signatures, such as a strong Merkle hash tree or non-cryptographic proof of the certificate contents. Thus signing stronger child keys from weaker CA keys is often allowed as a transition mechanism when a trusted root with strength n has been widely distributed, yet there is a desire to introduce new keys with strength m > n . The typical way (at least in the past) is for the strength n CA key to cross sign a strength m CA key, which is also made available as its own root cert for future deployment, thus eventually removing the reliance on the strength n key to validate the strength m keys. This was seen a lot during the long transition from RSA-SHA1 to RSA-SHA256, and some CAs may wish to prepare early for future transitions from RSA-SHA256 and ECDSA-SHA256 to stronger algorithms. Similarly, some users obtained end certificates based on 2048 bit RSA back when 1024 bit RSA was the norm. Similarly situated users today may wish to get ECDSA-P-521 or EdDSA-488 keys at a time when half as long keys are the norm. While getting such certificates from a weaker CA is obviously vulnerable to future attacks on the CA key, at least this provides a safety margin where the mitigations mentioned above are likely to be available. 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-521 Certificates
Jason via dev-security-policy writes: >I would say that the problem here would be that a child certificate can't use >a higher cryptography level than the issuer Why not? If the issuer uses strong-enough crypto, what difference does it make what the child uses? Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521 Certificates
On 10/01/2019 15:38, Jason wrote: I would say that the problem here would be that a child certificate can't use a higher cryptography level than the issuer, this is agains good practices and, AFAIK, agains the Webtrust audit criteria. Jason Note that the only one of all these certificates that I checked closely was issued from a SubCA with an RSA key. Direct strength comparison etween RSA and EC keys is somewhat difficult and depends on predictions of future key breaking technology, so for some people, the CA key was stronger than that particular P-521 EC key. (Not that this is a requirement, see other replies). 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-521 Certificates
Jason - where did you see this requirement? -Original Message- From: dev-security-policy On Behalf Of Jason via dev-security-policy Sent: Thursday, January 10, 2019 9:38 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: P-521 Certificates I would say that the problem here would be that a child certificate can't use a higher cryptography level than the issuer, this is agains good practices and, AFAIK, agains the Webtrust audit criteria. Jason ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521 Certificates
I would say that the problem here would be that a child certificate can't use a higher cryptography level than the issuer, this is agains good practices and, AFAIK, agains the Webtrust audit criteria. Jason ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521 Certificates
Adding some data points for use by future readers of this thread. On 08/01/2019 03:26, Corey Bonnell wrote: > (Posting in a personal capacity as I am no longer employed by Trustwave) > > Mozilla Root Store Policy section 5.1 > (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > prohibits the use of P-521 keys in root certificates included in the Mozilla > trust store, as well as in any certificates chaining to these roots. This > prohibition was made very clear in the discussion on this list in 2017 at > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC8/fsKobHABAwAJ. > This is Message-Id Dated 2017-Jun-27 with Subject "P-521" and starts an approximately 2 week long thread where arguments were made for and against reinstatating P-521. Arguments were weak on both sides, but the "keep banning P-521" side was chosen at the end. As noted by others, the ban was checked into draft policy on 2017-Feb-20 and took effect upon publication on 2017-Feb-28 . There was no explicit transition rule for existing certificates, thus certificates issued before 2017-Feb-28 are presumably exempt until their normal expiry. > Below is a list of unexpired, unrevoked certificates which contain P-521 > public keys (grouped by CA Owner and ordered by notBefore): > > Sectigo > crt.sh URL, notBefore, notAfter, issuer CN > -- > https://crt.sh/?id=6371802, 2015-01-23, 2020-01-22, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=13764502, 2015-10-17, 2019-01-16, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=308269873, 2016-10-22, 2019-10-09, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=307896586, 2017-01-23, 2019-01-23, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=308306899, 2017-01-27, 2020-01-27, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=308113189, 2017-03-22, 2020-03-06, InCommon ECC Server CA > https://crt.sh/?id=307650153, 2017-03-26, 2020-03-25, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=307656068, 2017-04-20, 2020-07-18, COMODO ECC Organization > Validation Secure Server CA > https://crt.sh/?id=307534525, 2017-05-18, 2020-05-18, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=308201491, 2017-06-27, 2020-06-26, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=292253731, 2017-12-31, 2019-12-31, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=325088752, 2018-02-07, 2019-02-07, Gandi Standard SSL CA 2 > https://crt.sh/?id=495848274, 2018-02-25, 2019-02-25, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=363803336, 2018-03-23, 2020-05-23, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=369709685, 2018-03-29, 2019-04-28, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=369824505, 2018-03-29, 2020-03-25, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=377999330, 2018-04-05, 2020-04-04, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=395687551, 2018-04-14, 2019-04-29, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=441476932, 2018-04-14, 2019-04-29, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=419677583, 2018-04-25, 2020-04-24, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=419685986, 2018-04-25, 2020-04-24, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=441178023, 2018-05-05, 2019-05-05, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=441178000, 2018-05-05, 2019-05-05, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=447475737, 2018-05-07, 2020-05-06, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=447484644, 2018-05-07, 2020-05-06, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=453793669, 2018-05-10, 2019-05-10, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=453793685, 2018-05-10, 2019-05-10, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=455176361, 2018-05-11, 2019-05-11, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=455176321, 2018-05-11, 2019-05-11, COMODO ECC Domain > Validation Secure Server CA > https://crt.sh/?id=463185238, 2018-05-15, 2019-05-15, USERTrust ECC Domain > Validation Secure Server CA > https://crt.sh/?id=463092619, 2018-05-15, 2019-05-12, USERTrust ECC Domain > Validation Secure Server CA > https://crt.sh/?id=463092603, 2018-05-15, 2019-05-12, USERTrust ECC Domain > Validation Secure Server CA > https://crt.sh/?id=463185322, 2018-05-15, 2019-05-15, USERTrust ECC Domain > Validation Secure Server CA > https://crt.sh/?id=499794005, 2018-06-01, 2020-02-29, COMODO ECC Domain > Validation Secure Server CA >
Re: P-521 Certificates
Thanks Corey, Ryan, and Jonathan. In one of the bugs that Ryan created, the CA stated that it's not clear if or when Mozilla requires revocation of these P-521 certificates. I believe the answer is that we do not require revocation. Our policy (section 6) explicitly requires CAs to abide by the BR revocation rules (section 4.9.1.1), but these certificates do not meet any of those requirements. - Wayne On Tue, Jan 8, 2019 at 11:30 AM Jonathan Rudenberg via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: > > (Posting in a personal capacity as I am no longer employed by Trustwave) > > > > Mozilla Root Store Policy section 5.1 > > ( > https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > > > prohibits the use of P-521 keys in root certificates included in the > > Mozilla trust store, as well as in any certificates chaining to these > > roots. This prohibition was made very clear in the discussion on this > > list in 2017 at > > > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC8/fsKobHABAwAJ. > > > > > Below is a list of unexpired, unrevoked certificates which contain P-521 > > public keys (grouped by CA Owner and ordered by notBefore): > > I've created https://misissued.com/batch/43/ to track these. > ___ > 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-521 Certificates
On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote: > (Posting in a personal capacity as I am no longer employed by Trustwave) > > Mozilla Root Store Policy section 5.1 > (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/) > > prohibits the use of P-521 keys in root certificates included in the > Mozilla trust store, as well as in any certificates chaining to these > roots. This prohibition was made very clear in the discussion on this > list in 2017 at > https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC8/fsKobHABAwAJ. > > > Below is a list of unexpired, unrevoked certificates which contain P-521 > public keys (grouped by CA Owner and ordered by notBefore): I've created https://misissued.com/batch/43/ to track these. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
