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.m
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 > Valida
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: FW: P-521
On 05/07/17 11:40, Arkadiusz Ławniczak wrote: > As CERTUM, we are not aware of any implementations which do not > support P-521 (with the exception of BoringSSL where P-512 is > disabled but not unsupported). Yes, but that means that whenever Chrome uses BoringSSL, your roots won't work, right? Is that not a problem for you? >> From a cryptosystem security point of view - especially rootCA and >> ARL - P384 to P521 is like "day to night". This is particularly >> important for crypto-systems to be safe for decades. As noted in my previous message, you need to provide some backup for that assertion. > The key is: "or higher". The thing is the vendors'/browsers' policies > should be consistent with the functioning of the market and therefore > we belive that removing P-521 from Mozilla Policy was not a good > thing. "The market" is overwhelmingly not using P-521, according to the statistics quoted in this discussion. If we allow it and it starts being used, every web client SSL implementation will need to carry this algorithm for the forseeable future. Given that there are other new, probably-better curves and algorithms coming down the pipe, it seems unwise to pad out the compulsory set with yet more variants on the same thing. So pending a very good argument why P-521 provides something that neither the existing algorithms nor the new class of pending algorithms can provide, I think we will leave the policy as-is. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On 06/07/17 16:20, Ryan Sleevi wrote: > compelling to add support for, and the security boundary between 192-bits > and 256-bits is somewhere in the "heat death of the universe" level > security (see > https://www.imperialviolet.org/2014/05/25/strengthmatching.html ) Perhaps this is the discussion we need to be having, because Arkadiusz asserted the difference was "night and day". Arkadiusz: do you have backing for your assertion that P-521 has meaningfully improved levels of security over 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
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: FW: P-521
On Thu, Jul 6, 2017 at 10:46 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/07/17 14:49, Alex Gaynor wrote: > > Is it really true that additional curves are just additional parameters? > I > > That was my assumption; additional clue on this point would be welcome. As Alex mentioned - it's generally not the case. While you can implement with generic parameters, this can create both security and performance issues, and so the preference within cryptographic libraries is to maintain optimized versions (optimized for constant time, which is not always easy, but also optimized for performance). For NSS, consider the contributions from Intel - https://bugzilla.mozilla.org/show_bug.cgi?id=1073990 , the performance analysis in https://bugzilla.mozilla.org/show_bug.cgi?id=1125028 , the performance optimizations in https://bugzilla.mozilla.org/show_bug.cgi?id=653236 , and the performance issues in https://bugzilla.mozilla.org/show_bug.cgi?id=1293936 . In short, it generally gravitates towards per-platform, per-curve optimizations. I think it's also worthwhile to consider the performance impact - https://www.imperialviolet.org/2010/12/21/eccspeed.html . Note where P-521 falls on that graph. While this is 7 years ago, the numbers have not (to my knowledge) substantially improved in relation to eachother. It's also useful to think of this similar to RSA. The Baseline Requirements do not set a maximum bound on the RSA modulus size - merely specifying a minimum of 2048. However, in practice, >= 8096 is not supported, due to limitations that many platforms impose, due to the computational cost. So the Web PKI does determine an effective limit, even if NSS supports up to 16K RSA moduli sizes (but imposes 16K as the limit, again, for performance reasons). So the Web PKI certainly imposes limits - for performance, security, and interoperability - so it's not unreasonable to impose this same limit. The performance gulf, and the added overhead, do not make it significantly compelling to add support for, and the security boundary between 192-bits and 256-bits is somewhere in the "heat death of the universe" level security (see https://www.imperialviolet.org/2014/05/25/strengthmatching.html ) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On 05/07/17 14:49, Alex Gaynor wrote: > Is it really true that additional curves are just additional parameters? I That was my assumption; additional clue on this point would be welcome. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
On Wed, Jul 5, 2017 at 7:51 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I agree crypto algorithms are not "gotta catch 'em all", but the > algorithm is ECDH, which NSS must implement anyway to support P-256 and > P-384, and a curve is just another set of parameters to it. I also think > that there is little value and there is potential confusion (as we have > seen) in Mozilla mandating a more restrictive set than the BRs and than > Microsoft: > Is it really true that additional curves are just additional parameters? I haven't gone source-diving in NSS recently, but my understanding is that most crypto libraries provide optimized assembly routines for scalar multiplication on a per-curve basis -- OpenSSL appears to have over 10,000 lines of assembly-generating-perl for P256 alone ( https://github.com/openssl/openssl/tree/master/crypto/ec/asm). Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: P-521
I agree crypto algorithms are not "gotta catch 'em all", but the algorithm is ECDH, which NSS must implement anyway to support P-256 and P-384, and a curve is just another set of parameters to it. I also think that there is little value and there is potential confusion (as we have seen) in Mozilla mandating a more restrictive set than the BRs and than Microsoft: > 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 If there are, or become, interoperability issues in practice, then I think we can leave that as the CA's lookout. So I am currently minded to restore P-521 to the Mozilla permitted list. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
FW: P-521
Hi As CERTUM, we are not aware of any implementations which do not support P-521 (with the exception of BoringSSL where P-512 is disabled but not unsupported). All popular web browsers support all three P-256, P-384 and P521 curves. The P-521 certificates are imported correctly even to the old iPhone 5S (iOS 10.3.2) or to the Samsung SM-T325 (Android 4.4.2). If the software does not support elliptic curves, it does not support them all - all or none. Also, when we consider NIST Special Publication 800-57 Part 1, Revision 4. Recommendation for Key Management, P. 53, Table 2: Comparable strengths (http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf) we can see the strengths of algorithms given as security bits. It clearly shows that algorithms based on P512 + curves represent 256 bits of security while curve 384 represents 192 bits. >From a cryptosystem security point of view - especially rootCA and ARL - P384 >to P521 is like "day to night". This is particularly important for >crypto-systems to be safe for decades. PS. Some example from Adobe world. The new AATL Technical Requirements (June 2017) states that: >RCA8 [...]For Elliptic Curve signature technology, a key length of 256-bit or >higher is required for RCA certificates. >A key length of 384-bit or higher is required for RCA certificates that are >issued on or after 1 July 2017. [...] The key is: "or higher". The thing is the vendors'/browsers' policies should be consistent with the functioning of the market and therefore we belive that removing P-521 from Mozilla Policy was not a good thing. -- Arkadiusz Ławniczak -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assecods...@lists.mozilla.org] On Behalf Of Arkadiusz Ławniczak via dev-security-policy Sent: Thursday, June 29, 2017 9:12 AM To: r...@sleevi.com; Alex Gaynor Cc: MozPol; Gervase Markham; Kurt Roeckx Subject: 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
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 <dev-security-policy@lists.mozilla.org> 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 <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. 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
P-521
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 removed it from the policy in https://github.com/mozilla/pkipolicy/issues/5 because I was under the impression that Firefox and/or NSS didn't support it. But I now see (not sure how I didn't notice before) that the relevant bugs are unfixed or WONTFIXed: https://bugzilla.mozilla.org/show_bug.cgi?id=1129077 https://bugzilla.mozilla.org/show_bug.cgi?id=1128792 And I notice that the P-521/SHA-512 combination is recommended, or at least specced, in TLS 1.3: https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.2.3 But it seems like BoringSSL doesn't support it: https://boringssl.googlesource.com/boringssl/+/e9fc3e547e557492316932b62881c3386973ceb2 So what should we be doing in our policy (which, by principle, looks to Mozilla's needs first)? Banning it? Discouraging it but allowing it? Permitting it? Something else? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
