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); https://crt.sh/
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
Checking this again I see that I'm probably wrong about Webtrust... Looking at 4.1.3-b: 4.1.3 CA key generation generates keys that: a) use a key generation algorithm as disclosed within the CA’s CP and/or CPS; b) have a key length that is appropriate for the algorithm and for the validity period of the CA certificate as disclosed in the CA’s CP and/or CPS. The public key length to be certified by a CA is less than or equal to that of the CA’s private signing key; and c) take into account requirements on parent and subordinate CA key sizes and have a key size in accordance with the CA’s CP and/or CPS. So this is about CA Keys... Although is a bit weird that there's such a requirement for intermediate and not for leaf certificates... El jueves, 10 de enero de 2019, 18:44:51 (UTC+3), Doug Beattie escribió: > 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 ___ 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 > https://crt.sh/?i
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
Re: P-521 Certificates
Thanks Corey for reporting these. As you note, this policy came in to force with Policy 2.4, which as noted in https://wiki.mozilla.org/CA/Root_Store_Policy_Archive , had a compliance date of February 28, 2017. This was also part of a CA Communications item - https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC&QuestionId=Q00022,Q00029 I've opened the following bugs, based on the CAs listed: Sectigo: https://bugzilla.mozilla.org/show_bug.cgi?id=1518553 DigiCert: https://bugzilla.mozilla.org/show_bug.cgi?id=1518555 Asseco DS / Certum: https://bugzilla.mozilla.org/show_bug.cgi?id=1518560 On Mon, Jan 7, 2019 at 9:55 PM Corey Bonnell via dev-security-policy < dev-security-policy@lists.mozilla.org> 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): > > 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-0
Re: P-521
On Tue, Jun 27, 2017 at 1:49 PM, Tom . wrote: > On 27 June 2017 at 11:44, Alex Gaynor wrote: > > I'll take the opposite side: let's disallow it before it's use expands > :-) > > But is that what we're talking about? I didn't think the question was > "Should we remove P-521 code from NSS" it's "Should we permit CAs to > use P-521?" > Note: Forbidding P-521 by policy likely wouldn't prompt us to disable or remove any code from NSS in any quick fashion; that curve is one of those exported to WebCrypto, and we'd need to be sure we weren't breaking things by pulling it from there. Given the low usage of ECDH/ECDSA and the lack of compatibility in Chrome, probably not, but we'd want to at least check. -J.C. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521
On 29/06/17 00:11, Arkadiusz Ławniczak wrote: > P-256, P-384 and P-521 curves are commonly implemented in all popular > cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or > Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware > cryptographic modules. Are you aware of any libraries or browsers which do not support P-521? > But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has > limited its policy to only two curves P-256 and P-384. > The reasons for this decision are known only to this agency and Mozilla. It > can be assumed that stronger cryptography is currently embarrassing for the > NSA, and the safety margin over the operation time is low. Do you believe that P-521 is usefully stronger than P-384? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: P-521
Hello all As CERTUM, we would like to create and submit to Mozilla our two new root CAs. There would be nothing unusual about this but I've found that Mozilla Policy doesn't allow to use algorithm P-521 and that is what we want to use in our root CA. NIST FIPS PUB 186-4 recommends 4 curves over Prime Fields for use in US public administration. These are: P-192, P-256, P-384, P-521 Baseline Requirements require: P-256, P-384 or P-521 Key Requirements for Microsoft Trusted Root Program: P-256, P-384, P-521 Mozilla Root Store Policy: P-256, P-384 P-256, P-384 and P-521 curves are commonly implemented in all popular cryptographic libraries such as OpenSSL, Microsoft Crypto API NB (CNG) or Bouncy Castle, popular web browsers and FIPS 140-2 certified hardware cryptographic modules. But it seems that Mozilla (like the NSA in its "Suite B" recommendation) has limited its policy to only two curves P-256 and P-384. The reasons for this decision are known only to this agency and Mozilla. It can be assumed that stronger cryptography is currently embarrassing for the NSA, and the safety margin over the operation time is low. >From the point of view of Certum CA, the two alleged reasons are irrelevant. This is true that, according to NSA "Suite B" recommendations, standards have been developed such as: 1) IETF RFC 6460, for TLS 2) IETF RFC 6379, for IPsec 3) IETF RFC 6318, for SMIME 4) IETF RFC 5759, for X.509 certificate and CRL However, we must recognize that X.509 end entities and service certificates are issued for one year, up to three years. CA root certificates are issued for 25 years. They must rely on stronger cryptography as well as the ARLs they publish. Not every commercial organization must also apply to NSA recommendations and its depleted cryptographic algorithms. Especially if it operates in Europe and cares for the safety of its customers. -- Arkadiusz Ławniczak Analyst Security and Trust Services Division Asseco Data Systems S.A. Biuro w Szczecinie ul. Królowej Korony Polskiej 21 70-486 Szczecin mob. +48 669992104 arkadiusz.lawnic...@assecods.pl assecods.pl -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assecods...@lists.mozilla.org] On Behalf Of Ryan Sleevi via dev-security-policy Sent: Wednesday, June 28, 2017 3:42 PM To: Alex Gaynor Cc: Gervase Markham; MozPol; Kurt Roeckx Subject: Re: P-521 On Tue, Jun 27, 2017 at 2:44 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I'll take the opposite side: let's disallow it before it's use expands > :-) > P-521 isn't great, and there's really no value in proliferation of > crypto algorithms, as someone told me: "Ciphersuites aren't pokemon, > you shouldn't try to catch 'em all". There's no real use cases P-521 > enables, and not supporting it means one less piece of code to drag > around as we move towards better curves/signature algorithms like Ed25519 and > co. +1 to this. P-521 is specified for negotiation because negotiation is just that - negotiation. It's not mandatory to implement all of those algorithms, and it's not necessarily desirable to either (e.g. rsa_pkcs1_sha1 ) P-521 does not have widespread deployment on the Web PKI, and does not meaningfully or substantially improve security relevant to the attacks, at a computational and interoperability cost that is justified. ___ 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
On Tue, Jun 27, 2017 at 2:44 PM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I'll take the opposite side: let's disallow it before it's use expands :-) > P-521 isn't great, and there's really no value in proliferation of crypto > algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't > try to catch 'em all". There's no real use cases P-521 enables, and not > supporting it means one less piece of code to drag around as we move > towards better curves/signature algorithms like Ed25519 and co. +1 to this. P-521 is specified for negotiation because negotiation is just that - negotiation. It's not mandatory to implement all of those algorithms, and it's not necessarily desirable to either (e.g. rsa_pkcs1_sha1 ) P-521 does not have widespread deployment on the Web PKI, and does not meaningfully or substantially improve security relevant to the attacks, at a computational and interoperability cost that is justified. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: P-521
Alex Gaynor via dev-security-policy writes: >I'll take the opposite side: let's disallow it before it's use expands :-) >P-521 isn't great, and there's really no value in proliferation of crypto >algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't >try to catch 'em all". "Elliptic Curve Cryptography in Practice", FC'14, for SSH P256 support is 99.9%, P521 support is 0.01%, P384 support is 0.00%. So you can pretty much just assume that if it supports ECC, it'll be P256. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521
On 27 June 2017 at 11:44, Alex Gaynor via dev-security-policy wrote: > I'll take the opposite side: let's disallow it before it's use expands :-) > P-521 isn't great, and there's really no value in proliferation of crypto > algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't > try to catch 'em all". There's no real use cases P-521 enables, and not > supporting it means one less piece of code to drag around as we move > towards better curves/signature algorithms like Ed25519 and co. But is that what we're talking about? I didn't think the question was "Should we remove P-521 code from NSS" it's "Should we permit CAs to use P-521?" Limiting the policy to restrict P-521 would probably not affect the code at all - a self-signed cert that uses it will still trigger the code most likely (unless we were particularly clever about not hitting those code paths until after the user trusted a self-signed cert.) -tom ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521
I'll take the opposite side: let's disallow it before it's use expands :-) P-521 isn't great, and there's really no value in proliferation of crypto algorithms, as someone told me: "Ciphersuites aren't pokemon, you shouldn't try to catch 'em all". There's no real use cases P-521 enables, and not supporting it means one less piece of code to drag around as we move towards better curves/signature algorithms like Ed25519 and co. Alex On Tue, Jun 27, 2017 at 2:40 PM, Kurt Roeckx via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote: > > On 27/06/17 07:17, Kurt Roeckx wrote: > > > I suggest you keep it for now. > > > > An opinion without a rationale is not all that useful :-) > > A lot of software supports it, including NSS / Firefox. It's not > an ideal curve, and it should get replaced, but it's currently > better to have it then not. > > I currently only count 222 certificate using P-521 that chain to > the Mozilla root store, and I guess some of those would fall back > to RSA. > > I see no reason to say that they shouldn't be used at this time. > > > Kurt > > ___ > 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
On Tue, Jun 27, 2017 at 10:41:49AM -0700, Gervase Markham wrote: > On 27/06/17 07:17, Kurt Roeckx wrote: > > I suggest you keep it for now. > > An opinion without a rationale is not all that useful :-) A lot of software supports it, including NSS / Firefox. It's not an ideal curve, and it should get replaced, but it's currently better to have it then not. I currently only count 222 certificate using P-521 that chain to the Mozilla root store, and I guess some of those would fall back to RSA. I see no reason to say that they shouldn't be used at this time. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521
On 27/06/17 07:17, Kurt Roeckx wrote: > I suggest you keep it for now. An opinion without a rationale is not all that useful :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: P-521
On 2017-06-27 15:51, Gervase Markham wrote: This issue seems to come up regularly, and I can never find the discussion I'm sure we had about it, so I'm starting a thread here with "P-521" in the subject so it'll be clear. Should we be permitting use of this curve in our policy? I suggest you keep it for now. You should probably allow ed25519 and ed448. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
