Re: About 's future...
The existence of this bug... https://bugzilla.mozilla.org/show_bug.cgi?id=1191414 "gather telemetry on usage of " ...would seem to suggest that Mozilla "haven't decided anything yet". On 17/09/15 19:51, helpcrypto helpcrypto wrote: > Hi all > > > As previously raised on this list, there's a open wardiscussion about > removing [1] > > Some people, like Sir Tim Berners-Lee doesn't seem to agree with that, > hence another thread is taking place at [2] > > For Google, it seems the decision has been made, nothing is going to > change, and could dissappear on Chrome 47 [3]. > > As MDN has marked the element as deprecated (according to WHATWG, I guess) > and there is -at least- one related bug open [4]: > > > *I will love someone @mozilla giving an official position, a blog post or > saying something (even "we haven't decided anything yet") about this issue, > and -if it's going to happen- aproximate date of the removal.* > > > Thanks a lot. > > [1] > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/pX5NbX0Xack > [2] https://lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html > [3] https://code.google.com/p/chromium/issues/detail?id=514767 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871 > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: What's My Chain Cert?
Great tool. I wonder how well its chain selection strategy works in practice though. The README [1] says: If multiple certificate chains are found, the shortest one is used. That's a good strategy for a browser to employ when deciding which chain to show in its certificate viewer, but it's unlikely to be the best strategy when configuring a server. There's often a cross-certificate issued by an older root to a newer root. For compatibility with browsers that don't trust the newer root, the server should send that cross-certificate too (even though it isn't part of the shortest chain). Using the longest available chain isn't always the correct strategy either though. [1] https://github.com/SSLMate/mkcertchain On 24/03/15 11:40, Gervase Markham wrote: Discovered today: https://whatsmychaincert.com/ That seems like a great resource for when we get those emails that say my cert isn't working in Firefox - why? Thanks to Andrew of SSLMate for putting the site together. Gerv -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Updates to the Server Side TLS guide
On 25/10/14 19:26, Julien Vehent wrote: snip I wonder if this is really useful though. Server Side TLS is a pragmatic guide, and pragmatism dictates that operators should use SHA-256 certs, not SHA-384 or SHA-512. When asked to review a production site that runs a SHA-512 cert, I would recommend the admins to downgrade to SHA-256 to prevent unknown behavior with unknown clients. Sadly, SHA-512 certs (both CA and end-entity) don't work very well with WebPKI TLS. Browsers typically don't specify RSA/SHA-512 and ECDSA/SHA-512 in the TLS signature_algorithms extension. Some servers interpret signature_algorithms as a full list of certificate signature algorithms supported by the client. Rather than return a SHA-512 cert to those browsers, such servers send a fatal alert. snip * ECDSA certs (and prioritisation of ECDSA above RSA) - there's no mention of those, and since we suggest PFS over non-PFS and ECDHE-ECDSA is over twice as fast as ECDHE-RSA[1], I think we definitely should allow (if not recommend) its use Same comment as above: we first need to evaluate compatibility of clients. Having ECDSA in the recommended ciphersuites has no site effect on server compatibility. But recommending ECDSA certificates does have strong side effects. Do you know of certificate authorities that issue ECDSA certs? Yes. Comodo and Symantec definitely do, and I wouldn't be surprised if several other CAs do by now. CloudFlare's Universal SSL uses ECDSA certs exclusively, so as of a few weeks ago there are now _a lot_ of ECDSA certs in the wild. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
http://dev.chromium.org/Home/chromium-security/crlsets says: The limit of the CRLSet size is 250KB Have Mozilla decided what the maximum OneCRL size will be? On 01/08/14 03:07, Richard Barnes wrote: Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed save on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SHA-256 support
On 11/18/2013 07:00 AM, Gervase Markham wrote: Hi everyone, Following Microsoft's announcement re: SHA-1, some CAs are asking browser and OS vendors about the ubiquity of SHA-256 support. It would be a help to them if we could say: - Which version of NSS first supported SHA-256 Gerv, SHA-256 isn't the only algorithm of interest here. The latest Windows Root Certificate Program requirements [1] permit CAs to use SHA-256, SHA-384 and SHA-512. Unsurprisingly, these 3 functions from the SHA-2 family are what the Windows CryptoAPI actually supports (since XP SP3). On 19/11/13 02:20, Robert Relyea wrote: I think it's safe to say if your NSS ap is newer than a decade old, you have SHA-2 support. The one caveat is that SHA-224 support was added much later, but SHA-256, SHA-384, and SHA-512 have all been supported for a while. SHA-224 isn't supported by CryptoAPI, and CAs aren't permitted (by [1]) to use it anyway. Ditto for the SHA-512/224, SHA-512/256 and SHA-512/t functions that were added to the SHA-2 specification [2] last year. [1] http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx [2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
Hmmm...why are all of the DNSNames duplicated? The ones with a dot at the beginning don't need to be there, do they? On 02/11/13 15:13, Kaspar Brand wrote: On 02.11.2013 15:40, Erwann Abalea wrote: You missed the exclusion of IPv6 addresses. So this CA can certify for any IPv6 address range. I don't think it will be very dangerous within the next year, considering current IPv6 deployment. s/You/They/. I'm not affiliated with O=Baltimore in any way (nor with O=admin, JFTR). For a live site serving this cert in the handshake, you might want to visit https://www.sonderbewilligungen.admin.ch. Kaspar -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
On 02/11/13 14:40, Erwann Abalea wrote: Le samedi 2 novembre 2013 08:39:53 UTC+1, Kaspar Brand a écrit : 11 hours ago, a new certificate was given birth to which I would like to share with this list for edification purposes. I think that the audience here should be able to fully appreciate what marvellous real-world example we are now provided with for testing the PKIX-based path validation implementations of the world for RFC 5280 compliance (Applications conforming to this profile MUST be able to process name constraints that are imposed on the directoryName name form and SHOULD be able to process name constraints that are imposed on the rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name forms). Nice. Even cut/pasting it to parse it is a bargain. Wouldn't it have been easier to have several CA certificates with smaller constraints? With such a large permitted subtree, can it really be considered constrained? Technically, it is, yes. You missed the exclusion of IPv6 addresses. So this CA can certify for any IPv6 address range. I don't think it will be very dangerous within the next year, considering current IPv6 deployment. Nonetheless, that IPv6 omission means that this CA certificate is unfortunately _not_ considered technically constrained according to the Mozilla CA Certificate Inclusion Policy. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: id-ce-nameConstraints (2.5.29.30) in the real world
UDELMAkGA1UEBhMCQ0gxDTALBgNVBAcTBEJlcm4xMjAwBgNVBAoMKUVpZGdlbsO2 c3Npc2NoZSBGaW5hbnptYXJrdGF1ZnNpY2h0IEZJTk1BMEGkPzA9MQswCQYDVQQG EwJDSDEUMBIGA1UEBxMLTGVzIEFjYWNpYXMxGDAWBgNVBAoMD0V0YXQgZGUgR2Vu w6h2ZTA2pDQwMjELMAkGA1UEBhMCQVQxDTALBgNVBAcTBExpbnoxFDASBgNVBAoT C0ZhYmFzb2Z0IEFHMF+kXTBbMQswCQYDVQQGEwJDSDEQMA4GA1UEBxMHUG9zaWV1 eDE6MDgGA1UEChMxRm9yc2NodW5nc2Fuc3RhbHQgQWdyb3Njb3BlIExpZWJlZmVs ZC1Qb3NpZXV4IEFMUDBBpD8wPTELMAkGA1UEBhMCQ0gxEzARBgNVBAcTClpvbGxp a29mZW4xGTAXBgNVBAoTEEdFTEFOIEluZm9ybWF0aWswWKRWMFQxCzAJBgNVBAYT AkNIMQ0wCwYDVQQHEwRCZXJuMTYwNAYDVQQKEy1HZW5lcmFsc2VrcmV0YXJpYXQg V0JGL0luZm9ybWF0aWsgRGVwYXJ0ZW1lbnQwbqRsMGoxCzAJBgNVBAYTAk1DMQ8w DQYDVQQHEwZNb25hY28xSjBIBgNVBAoTQUdvdXZlcm5lbWVudCBkZSBNb25hY28t RGlyZWN0aW9uIGRlcyBDb21tdW5pY2F0aW9ucyBFbGVjdHJvbmlxdWVzMDGkLzAt MQswCQYDVQQGEwJDSDENMAsGA1UEBxMEQmVybjEPMA0GA1UEChMGR1MtRVZEMDmk NzA1MQswCQYDVQQGEwJDSDENMAsGA1UEBxMEQmVybjEXMBUGA1UEChMOSVYtU3Rl bGxlIEJlcm4wOaQ3MDUxCzAJBgNVBAYTAkNIMQ4wDAYDVQQHEwVBYXJhdTEWMBQG A1UEChMNS2FudG9uIEFhcmdhdTA9pDswOTELMAkGA1UEBhMCQ0gxDTALBgNVBAcT BENodXIxGzAZBgNVBAoMEkthbnRvbiBHcmF1YsO8bmRlbjA6pDgwNjELMAkGA1UE BhMCQ0gxDzANBgNVBAcTBlNjaHd5ejEWMBQGA1UEChMNS2FudG9uIFNjaHd5ejBK pEgwRjELMAkGA1UEBhMCQ0gxEDAOBgNVBAcMB1rDvHJpY2gxJTAjBgNVBAoMHEth bnRvbmFsZSBWZXJ3YWx0dW5nIFrDvHJpY2gwNKQyMDAxCzAJBgNVBAYTAkNIMQ0w CwYDVQQHEwRCZXJuMRIwEAYDVQQKEwlMdWZ0d2FmZmUwXKRaMFgxCzAJBgNVBAYT AkNIMRQwEgYDVQQHEwtCaWVsL0JpZW5uZTEzMDEGA1UECgwqT2ZmaWNlIGbDqWTD qXJhbCBkZSBsYSBjb21tdW5pY2F0aW9uIE9GQ09NMFOkUTBPMQswCQYDVQQGEwJD SDETMBEGA1UEBwwKTmV1Y2jDonRlbDErMCkGA1UECgwiT2ZmaWNlIGbDqWTDqXJh bCBkZSBsYSBzdGF0aXN0aXF1ZTBLpEkwRzELMAkGA1UEBhMCQ0gxDTALBgNVBAcT BEJlcm4xKTAnBgNVBAoTIFBlbnNpb25za2Fzc2UgZGVzIEJ1bmRlcyBQVUJMSUNB MEykSjBIMQswCQYDVQQGEwJDSDETMBEGA1UEBxMKQmVsbGluem9uYTEkMCIGA1UE ChMbUmVwdWJibGljYSBlIENhbnRvbmUgVGljaW5vMEekRTBDMQswCQYDVQQGEwJD SDENMAsGA1UEBxMEQmVybjElMCMGA1UEChMcU2Nod2VpemVyaXNjaGUgQnVuZGVz a2FuemxlaTBNpEswSTELMAkGA1UEBhMCQ0gxDTALBgNVBAcTBEJlcm4xKzApBgNV BAoTIlNjaHdlaXplcmlzY2hlIEluZm9ybWF0aWtrb25mZXJlbnowR6RFMEMxCzAJ BgNVBAYTAkNIMQ0wCwYDVQQHEwRCZXJuMSUwIwYDVQQKExxTY2h3ZWl6ZXJpc2No ZXMgQnVuZGVzYXJjaGl2MEGkPzA9MQswCQYDVQQGEwJDSDEUMBIGA1UEBxMLRGF2 b3MgUGxhdHoxGDAWBgNVBAoTD1NwaXRhbCBEYXZvcyBBRzBMpEowSDELMAkGA1UE BhMCQ0gxDTALBgNVBAcTBEJlcm4xKjAoBgNVBAoMIVN0YWF0c3Nla3JldGFyaWF0 IGbDvHIgV2lydHNjaGFmdDBMpEowSDELMAkGA1UEBhMCQ0gxDTALBgNVBAcTBEJl cm4xKjAoBgNVBAoTIVN0ZXVlcnZlcndhbHR1bmcgZGVzIEthbnRvbnMgQmVybjBO pEwwSjELMAkGA1UEBhMCQ0gxDzANBgNVBAcTBldhYmVybjEqMCgGA1UEChMhU3dp c3MgRmVkZXJhbCBPZmZpY2Ugb2YgTWV0cm9sb2d5MDWkMzAxMQswCQYDVQQGEwJD SDENMAsGA1UEBxMEQmVybjETMBEGA1UEChMKU3dpc3NtZWRpYzA6pDgwNjELMAkG A1UEBhMCQ0gxFTATBgNVBAcMDEVtbWVuYnLDvGNrZTEQMA4GA1UEChMHemVudHJh czBmpGQwYjELMAkGA1UEBhMCQ0gxDTALBgNVBAcTBEJlcm4xRDBCBgNVBAoMO0Rl cGFydGVtZW50IGbDvHIgVmVydGVpZGlndW5nIEJldsO2bGtlcnVuZ3NzY2h1dHog dW5kIFNwb3J0oQwwCocIAAAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQW MBQGCCsGAQUFBwMBBggrBgEFBQcDAjAfBgNVHSMEGDAWgBTlnVkwgkdYzKz6CFQ2 hns6tQRN8DBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vY2RwMS5wdWJsaWMtdHJ1 c3QuY29tL0NSTC9PbW5pcm9vdDIwMjUuY3JsMB0GA1UdDgQWBBQqxGkKocZVxgNu cM6GgbOkD6oZ2zANBgkqhkiG9w0BAQUFAAOCAQEAOtYqqZMEofe1V9AQX2A4BVN6 2Re3wLWY293JacyU80S4J32dKaf03CDghTze1uIGUP0i7VVQjiD0B0IqAm5gymok VGwA/UwQ21oZM7eyX+u6yCf1uS1iIEJavaI7cc48B3/KjRHxBD000ZPeIh8++gSN ZasaFrrcbUAeEwLxc7LOFdR/Pv6FgL2ptnrXuga1UxJMpG3ybudmJwSudX07KGT9 8Yaqw9aIOLwaUvCtIUB+5orZBIIWy1zfq+lX1o6bHnx3nY2Tk/s991z/ufg7GQN8 iHyunfkp5eAFTJ8+FtpEUcWKKB1mEQBxk65af8XpScn2miiFZbPXYWg6f8bbMA== -END CERTIFICATE- -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 13/09/13 04:52, Julien Pierre wrote: snip Some servers also ignore the order of cipher suites in the Clienthelo anyway in some cases, and choose whatever they prefer among the client cipher suite list regardless of order, even though this doesn't follow the TLS specs. Julien, I disagree that this doesn't follow the TLS specs. RFC5246 (Section 7.4.1.2) says (emphasis mine): The cipher suite list, passed from the client to the server in the ClientHello... If the list contains cipher suites the server does not recognize, support, *or wish to use*, the server MUST ignore those cipher suites, and process the remaining ones as usual. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
The NSA recommends ECC for encrypting secret and top secret information. So if the NSA have backdoored the NIST curves somehow, presumably they're 100% confident that the details of the backdoor won't get leaked or discovered by external researchers! On 09/09/13 17:15, Kurt Roeckx wrote: On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote: On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
Probably worth keeping an eye on this new draft and the related discussion on the TLS list... http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 On 09/09/13 17:15, Kurt Roeckx wrote: On Mon, Sep 09, 2013 at 11:29:19AM -0400, Stefan Arentz wrote: On Sep 9, 2013, at 11:16 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 03:30, Brian Smith wrote: Please see https://briansmith.org/browser-ciphersuites-01.html This proposal promotes ECC. http://www.theguardian.com/world/2013/sep/05/nsa-how-to-remain-secure-surveillance Schneier: Prefer conventional discrete-log-based systems over elliptic-curve systems; the latter have constants that the NSA influences when they can. He elaborates in the comments: I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry. Does that affect your proposal? Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ? No, he actually said he doesn't trust any ECC, but on the other hand said that we should probably move to at least 500 bit ECC. Kurt -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 15/08/13 18:15, Chris Richardson wrote: I believe this plan would have poor side effects. For example, if Apple ships clients with a broken ECDSA implementation [0], a server cannot detect detect if a connecting client is an Apple product and avoid the use of ECDSA in that subset of connections. Instead, ECDSA suddenly becomes unsafe for anyone to use anywhere. Chris, Firefox already offers ECDHE-ECDSA ciphersuites, so I don't think Brian's plan would introduce any _new_ side effects relating to that OSX (10.8..10.8.3) bug. Are you suggesting that Firefox should drop support for all ECDHE-ECDSA ciphersuites? Or are you suggesting that NSS should implement the equivalent of that proposed OpenSSL patch, so that NSS-based TLS servers can avoid attempting to negotiate ECDHE-ECDSA with broken OSX clients? Or what? Should browsers drop support now for all TLS features that might possibly suffer broken implementations in the future? (For example, AGL would like to get rid of AES-GCM because it's hard to implement securely. See https://www.imperialviolet.org/2013/01/13/rwc03.html) [0]: https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith br...@briansmith.org wrote: Please see https://briansmith.org/browser-ciphersuites-01.html First, this is a proposal to change the set of sequence of ciphersuites that Firefox offers. Secondly, this is an invitation for other browser makers to adopt the same sequence of ciphersuites to maximize interoperability, to minimize fingerprinting, and ultimately to make server-side software developers and system administrators' jobs easier. Suggestions for improvements are encouraged. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 16/08/13 23:05, Wan-Teh Chang wrote: snip 8. Authentication: RSA before ECDSA a. RSA before ECDSA : performance b. DSA last: not in use snip ... I would prefer ECDSA over RSA for authentication. Wan-Teh, why do you think Firefox should specify a preference for ECDSA over RSA? If a webserver wants to prefer ECDSA over RSA, then it can override the browser-supplied cipher-suite order. e.g. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslhonorcipherorder -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Introductions - want to contribute to NSS developer friendliness
On 17/06/13 18:58, Chris Newman wrote: snip I think these would be good usability issues to address. When I contributed that code, I was a Sun Microsystems employee and Sun was an NSS contributor. However, I can not maintain or update that code as my present employer does not have a code contribution agreement with Mozilla to my knowledge. Is there actually such a thing as a code contribution agreement with Mozilla ? https://bugzilla.mozilla.org/show_bug.cgi?id=369879#c19 ...suggests that there isn't (at least, not yet). (A quick Google search finds a MoFo Committer's Agreement, but you don't need committer privileges in order to create a bug on Bugzilla, attach a patch, etc). -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Root Certificates in Firefox OS (was Re: NSS in Firefox OS)
On 20/10/12 18:33, Brian Smith wrote: snip B2G (Firefox OS) does use NSS. Brian, I presume that Firefox OS trusts NSS's Built-in Root Certificates [1], but what (if anything) does Firefox OS do for EV SSL? Does Firefox OS import PSM's list of EV-enabled Root Certificates? [2] Thanks. [1] https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt [2] https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp snip -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
I've just filed Bug 764393 to track this request. I've attached an updated version of Nelson's disgusting hack patch. I've also attached a patch for the alternative idea I mentioned. I'd be very grateful if the NSS Team would seriously consider accepting one of these two patches ASAP! On 11/06/12 15:25, Rob Stradling wrote: On 09/06/12 06:03, Wan-Teh Chang wrote: Rob, Please fix the bug in the old certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? Wan-Teh Hi Wan-Teh. I'm afraid I have nowhere near enough knowledge of NSS internals to turn Nelson's disgusting hack [1] into something that the NSS team would, under normal circumstances, contemplate committing [2]. I've just tested Nelson's 2 patches ([1] and [3]) against mozilla-inbound, and they appear to fix the problem. IMHO, a disgusting hack fix is much better than a non-disgusting, significantly delayed fix. So, how would Mozilla and the NSS Team feel about committing Nelson's 2 patches? [1] https://bugzilla.mozilla.org/attachment.cgi?id=366236 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=482153#c1 [3] https://bugzilla.mozilla.org/attachment.cgi?id=366225 P.S. An alternative idea, for which I am willing to write a patch (if you think this would be preferable to Nelson's disgusting hack): - Define a certHashesToAvoidUsing[] array in nssCertificateArray_FindBestCertificate(). Populate this array with the hashes of all of the UTN-AddTrust and AddTrust-UTN cross-certificates. Make the code consult this list: if a match is found, do not consider this cert to be the best match. P.P.S. 2 other ideas which didn't appear to work... 1. I tried adding the affected UTN--AddTrust cross-certificates as distrusted built-ins, but this didn't help. Presumably distrust is only evaluated after the best certificate chain has been chosen, rather than during the process of chain selection. 2. I tried removing one of the affected UTN root-certificates and then adding the relevant AddTrust-UTN cross-certificate as a built-in. This didn't work either, presumably because the UTN root-certificate was for some reason still listed as a Software Security Device. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Is there an ETA yet for when Firefox will use libpkix by default?
On 09/06/12 06:03, Wan-Teh Chang wrote: Rob, Please fix the bug in the old certificate verification library. Thanks. Are you going to use the approach outlined by Nelson in bug 479508 and bug 482153? Wan-Teh Hi Wan-Teh. I'm afraid I have nowhere near enough knowledge of NSS internals to turn Nelson's disgusting hack [1] into something that the NSS team would, under normal circumstances, contemplate committing [2]. I've just tested Nelson's 2 patches ([1] and [3]) against mozilla-inbound, and they appear to fix the problem. IMHO, a disgusting hack fix is much better than a non-disgusting, significantly delayed fix. So, how would Mozilla and the NSS Team feel about committing Nelson's 2 patches? [1] https://bugzilla.mozilla.org/attachment.cgi?id=366236 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=482153#c1 [3] https://bugzilla.mozilla.org/attachment.cgi?id=366225 P.S. An alternative idea, for which I am willing to write a patch (if you think this would be preferable to Nelson's disgusting hack): - Define a certHashesToAvoidUsing[] array in nssCertificateArray_FindBestCertificate(). Populate this array with the hashes of all of the UTN-AddTrust and AddTrust-UTN cross-certificates. Make the code consult this list: if a match is found, do not consider this cert to be the best match. P.P.S. 2 other ideas which didn't appear to work... 1. I tried adding the affected UTN--AddTrust cross-certificates as distrusted built-ins, but this didn't help. Presumably distrust is only evaluated after the best certificate chain has been chosen, rather than during the process of chain selection. 2. I tried removing one of the affected UTN root-certificates and then adding the relevant AddTrust-UTN cross-certificate as a built-in. This didn't work either, presumably because the UTN root-certificate was for some reason still listed as a Software Security Device. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Is there an ETA yet for when Firefox will use libpkix by default?
Brian, It has been well over 3 years since the cross-certification looping bug described in Bug #479508 and Bug #634074 was first filed. It was decided that the proper fix was to wait for Firefox to migrate to libpkix by default. We and our customers have been waiting patiently for this fix. The effects of this bug have apparently been getting worse over time, and we don't believe that we can tolerate it for very much longer. Might there be a Firefox 13.x point-release that will enable libpkix by default? Will Firefox 14 enable libpkix by default? Or can you say that enabling libpkix by default will definitely not happen until Firefox 15 or later? If you're reasonably sure it won't happen by Firefox 14, my CTO has asked me to urgently i) attempt to write an ugly kludge of a patch to fix the bug in the old certificate verification library and then ii) petition Mozilla and the NSS team to accept my patch and ship it in Firefox 14 or sooner. Thanks. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
FYI, Adam Langley told me The hope is that everything is 100KB. I asked him if I could share that figure here and he just replied No problem. It's not a strict limit that we set and we'll have to see how well we do. We've calculated that there are currently ~53,000 revoked Server Authentication certs that were issued by Comodo's CA systems, each with a serial number of 16 bytes (+ a leading zero byte if required to ensure it's not treated as a negative number). That adds up to well over 800KB. And obviously we're not the only CA! On 08/02/12 22:18, Nelson B Bolyard wrote: On 2012/02/08 12:57 PDT, Kai Engert wrote: My criticism: [snip] Won't the set of CRLs be too big for download? [snip] This is my question as well. Will they really include the CRLs from all of mozilla's trusted CAs? Won't the union of all those CRLs be huge, even if they strip off certain reason codes? -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Google about to fix the CRL download mechanism in Chrome
On 09/02/12 13:10, Gervase Markham wrote: On 09/02/12 12:54, Rob Stradling wrote: We've calculated that there are currently ~53,000 revoked Server Authentication certs that were issued by Comodo's CA systems, each with a serial number of 16 bytes (+ a leading zero byte if required to ensure it's not treated as a negative number). That adds up to well over 800KB. And obviously we're not the only CA! Which is why he's obviously not going to transmit the information as a list of serial numbers :-) Actually, he is. He's probably planning something vaguely like this: http://en.wikipedia.org/wiki/Bloom_filter I know Adam was looking at Bloom filters and related techniques last year [1], but I understand that he abandoned those approaches. I'm not sure why. The current CRLSet format is described in the Chromium source code [2] (search for CRLSet format). Also, he's published a tool for downloading and parsing CRLSets [3]. [1] http://www.imperialviolet.org/2011/04/29/filters.html [2] http://src.chromium.org/viewvc/chrome/trunk/src/net/base/crl_set.cc?revision=97640view=markup [3] https://github.com/agl/crlset-tools Gerv -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure
On 08/02/12 12:43, Ondrej Mikle wrote: On 02/07/2012 09:58 PM, Kai Engert wrote: snip That's a reason why I propose vouchers to be IP specific. In my understanding, each IP will have only a single certificate, regardless from where in the world you connect to it. It's not true in general. There are services hidden with a load-balancer behind a single IP. An example - 3m.com: Also, a TLS Server might choose a different cert depending on the cipher suite list provided by the TLS client. e.g. $ openssl s_client -connect tls.secg.org:40023 -cipher RSA 2 /dev/null | grep Certificate chain -A 3 Certificate chain 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Server Certificate/C=CA i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org RSA 1024 Certificate Authority/C=CA --- vs $ openssl s_client -connect tls.secg.org:40023 -cipher ECDSA 2 /dev/null | grep Certificate chain -A 5 Certificate chain 0 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/ST=Ontario/CN=tls.secg.org ECC secp256r1 Server Certificate/C=CA i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate Authority/C=CA 1 s:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate Authority/C=CA i:/OU=SAMPLE ONLY/O=Certicom Corp./L=Toronto/SN=Ontario/CN=tls.secg.org ECC secp256r1 Certificate Authority/C=CA --- AFAIK, such configurations are not widespread today, but this would change if/when ECC certs start to be used more widely. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
OCSP-in-DNS (was Re: For discussion: MECAI: Mutually Endorsing CA Infrastructure)
On Wednesday 07 Dec 2011 04:19:09 Kai Engert wrote: snip I haven't researched, but has anyone already thought of distributing OCSP records using DNS in general? If we had OCSP-in-DNS, we might not even require OCSP stapling. This could run as a service completely independent of the SSL servers - only clients would need to be updated to fetch OCSP from DNS - does this make sense? Hi Kai. We discussed OCSP-in-DNS over at m.d.s.policy earlier this year... https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/a5f14bbd3159c44f/446abd478dc847ec (it's a long thread, but it does contain a lot of useful thoughts) Recalling that discussion, Gerv recently said... https://mail1.eff.org/pipermail/observatory/2011-September/000405.html ...the arguments for something DNS-based are IMO very strong (much better privacy story, very hard to DOS, cached and distributed). Peter Gutmann lists numerous deficiencies with the OCSP protocol - e.g. see here... https://mail1.eff.org/pipermail/observatory/2011-September/000330.html I think that any future DNS-based certificate status checking protocols should at least consider addressing some of these issues. snip Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote: snip - OCSP and CRLs are unnecessary with DANE Steve, may we presume that you only intended this statement to apply to the use of self-signed certs with DANE? When an EV (or OV) certificate issued by a third-party CA is used with DANE, I would argue that OCSP and CRLs are still essential, because these certificates make claims (about organizational identity) that can't be assured by DNS(SEC)/DANE. When a DV certificate issued by a third-party CA is used with DANE, I would argue that OCSP and CRLs may be less than essential but they are still useful (e.g. the CA may subsequently detect that the key or hash algorithm used in the certificate is weak). Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Domain-validated name-constrained CA certificates?
On Tuesday 06 April 2010 10:54:49 Jean-Marc Desperrier wrote: Matt McCutchen wrote: An extended key usage of TLS Web Server Authentication on the intermediate CA would constrain all sub-certificates, no? You are here talking about a proprietary Microsoft extension of the X509 security model. Mozilla has its own proprietary certificate extension (Netscape Cert Type) that (IINM) can be used to achieve the same outcome (by setting the SSL CA bit). http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html has some old notes from Nelson. AFAIK, this extension is still supported by NSS, but having said that I wouldn't be surprised if Nelson replies to this message with words to the effect of that extension is deprecated, so please don't use it any more! Rob Stradling Senior Research Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Basic ECC in NSS 3.12.4 with NSPR 4.8
Frank, I'm pretty sure you meant to say Certicom (who are now owned by RIM) rather than Entrust. (Perhaps you were thinking of Entrust's CRL Distribution Points patent, a license for which was granted to Mozilla relatively recently?) Certicom have said that their desire is to facilitate the wide-scale adoption and proliferation of Elliptic Curve Cryptography (ECC) technology and that they will, upon request, provide a nonexclusive, royalty free patent license, to manufacturers to permit end users (including both client and server sides), to use the patents... https://datatracker.ietf.org/ipr/1154/ http://www.certicom.com/images/pdfs/certicom%20-ipr-contribution-to- ietfsept08.pdf Does anybody know if Mozilla/NSS has actually requested and obtained a nonexclusive, royalty free patent license from Certicom/RIM? On Tuesday 03 November 2009 18:49:57 Frank Hecker wrote: David Stutzman wrote: Rob Stradling wrote: A question for the NSS devs: Is there any reason why NSS couldn't be changed to assume NSS_ENABLE_ECC=1 by default? Yes... http://fedoraproject.org/wiki/User:Peter/Disabled_applications Disabled features: Elliptic Curve crypto algorithm Reasons: software patents and US Laws (?) I think these reasons are out of date and not applicable. Re patents, Entrust freely licensed enough of their ECC-relevant patents to permit it to be implemented in NSS (though IIRC Entrust retains rights to certain ECC-related patent, which is why the NSS implementation doesn't include as many ECC features as it otherwise might). Re US laws, to my knowledge there are no US laws or regulations that would specifically affect ECC as opposed to other encryption mechanisms. US encryption export control regulations don't distinguish between ECC and (e.g.) RSA, AES, etc., and have permitted export of open source encryption code since 2000 or so. Frank Rob Stradling Senior Research Development Scientist C·O·M·O·D·O -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Basic ECC in NSS 3.12.4 with NSPR 4.8
On Tuesday 03 November 2009 13:42:14 David Stutzman wrote: snip Some linux distributions distribute NSS built without ECC support, like Fedora. Red Hat, on the other hand, distributes NSS sort of how Java 1.6 is. It suppports ECC but itself has no ECC implementation and you must add in a third party PKCS#11 module to gain working ECC. So Fedora ignores it, and RHEL makes it relatively easy to integrate it. snip I also just tested EC keygen using certutil and EC SSL on both Gentoo ($Header: NSS 3.12.4.5 Basic ECC Sep 28 2009 07:58:40 $) server and OpenSuse 11.1. Both worked fine out of the box. Hi David. Gentoo's NSS package supports ECC because I asked them to enable it: http://bugs.gentoo.org/247221 I don't think it was ever a deliberate decision on their part to not enable it previously. They raised no objections to my request. Perhaps Fedora and other distros would also be happy to enable ECC by default in NSS if somebody would simply ask them to do so. A question for the NSS devs: Is there any reason why NSS couldn't be changed to assume NSS_ENABLE_ECC=1 by default? So to tie all this gibberish to the thread, the OP *shouldn't* need a third party ECC library to do what he is attempting to do (as evidenced by the Windows, Gentoo and OpenSUSE builds of NSS). I know I've had previous dealings with many of you before on this topic and don't take this as complaining...just trying to put the info out there and understand the what's and why's. I appreciate all the hard work you do. Dave PS Nelson, I've been trying to email you directly and haven't been getting any responses. Rob Stradling Senior Research Development Scientist C·O·M·O·D·O - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Basic ECC in NSS 3.12.4 with NSPR 4.8
On Tuesday 03 November 2009 14:29:43 Rob Stradling wrote: On Tuesday 03 November 2009 13:42:14 David Stutzman wrote: snip Hi David. Gentoo's NSS package supports ECC because I asked them to enable it: http://bugs.gentoo.org/247221 I don't think it was ever a deliberate decision on their part to not enable it previously. They raised no objections to my request. FYI, the story was apparently very similar with Ubuntu and Debian: https://bugs.launchpad.net/ubuntu/+source/nss/+bug/232392 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490826 All it needed was somebody to ask them to set NSS_ENABLE_ECC=1 by default in their NSS packages. snip Rob Stradling Senior Research Development Scientist C·O·M·O·D·O - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Roots that are identical except for signature algorithm and serial number
Frank, Nelson, just in case it's useful... I recall that GlobalSign recently refreshed their GlobalSign Root CA: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 When the new GlobalSign Root CA certificate (which expires in 2028) was added to NSS, the old certificate (which expires in 2014) was *removed*: https://bug449883.bugzilla.mozilla.org/attachment.cgi?id=333011 I presume that GlobalSign have not encountered any problems following the removal of their old certificate from NSS. On Friday 22 May 2009 15:24:47 Frank Hecker wrote: Nelson Bolyard wrote: On 2009-05-20 13:58, Kathleen Wilson wrote: When processing a cert chain, does Mozilla use a specified algorithm/ order for determining which root to use when there are two roots included that are identical except for signature algorithm and serial number? The algorithm for choosing from among multiple certs with the same subject name and key ID generally involves picking the newest one. When multiple certs have the same exact notBefore and notAfter dates, the order is determined by the certs' relative positions in the cert cache, which is effectively unpredictable. So, for purposes of this discussion, the short answer to your question is: no. So, just to clarify: I *think* you're proposing that we do the following in cases where CAs issue new root certificates with stronger signature algorithms (e.g., upgrading MD2 or MD5 roots to use SHA-1): 1. We should keep the old root certificates in the root list, at least for now. Rationale: It does no harm to keep the old roots, since we do not check signatures on roots, and it may prevent possible errors when Firefox, Thunderbird, etc., receive a full cert chain that includes the old root. 2. We should encourage CAs to issue the new replacement roots with notBefore and notAfter dates that are later than the corresponding dates for the old roots. Rationale: This ensures that NSS will deterministically select the newer root in cases where there is a choice to be made. (Does this include the case when Firefox, etc., receive a full cert chain that includes the old root?) Is the above a correct reading of your comments? Frank -- Frank Hecker hec...@mozillafoundation.org -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Thanks for your thoughts Nelson. There's one big problem with this idea of a certificate extension for additional signatures, which I hadn't thought of before (Thanks to Paul H for spotting it!)... For the additional signature(s) to become especially useful, the primary signature on the certificate would need to be substantially broken (e.g. by a pre-image attack on the hash algorithm). But if this happened, it is likely that the CA would revoke the certificate. Once the certificate is revoked, it's...errr...revoked. The additional signature(s) extension would simply be ignored. On Monday 19 January 2009 22:07:46 Nelson B Bolyard wrote: Rob Stradling wrote, On 2009-01-14 03:24 PST: To the NSS developers: If there existed a standardized certificate extension in which a CA could put additional signatures using different algorithms, do you think you'd consider adding support for it to NSS? Yes, I think the NSS team would consider it, if it really was a standard, at least an IETF RFC. If yes, might you do this before it was widely supported by CAs, or do you think you'd wait for the majority of CAs to start using it first? I think that largely depends on who does the work. If someone contributed a patch to NSS that implemented it, and was quite complete (including changes to test tools and test scripts), and didn't require much work at all to go in, I think it might go in basically as soon as it was standard. The contribution of the Japanese Camellia cipher was an example of a very well done contribution that went right in. But if the NSS must develop it, or if a contributed patch is incomplete or requires a lot of work that the contributor is unwilling or unable to do, then prioritizing and scheduling that work involves factors such as the priorities of the sponsors of NSS development. Looking at the new developments in standards of the last few years, we see a list of standardized features that are thought to be important by various members of the crypto community, but which are not yet available in NSS. To name just a few, there are TLS 1.2, AES GCM, OCSP stapling, server support for SNI. Together they constitute a pretty large back log of development waiting to be done. Another new proposal would contend with those for resources. Not all of the features that have been added to NSS in the last few years have been widely adopted by the applications that use NSS. Consequently, the sponsors are now evaluating possible future developments based on their projections for the demand of application developers for those features. I think that says that if they see a groundswell of demand from the application developers for a new feature such as multiple signatures in a certificate, they might go for it, but otherwise, it is likely to languish, IMO. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Tuesday 13 January 2009 15:47:22 Paul Hoffman wrote: At 3:31 PM + 1/13/09, Rob Stradling wrote: Why almost every piece of PKIX validating software ? I think it would be worth it if, at a minimum... - the majority of CAs added the extension to the certificates they issue, and... - Mozilla implemented support for the extension in NSS. This would allow Mozilla to disable a weak algorithm quickly, without having to wait for the majority of certificates in the wild to stop using that algorithm for their main certificate signature. Fair enough. I think the biggest barrier to adoption would be convincing enough of the CAs to implement it. Really? :-) But perhaps the Mozilla CA Certificate Policy could be updated to require CAs to implement it? That seems kind of drastic for an extension that would only help on a security issue that has never been met True. That is, the extension will only be useful for hash functions for which practical pre-image attacks are discovered, or signature functions that quickly become drastically weaker than expected. It's like an insurance policy. CAs and PKIX validating software would pay a premium (i.e. development effort required to support the proposed certificate extension), but would hope that they never need to make a claim. I still think it is sufficient for the policy to list the acceptable signing algorithms of the day. If the extension is standardized and is used by any CAs, and if NSS implements it and allows Firefox to be able to shut off one of multiple algorithms in the extension, that would help the CAs who used the extension. if NSS implements it. To the NSS developers: If there existed a standardized certificate extension in which a CA could put additional signatures using different algorithms, do you think you'd consider adding support for it to NSS? If yes, might you do this before it was widely supported by CAs, or do you think you'd wait for the majority of CAs to start using it first? -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Friday 09 January 2009 02:04:59 Julien R Pierre - Sun Microsystems wrote: On Friday 09 January 2009 04:32:41 Ben Bucksch wrote: snip Can we create another extension? The signature itself is a shell around the certified bits. Add the second signature around that first signature. There must be a way to add signatures. It's a base feature in PGP! If it's entirely impossible to have two signatures, and no way to add it to the spec, that's a design error. It's hard to believe that it's so limited. If one wanted to have another signature, it wouldn't be as an extension, since, as Nelson pointed out, extensions are part of what gets signed. The current single signature is not an extension. Well, I guess somebody did it anyway : http://www.freepatentsonline.com/y2008/0270788.html sigh. Ben, Julien, That IBM patent application does not yet appear to have been reviewed and either granted or rejected. I made a similar suggestion to ietf.pkix in October 2006. See... http://www.imc.org/ietf-pkix/mail-archive/msg01964.html ...and the rest of that thread, including... http://www.imc.org/ietf-pkix/mail-archive/msg01984.html IANAL, but I think this should be sufficient prior art against the main claims in the IBM patent application. Ben, I agree that having multiple signatures in a certificate could be useful. If, for example, the certificates in the wild today contained both MD5/RSA and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support *today* without breaking the internet, as long as the majority of relying party software could process the additional signatures. If the industry chose to introduce such a thing now, it could help us all in the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to SHA-3, etc. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Thanks Ben. Perhaps it's time to have another go at canvassing support for the idea. In 2006, the PKIX WG didn't seem interested in tackling the problem I was trying to solve. Paul, do you think it's worth re-raising this idea with the PKIX WG ? On Tuesday 13 January 2009 09:39:06 Ben Bucksch wrote: On 13.01.2009 09:48, Rob Stradling wrote: I made a similar suggestion to ietf.pkix in October 2006. See... http://www.imc.org/ietf-pkix/mail-archive/msg01964.html ...and the rest of that thread, including... http://www.imc.org/ietf-pkix/mail-archive/msg01984.html ... Ben, I agree that having multiple signatures in a certificate could be useful. If, for example, the certificates in the wild today contained both MD5/RSA and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support *today* without breaking the internet, as long as the majority of relying party software could process the additional signatures. If the industry chose to introduce such a thing now, it could help us all in the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to SHA-3, etc. Rob, I think that's an excellent suggestion. Not only because it allows more advanced trust management, but also, as you point out, because it eases the transition away from SHA-1 significantly, which I think will be very important and may shorten the transition by years. I think your proposal is nice, as it would allow to use the existing extension mechanism, which means that it doesn't break current browsers. Also, given that software will have to be changed anyways to support SHA-2 or whatever, and we'll eventually use only that, I think there's - in addition to the backwards-compatible way you propose - a chance to introduce a new format which supports several signatures in a straightforward way, and also other improvements which were hindered by backwards-compatibility. Greetings, and thanks a lot! Ben ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
Why almost every piece of PKIX validating software ? I think it would be worth it if, at a minimum... - the majority of CAs added the extension to the certificates they issue, and... - Mozilla implemented support for the extension in NSS. This would allow Mozilla to disable a weak algorithm quickly, without having to wait for the majority of certificates in the wild to stop using that algorithm for their main certificate signature. I think the biggest barrier to adoption would be convincing enough of the CAs to implement it. But perhaps the Mozilla CA Certificate Policy could be updated to require CAs to implement it? On Tuesday 13 January 2009 14:50:32 Paul Hoffman wrote: At 9:55 AM + 1/13/09, Rob Stradling wrote: Thanks Ben. Perhaps it's time to have another go at canvassing support for the idea. In 2006, the PKIX WG didn't seem interested in tackling the problem I was trying to solve. Paul, do you think it's worth re-raising this idea with the PKIX WG ? Dunno. The WG seems willing to take on anything that will keep it alive longer. On the other hand, even if your spec is accepted by the WG, I highly doubt you will get enough implementation to make it worth your time. That is, unless almost every piece of PKIX validating software added the extension, it wouldn't really add much value. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
and required by EV ? Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when* they are used, but AFAIK they don't mandate that Intermediate CAs MUST be used. Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without involving any Intermediate CA(s) in the certificate chain. On Monday 12 January 2009 10:28:42 Eddy Nigg wrote: On 01/12/2009 11:56 AM, Jean-Marc Desperrier: Eddy Nigg wrote: [...] No exception can be added for revoked certificates, but for expired ones it's possible - hence it suggests that revocation is more severe than expired (if one can think in those terms). Or how would you explain that? As I have already found myself in the situation of really needing to override an expired certificate, I beg to differ and find an explanation. In the case of revoked certificates, you have positive proof that the CA wants that cert to be revoked. Indeed! That was the point I was trying to make (and why i believe that expired but revoked certificates should never be removed from the CRL). Considering that intermediate CAs are more and more common and the encouraged practice anyway (and required by EV), those CRLs shouldn't grow that badly until the issuing CA certificate expires. As Julien also mentioned, some CAs keep the revoked certs for a period of N years in the CRL - with intermediates assumed limited life-time, we aren't really far from that. In the case of expired certificates, you just don't know. So it leave the possibility that you have out of band information that the key is not compromised and that you should be able to access the site. Yes, I view an expired certificate differently than a revoked one. There are indeed situations which require to access a site with an expired cert. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Monday 12 January 2009 11:00:59 Eddy Nigg wrote: On 01/12/2009 12:45 PM, Rob Stradling: and required by EV ? Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when* they are used, but AFAIK they don't mandate that Intermediate CAs MUST be used. Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without involving any Intermediate CA(s) in the certificate chain. Did just thatand this site's certificate is signed by SecureTrust CA which chains to Entrust.net Secure Server Certification Authority. The Entrust.net Secure Server Certification Authority is used for legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in FF3 (and other EV-capable browsers) because the SecureTrust CA self-signed Root Certificate is enabled for EV. That's why Larry says Verified by: SecureTrust Corporation, rather than Verified by: Entrust, Inc. for https://www.securetrust.com. But besides that, it's perhaps not clearly defined in the EV Guidelines, but section 7 suggests that there are no roots issuing directly. I disagree. Section 7 says that EV Subordinate CA Certificates may exist, and it imposes some restrictions relating to Certificate Policy OIDs. But it does not say that Root CA Certificates should not be used for issuing end-entity EV Certificates. In fact, it says... The Application Software Vendor identifies Root CAs that are approved to issue EV Certificates... ...which surely cannot mean Root CAs are not approved to issue EV Certificates ! -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Suggestion: Announce date for MD5 signature deactivation
Eddy, I apologize if I'm misinterpreting your response to Paul's last comment, but I think you are suggesting that Mozilla could hold a CA to doing something that is 'currently in the 'problematic practices' wiki page, purely because that wiki page is a document that is (you allege) presented to every CA for a while already. If that is what you are saying, I disagree with you. The wiki page clearly says (capitalization mine)... - POTENTIALLY problematic CA practices. - we do NOT NECESSARILY consider them security risks. - Some of these practices MAY be addressed in future versions of the policy. If Mozilla want to hold a CA to doing something, then IMHO the first step towards achieving this has to be to update the Mozilla CA Certificate Policy to explicitly cover that something. The wiki page discusses *possible* *future* policy only. On Saturday 10 January 2009 20:10:35 Eddy Nigg wrote: On 01/10/2009 08:59 PM, Paul Hoffman: That's absurd. You can't hold a CA to doing something that we don't document. Just a by-note on this one...It doesn't have to be in the CA Policy, but may be also in some by-laws or as we have it currently in the problematic practices. This document is presented to every CA for a while already, so the CAs know about it, even if it's not part of the policy itself. Perhaps a better mechanism regulating these aspects might be useful too. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Monday 12 January 2009 12:10:17 Eddy Nigg wrote: On 01/12/2009 01:20 PM, Rob Stradling: The Entrust.net Secure Server Certification Authority is used for legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in FF3 (and other EV-capable browsers) because the SecureTrust CA self-signed Root Certificate is enabled for EV. I can't find the SecureTrust CA request for enabling EV. It's not on the pending list, not on the included list, nor could I find bug for it... anybody know where the paper trail is for this CA? https://bugzilla.mozilla.org/show_bug.cgi?id=409837 That's why Larry says Verified by: SecureTrust Corporation, rather than Verified by: Entrust, Inc. for https://www.securetrust.com. I'm almost certain that the Verified by usually lists the last CA certificate in the chain. At least for regular SSL certs. Ah yes, you may well be right. I was probably thinking of IE7's equivalent behaviour. In any case, if you compare the EV Policy OIDs mentioned in Bug #409837 (SecureTrust) and Bug #416544 (Entrust) with the EV Policy OID in the site certificate for www.securetrust.com, you'll see that it's the SecureTrust CA which gives that site the EV UI. I disagree. Section 7 says that EV Subordinate CA Certificates may exist, and it imposes some restrictions relating to Certificate Policy OIDs. But it does not say that Root CA Certificates should not be used for issuing end-entity EV Certificates. In fact, it says... The Application Software Vendor identifies Root CAs that are approved to issue EV Certificates... ...which surely cannot mean Root CAs are not approved to issue EV Certificates ! Than this is another issue to suggest change. Perhaps I wanted it to read that EV roots which are approved to issue EV certs, but issuing from intermediate - as most CAs actually have done so. That includes Verisign (most notable) which transitioned to issuing from intermediate's a while ago. Mozilla doesn't enable intermediate CAs, it enables roots, even if only one intermediate issues EV and the root never does directly. Just because VeriSign use Intermediates for EV, I don't think that means that Mozilla should require CAs such as SecureTrust to do the same. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Suggestion: Announce date for MD5 signature deactivation
Eddy, I agree that the Potentially Problematic Practices wiki page is a useful resource during the information gathering period that happens *before* a Root Certificate is ever accepted by Mozilla. But (reading back a few messages in this thread), the context of this discussion is Paul's proposal of a retroactive change to its (Mozilla's) acceptance policy in the pile in order to curtail the use of MD5 by CAs who have *already* been accepted by Mozilla. Are you saying that Mozilla could change the Potentially Problematic Practices wiki page, and then use non-compliance to anything on that page as grounds for pulling a previously approved Root Certificate from the trust pile? On Monday 12 January 2009 11:26:03 Eddy Nigg wrote: On 01/12/2009 01:08 PM, Rob Stradling: Eddy, I apologize if I'm misinterpreting your response to Paul's last comment, but I think you are suggesting that Mozilla could hold a CA to doing something that is 'currently in the 'problematic practices' wiki page, purely because that wiki page is a document that is (you allege) presented to every CA for a while already. If that is what you are saying, I disagree with you. The wiki page clearly says (capitalization mine)... - POTENTIALLY problematic CA practices. - we do NOT NECESSARILY consider them security risks. - Some of these practices MAY be addressed in future versions of the policy. If Mozilla want to hold a CA to doing something, then IMHO the first step towards achieving this has to be to update the Mozilla CA Certificate Policy to explicitly cover that something. I absolutely agree with you and in my opinion this is what should be done - at least for some of those practices. However as I understand, not everything is every time clear so cut to make it a policy, hence there are problematic practices which are reviewed on a case-to-case basis for every CA individually. Confronting the CA with this page early on during the information gathering period makes the CA aware of potential problems during the process. This is what happened for a while now. I think that not every bit and byte must be listed in the policy, but by-laws may exists to assist the intend of the policy. Instead I think the policy should mention that such by-laws may exists - as matter of fact section 4 deals with it more or less. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Cert expiry with Key Continuity Management
On Monday 12 January 2009 13:07:17 Eddy Nigg wrote: snip I would go as far and require it, simple as that. You are entitled to your opinion. That should be really an issue for the CAB forum however. So why don't you join the CA/Browser Forum and share your opinion? BTW, my point wasn't *because* of Verisign, but *even* Verisign does it ;-) OK. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Suggestion: Announce date for MD5 signature deactivation
On Monday 12 January 2009 13:30:35 Kyle Hamilton wrote: I believe that this is not only exactly what he is saying, but also exactly what must be done. Once a potentially problematic practice is shown to have moved from potential to actual, it is a problematic practice. Once that happens, it must be addressed. I fully agree. Right now, as I see it, we have... 1). potential - The Potentially Problematic Practices wiki page. 2). actual - The Mozilla CA Certificate Policy. So when a problem is shown to have moved from 'potential' to 'actual', surely the way to address it would be to update the Mozilla CA Certificate Policy and require CAs to conform to the new version (or risk having their Root(s) pulled) ? CAs fall into a class of security called operational security. This means, among other things, that their operations -- inputs, black-box certification procedure, and outputs -- are subject to continual attack. Once a viable attack has been exhibited, mitigations against attack must be revisited with that attack in mind -- and if they are insufficient, new mitigations must be applied retroactively. (If an attack currently takes 8+ months to pull off, that just means that in less than 2 years it's going to take on the order of 4 months, in less than 2 years after that it's going to take on the order of 2 months, and in less than 2 years after that it's going to take on the order of 1 month -- assuming that there's no change in the understanding of the underlying mathematics. This is in keeping with the corollary to Moore's Law, that processing power doubles every 18 months, which lately seems to be maintained even in the face of heat problems inherent with doubling the number of transistors on a die.) Yes, this does mean that new requirements could require operational changes in some/all roots, or risk de-acceptance. If a CA's operations are not secure (due to input, processing, or output), how can anyone put any trust in them? -Kyle H On Mon, Jan 12, 2009 at 5:07 AM, Rob Stradling rob.stradl...@comodo.com wrote: Eddy, I agree that the Potentially Problematic Practices wiki page is a useful resource during the information gathering period that happens *before* a Root Certificate is ever accepted by Mozilla. But (reading back a few messages in this thread), the context of this discussion is Paul's proposal of a retroactive change to its (Mozilla's) acceptance policy in the pile in order to curtail the use of MD5 by CAs who have *already* been accepted by Mozilla. Are you saying that Mozilla could change the Potentially Problematic Practices wiki page, and then use non-compliance to anything on that page as grounds for pulling a previously approved Root Certificate from the trust pile? On Monday 12 January 2009 11:26:03 Eddy Nigg wrote: On 01/12/2009 01:08 PM, Rob Stradling: Eddy, I apologize if I'm misinterpreting your response to Paul's last comment, but I think you are suggesting that Mozilla could hold a CA to doing something that is 'currently in the 'problematic practices' wiki page, purely because that wiki page is a document that is (you allege) presented to every CA for a while already. If that is what you are saying, I disagree with you. The wiki page clearly says (capitalization mine)... - POTENTIALLY problematic CA practices. - we do NOT NECESSARILY consider them security risks. - Some of these practices MAY be addressed in future versions of the policy. If Mozilla want to hold a CA to doing something, then IMHO the first step towards achieving this has to be to update the Mozilla CA Certificate Policy to explicitly cover that something. I absolutely agree with you and in my opinion this is what should be done - at least for some of those practices. However as I understand, not everything is every time clear so cut to make it a policy, hence there are problematic practices which are reviewed on a case-to-case basis for every CA individually. Confronting the CA with this page early on during the information gathering period makes the CA aware of potential problems during the process. This is what happened for a while now. I think that not every bit and byte must be listed in the policy, but by-laws may exists to assist the intend of the policy. Instead I think the policy should mention that such by-laws may exists - as matter of fact section 4 deals with it more or less. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual
Re: OCSP bypass in recent demo/exploit
Looking at the http://www.win.tue.nl/hashclash/rogue-ca/ attack specifically... The Equifax Secure Global eBusiness CA-1 self-signed Root Certificate trust anchor does *not* contain the Authority Info Access extension or CRL Distribution Points extension. The Rogue CA Certificate does *not* contain the Authority Info Access extension or CRL Distribution Points extension. (The legitimate certificate that has the same signature as the Rogue CA Certificate does contain the CRL Distribution Points extension, but that's irrelevant). So, with zero potentially suitable CRL/OCSP URLs available, this surely means that that Rogue CA Certificate is essentially *unrevokable* by normal means, and that any certificates issued by the Rogue CA Certificate are essentially *unrevokable* by anyone other than the attacker. The CA (RapidSSL) could have thwarted the attack by using a stronger hash algorithm, or by generating random certificate serial numbers instead of guessable sequential ones. I think it's sensible to expect this attack on MD5 to be repeated by other attackers, and to expect a similar attack on SHA-1 in the future. Therefore, we should consider putting in place some safeguards now. Some ideas: Perhaps the Mozilla CA Certificate Policy could mandate that all CAs must (after a certain date) generate long, randomized certificate serial numbers? Perhaps the NSS code could reject (after a certain date) certificates with short serial numbers, on the assumption that they are sequential and therefore potentially guessable? (Perhaps future updates to RFC5280 and the CABForum EV Guidelines could recommend or require long, randomized certificate serial numbers as well?) On Tuesday 06 January 2009 01:31:55 Paul Hoffman wrote: At 4:01 PM -0800 1/5/09, Nelson B Bolyard wrote: Paul Hoffman wrote, On 2009-01-05 08:54: At 3:09 PM +0100 1/5/09, Ian G wrote: [...] Hence, once we rogue-players have created a certificate like this, the CA cannot revoke it using its own control mechanisms. [...] I am not convinced the article is correct. If it is correct, it is a serious but easily-fixed bug in IE. That is, if a trust anchor contains a AIA that points to an OCSP responder, and the rogue sub-CA has an AIA that points to a different OCSP responder, the validation process should should check the OCSP of the trust anchor. I'm surprised that you wrote that, for several reasons. Let me explain some of them. For brevity, I will use the following terms: child - the cert whose revocation we want to check parent - the cert for the CA that issued the child cert sibling - another cert issued by the same parent CA grandparent - the cert for the issuer of the parent cert. Everything I write below about OCSP is also true for CRLs, IINM. 1) It's not generally true that you can use the OCSP URL in the parent cert to check the OCSP status of a child cert. This is because it is not generally the case that the issuer of the child is also the issuer of the parent (that is, that parent == grandparent, parent is a root). 2) It's also not generally true that you can use the OCSP URL in a sibling to check the OCSP status of a child. This is because the parent may have multiple OCSP responders and may use different responders for different certs that it issues. Indeed, the parent could put a unique OCSP URL into every cert it issues. 3) A corollary of (2): Even when parent == grandparent, and hence parent is also a sibling, it's not generally true that you can use the OCSP URL from the parent to check the OCSP status of a child. All of that is true (and is true for CRLs, I believe), but it is not what I was speaking to. The recent MD5 attack creates a rogue sub-CA, that is a new child of one of your trust anchors. The Microsoft article made it sound (to me, at least) that if the rogue sub-CA (the child) has a AIA, then IE will not look in the parent's AIA to determine the status of the child. If that's true, it is broken. Each level of the family can have its own AIA that applies to all of its children, not just to end entities. 4) Trust anchors are not necessarily roots. Of course. I'm not seeing where that is relevant here, but I could be missing something. 5) Most roots don't have AIA cert extensions. Only 8 out of the 125 roots in nssckbi have them. Now *that* is sad. I was hoping for closer to 50%. It does not make my argument wrong, just pretty moot. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road
Re: Words from Comodo?
On Monday 29 December 2008 13:50:58 Eddy Nigg wrote: There is now an interest article at the register: http://www.theregister.co.uk/2008/12/29/ca_mozzilla_cert_snaf/ snip Interesting that Comodo founded the CAB forum and Comodo created a standard for domain control validation. I wonder where exactly? This might be reason to join the CAB forum? Eddy, assuming Startcom meets the CABForum's membership requirements (see http://www.cabforum.org/forum.html), I would definitely encourage you to apply to join. This would allow you to contribute to the minimum standards for domain validation initiative mentioned by that Reg article. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: MD5 irretrievably broken
On Tuesday 30 December 2008 22:07:08 Kyle Hamilton wrote: I would suggest requiring all new roots approved to state that they do not and will not use MD5 in any newly-minted certificate (except possibly in a configuration like the TLS pseudo-random function). FWIW, Comodo have never signed (and we will never sign) any certificates with MD2, MD4 or MD5. Also, since we launched our CA business, we've always generated random certificate serial numbers. This is not yet policy, though it should be. (FWIW, this was known two years ago.) -Kyle H On Tue, Dec 30, 2008 at 8:39 AM, Chris Hills c...@chaz6.com wrote: A presentation was given at this year's Chaos Communication Congress in which it was described how researchers were apparently able to produce authentic signed SSL certificates thanks to a handful of CAs who rely on MD5. If true, is it time to disable MD5 by default? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Words from Comodo?
On Tuesday 30 December 2008 22:22:11 Gervase Markham wrote: Ian G wrote: As far as I heard, the CABForum was also formed or inspired from a similar group of vendors (browsers) that got together at the invite of the Konqueror guy to talk about phishing one day ... I'm fairly sure it wasn't at the invitation of the Konqueror guy (George Staikos), but a CA-led initiative right at the very beginning. But my memory could be failing me, or there could have been meetings I didn't know about. Gerv, your memory is correct. Comodo instigated and hosted an Industry Round Table on May 17th 2005, inviting various CAs and Browser reps to attend. This meeting led directly to the formation of the CABForum. Comodo's intention was to stop the race to the bottom and to restore the value of the browser padlock by creating an industry standard for IV/OV and by persuading the browsers to differentiate between DV and IV/OV. (I just tried to post this same message with a PDF attachment containing the invitation to the Industry Round Table, but it appears that that message was blocked). Question for now: is the CABForum still a closed group? Depends what you mean by 'closed'. There are membership criteria, and anyone who fits the criteria can be a member. See the bottom of this page: http://www.cabforum.org/forum.html Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SECOM Trust EV root inclusion request
On Saturday 06 December 2008 06:33:13 Frank Hecker wrote: snip * SECOM Trust doesn't currently support OCSP. OCSP is not (yet) mandatory for EV, so this is not an issue from a policy perspective. IIRC this will not pose a technical problem either, as long as EV certs issued by SECOM Trust don't have an AIA extension with OCSP URL. That assumes that https://bugzilla.mozilla.org/show_bug.cgi?id=413997 will not be implemented before such time as SECOM Trust do start to support OCSP. * SECOM Trust had one caveat on their EV audit, having to do with their not performing certain background checks on staff. As noted in Kathleen Wilson's summary document (attached to the bug), this is apparently a side-effect of Japanese laws and regulations, and not a substantive problem. I suggest reading Kathleen's summary document to get an overview of this request; thanks again to Kathleen for preparing these! For this request and subsequent requests I'm going to adopt a suggestion made by Eddy a little while back: Rather than having a two-week discussion period divided into two phases, I'm going to have a single one-week discussion period. After that week, if there are no outstanding issues relating to the request then I am going to go ahead and officially approve it. However if there are outstanding issues that in my opinion are relevant, then I'm going to postpone further consideration of the request. This will allow time to try to get the issues resolved, after which we can start a new public discussion period. Frank -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Creating a Global User-level CA/Trust Infrastructure forSecureMessaging
On Wednesday 03 December 2008 12:22:19 Eddy Nigg wrote: On 12/02/2008 08:16 PM, Ian G: Right, CAs won't have the private keys, unless they do. I imagine a corporate CA can do what it likes, and doesn't need the consent of the user. Sure, but they aren't in my list of CA roots. And if my CA says we got your private keys, then you have the choice of another CA. It's considered a very bad practice I think. Eddy, could you expand on this point? I don't think WebTrust prohibits CAs from generating/retaining private keys for users. Are there any CAs in Mozilla NSS which have the users private keys? Have a look at: http://www.globalsign.com/support/csr/autocsr.html Also, there is a silliness aspect to this. If the CAs are trusted not to issue false certs for users, why can't they be trusted to look after their private keys? Perhaps because some countries have certain laws... If you don't like that, places to change it would be Chokhani et al (RFC 3647) or the Mozilla policy, I guess. The Mozilla CA policy is my domain...indeed are there CAs which perform key escrow without the consent of the user (or without the user having explicitly asked beforehand)? -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SSL servers sending out multiple cert chains?
On Tuesday 14 October 2008 08:03:04 Nelson B Bolyard wrote: Some time ago, in the last year, while the details of EV were getting worked out, I read a message from a representative of a CA whose root(s) are in Firefox. He wrote that to resolve certain issues with some browsers using new roots and other browsers using old roots, his CA was advising customers to configure their servers to send out all the certs needed to build a chain to either of those roots. Hi Nelson. I think you're probably referring to me and Comodo's EV AUTO-Enhancer(tm)... https://bugzilla.mozilla.org/show_bug.cgi?id=406755#c33 If I recall correctly, he used the word shotgun to describe this technique. I didn't use that word. Sadly for me, I do not remember who wrote that comment, or what CA he represented, or to which mailing list he sent that message, and I cannot find that message. So now I'm writing to this group in hopes that that person reads this list. If you are the CA representative who wrote about that, please write to me and tell me if there is any public information about your technique. See the bugzilla.mozilla.org link above. I write this because the IETF TLS working group is now considering whether to refine the next TLS RFC to speak to certain related issues. It has been proposed to change the text in the next TLS RFC to explicitly disallow the sending of anything but a single cert chain, from leaf to root. Nelson, thanks for mentioning this! I really do hope that this proposed change is not approved! I've been meaning to get around to suggesting to the IETF TLS WG that the next TLS RFC should *explicitly allow* the sending of certs in multiple chains! I'd like to offer pointers to any public information about that shotgun technique as evidence that the alternative (sending certs that are NOT necessarily a single chain) is being used to good advantage on the Internet today. The bugzilla.mozilla.org link above mentions a number of good advantages w.r.t. activating the EV UI in Internet Explorer 7. I'd be more than happy to answer any further questions. Regards, /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
the OCSP URI in the CA root IS a problem Nelson, does NSS ever attempt to check the revocation status of a built-in Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP URI(s) ? On Sunday 12 October 2008 16:40:11 Eddy Nigg wrote: Eddy Nigg: Except if Nelson thinks otherwise, removing the AIA OCSP service URI solves this issue. More specific the Mozilla CA Policy calls for: cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Therefor the OCSP reference MUST NOT appear in the EE certificates of Microsec. I suggest to follow up on this to confirm compliance. I think we have a problem here! I wanted to make sure that the CA root and intermediate CA certificates don't include OCSP AIA extensions and I noticed the following when importing and examining the CA root... - The CA root includes the OCSP service URI in the AIA extension: OCSP: URI: https://rca.e-szigno.hu/ocsp - Upon going to https://srv.e-szigno.hu/ I received an sec_error_unknown_issuer error. Apparently the certificate isn't installed correctly and doesn't present the certificate chain. The later is just an annoyance which can be easily fixed, however the OCSP URI in the CA root IS a problem. Additionally the intermediate CA certificate might also feature the AIA extension (which I couldn't test). As mentioned earlier, the Mozilla CA Policy states: ...might cause technical problems with the operation of our software, for example, with CAs that issue certificates that have... ...cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists. Micorsec doesn't provide an operational OCSP responder when used in conjunction with AIA service URI. Over to Frank. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microtec CA inclusion request
On Monday 13 October 2008 15:36:02 István Zsolt BERTA wrote: snip - The CA root includes the OCSP service URI in the AIA extension: We accept that it is awkward that our root certificate includes the OCSP AIA extension, it was a bad idea for us to include it. Unfortunately our root certificate is not something we can change on the short run. István, Just a thought... If Nelson's investigation does find that the OCSP AIA extension in your Root Certificate is a problem for NSS, is there really anything to stop you from issuing a new Root Certificate? This new Root Certificate could be identical to your current Root Certificate except for i) different serial number, and ii) OCSP AIA removed. As the old and new Root Certificates would have the same Subject Name and Key, they would effectively be interchangeable. We don't quite understand why anyone would check the revocation status of a trust anchor via CRL or OCSP. Regards, István ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Microsec CA inclusion request
On Thursday 02 October 2008 22:43:02 Frank Hecker wrote: snip * Microsec has a separate root used for OCSP, and apparently does not offer OCSP as a general public service; please see the comments in the bug. I'd like those of you who are OCSP experts to look at this issue and tell us if you see any potential problems there. Comment #3 in that bug indicates that they're not expecting Mozilla to support OCSP under a separate root. When Microsec be include their OCSP Responder URL in an end-entity certificates that they issue, FF3 will by default attempt to check the certificate's status via OCSP. This OCSP check will of course fail, because: i) the OCSP signer certificate does not chain up to a trusted Root, and... ii) RFC2560 section 4.2.2.2 (and therefore FF3, I presume) insists that a certificate's issuer MUST either sign the OCSP responses itself or it MUST explicitly designate this authority to another entity, and this condition is not met. On Saturday 04 October 2008 12:54:10 Eddy Nigg wrote: The default settings of FF3 is to use OCSP and as you mentioned, this isn't going to work (as you mentioned already). Yes and no. IINM, FF3 by default has the When an OCSP connection fails, treat the certificate as invalid tickbox set to *disabled*, meaning that most users won't see browser warnings. Therefore, IMHO, if Microsec don't think it's a problem, then it's not a problem. (The other effect of a failed OCSP lookup in FF3 is that an EV cert will lose its EV status, but I don't believe that Microsec are an EV certificate issuer at present). On a related note... It might interest you to know that the Microsoft CryptoAPI does support OCSP under a separate root in Windows XP and Vista. I recently asked our contact at Microsoft to explain to me why this RFC2560-non-compliant feature exists. He said: The feature to allow OCSP responses to be signed by a certificate under a different root was added for customers with branch networks that cannot connect to the CA's revocation repository, either because the customer do not want to allow those machines to connect to the Internet directly, the connection has limited bandwidth, or the branch network is physically disconnected for extended periods (such as those on a ship). This first public comment period will be for one week, and then I'll make a preliminary determination regarding this request. Frank [1] Fun fact: Within Hungary names are normally given in Eastern order (i.e., like China or Japan) with surname first. In this case I've transposed to Western order (I think). -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo ECC CA inclusion/EV request
On Saturday 19 July 2008 19:30:51 Paul Hoffman wrote: At 11:04 AM +0100 7/19/08, Rob Stradling wrote: I think that the ECDSA signature algorithms will only be supported in OpenSSL 0.9.9 (not yet released) and above. Try a recent openssl-SNAP-2008mmdd.tar.gz from ftp://ftp.openssl.org/snapshot instead. Will do. Non-mandatory question: what software/hardware did Comodo use to generate the key pair? Our ECC key pair was generated on a Utimaco SafeGuard CryptoServer (FIPS 140-2 Level 3/4). http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2007.htm#811 What did you use to validate it? I would hope that, before the FIPS 140-2 certification was granted, Utimaco and/or NIST ensured that the Utimaco HSMs were only capable of generating valid ECC key pairs. After generating our ECC key pair, issuing the COMODO ECC Certification Authority root certificate, and issuing a test EV SSL Server Certificate, we checked... - that openssl x509 in the latest OpenSSL-0.9.9 snapshot was able to parse the root certificate without complaining about anything. - that the certificate viewer in Windows Vista was able to view the root certificate without complaining about anything. (We of course had to manually add the root certificate to the Windows Trusted Root Store). - that IE7/Vista, Firefox 2/3 on several OSes, and openssl s_client were able to connect to the https://comodoecccertificationauthority-ev.comodoca.com test site without complaining about anything. (We of course had to manually add the root certificate to the Windows and Mozilla Trusted Root Stores). As Mozilla (hopefully) starts seeing more ECDSA certs, having some common tools would be very useful for all of us. Nelson has said: Yes, NSS does this for every ECC signature it verifies. NSS recognizes a finite set of curves, and verifies that the base point is on the curve as a part of signature verification. Perhaps NSS's checkcert command-line utility would or should do the necessary checks? ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo ECC CA inclusion/EV request
On Saturday 19 July 2008 00:26:57 Paul Hoffman wrote: At 6:18 PM -0400 7/18/08, Frank Hecker wrote: Paul Hoffman wrote: At 9:27 AM -0400 7/18/08, Frank Hecker wrote: Paul Hoffman wrote: Has anyone validated the ECC paramters they used? Not that I'm aware. I think that's unfortunate. It is easy for all of us to test the parameters for RSA certs, but few of us have software for testing ECC certs. Are there NSS, OpenSSL, or other open source utilities available for this purpose? I don't know, but I take it you don't either. Hopefully others on this list might. FWIW, the latest version of OpenSSL (0.98h) won't: I think that the ECDSA signature algorithms will only be supported in OpenSSL 0.9.9 (not yet released) and above. Try a recent openssl-SNAP-2008mmdd.tar.gz from ftp://ftp.openssl.org/snapshot instead. # openssl x509 -in COMODOECCCertificationAuthority.crt -out COMODOECCCertificationAuthority.pem -inform der -outform pem # openssl verify COMODOECCCertificationAuthority.pem COMODOECCCertificationAuthority.pem: /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority error 18 at 0 depth lookup:self signed certificate /C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority error 7 at 0 depth lookup:certificate signature failure 57046:error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm:a_verify.c:141: Could you point me to more information on this topic? NIST FIPS 186-3 is the standard, and it has the parameters for the curve that Comodo says they are using. There's a test site with a Comodo-issued ECC cert at https://comodoecccertificationauthority-ev.comodoca.com/ ...which no browser will let me into. :-) For Firefox at least that's because we haven't added the root CA cert yet, though there might be additional reasons relating to the OCSP responder (see the bug for more info). I was able to add a security exception for this site and then could access it successfully (using Firefox 3.0.1 on OS X), however it's not clear to what extent Firefox was able to validate the cert signature. (Firefox still gives me a certificate did not verify for unknown reasons message.) That is a bad sign, yes? It seems unwise for us to approve a trust anchor we can't even verify. I am quite sure we will eventually be able to verify it (or a corrected version if Comodo made a mistake), but having an error in the first ECDSA certificate we put in our trusted root pile will be bad publicity both for Mozilla and for ECDSA. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Decline in firefox usage due to lacking CA certificates
On Wednesday 16 July 2008 15:08:15 Frank Hecker wrote: ... We are doing what we can. However by design we do not simply rubber-stamp CA requests. We have an official policy which was developed through a process of community consultation, and we follow a similar process of community discussion when considering CAs. We do have more people now working on CA-related tasks (unlike previously when I was the only person, and could do it only part-time). However the process will never be quick IMO. Frank, is there any reason why you can't have multiple candidate CAs having their public discussion periods simultaneously? Having watched this list for a number of months, I think I'm right in saying that you're only allowing one at a time...in which case, how is having more people now working on CA-related tasks actually improving your overall throughput? -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Decline in firefox usage due to lacking CA certificates
On Thursday 17 July 2008 13:33:04 Frank Hecker wrote: Rob Stradling wrote: Frank, is there any reason why you can't have multiple candidate CAs having their public discussion periods simultaneously? No reason at all; Thanks Frank. That's good to hear. in fact, technically we have two in public discussion right now (GlobalSign and T-Systems). The major bottleneck is collecting the CA information and getting the last 10% of questions answered. Kathleen Wilson has some CAs that are in that stage now, Frank, in Bug #421946 Comment #15 you said: I'll proceed with the first public comment period once I figure out where this request sits in the queue relative to other similar requests. If the public comment/discussion periods are not the major bottleneck, then can you explain why there has been no movement on this bug for over a month? Thanks. and I've asked Gerv Markham to start the process on two more. There are also a couple of CAs that got bogged down at the public discussion stage earlier, and I'm going to see if we can move them forward. Frank -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Decline in firefox usage due to lacking CA certificates
On Thursday 17 July 2008 16:50:50 Frank Hecker wrote: Rob Stradling wrote: Frank, in Bug #421946 Comment #15 you said: I'll proceed with the first public comment period once I figure out where this request sits in the queue relative to other similar requests. If the public comment/discussion periods are not the major bottleneck, then can you explain why there has been no movement on this bug for over a month? Because I dropped the ball on that one, for which I apologize. I'll look at it and start public discussion as soon as I can. Apology accepted. Thanks for picking the ball up again. :-) Frank P.S. Incidentally, I have no problem whatsoever with CAs pinging me directly (via email or phone or whatever) to remind me that their requests need attention. Please feel free to do that if ever you should need to. Sure. Thanks. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
On Friday 06 June 2008 10:07:20 Gervase Markham wrote:
Nelson B Bolyard wrote:
Rob, in the past, any time that we have suggested that a CA issue a new
root CA cert for any reason, even if only to change something minor,
we've received much feedback saying that doing so represents a huge
challenge and investment for the CAs, necessitating modifications to
CPSes, triggering new audits, etc. etc. One gets the impression from
those replies that this is something the CAs would rather avoid at
(nearly) all cost.
Another option would be to make a (small? :-) modification to NSS to
allow us to store an expiry date which overrode the one in the certificate.
Good idea. That would be much less hassle (compared to my proposal) for both
the CAs and Mozilla.
Or, instead of modifying the data that NSS holds for each certificate...
Yet another alternative option would be to make a modification to NSS's
certificate path processing code, so that whenever NSS is attempting to build
a certificate chain up to a trusted Root it would check:
- the current date/time.
- the key sizes of each certificate it is considering trusting.
- a hard-coded array of: { algorithm, key_size, soft_insecure_after_date,
hard_insecure_after_date }.
Whenever a key is found whose soft_insecure_after_date is in the past,
NSS/Firefox/etc would warn the user, but allow them to choose to navigate to
the HTTPS site if they really want to.
Whenever a key is found whose hard_insecure_after_date is in the past,
NSS/Firefox/etc would warn the user and refuse to allow them to navigate to
the HTTPS site.
I think it would make sense for the soft_insecure_after_dates to match
NIST's recommendations, but the hard_insecure_after_dates would be up to
Mozilla to define.
Also, the hard-coded array could be extended to define algorithm expiry
information for not only RSA key-sizes, but also...
- Hash algorithms used in signatures (e.g. NIST specify a 2010 deadline for
SHA-1; and I think MD2/4/5 and SHA-0 should already be deemed to have passed
their soft_insecure_after_date).
- ECC key-sizes and curves.
- Symmetric algorithms used in SSL cipher suites.
NSS could check all of these during certificate path processing and SSL/TLS
handshakes.
With this approach, Mozilla could even continue to accept new 1024-bit Root
Certificate submissions for the next few years (not that I'm advocating that,
of course!)
Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
On Wednesday 04 June 2008 21:59:54 Paul Hoffman wrote: ... - There may be some (solvable, I think) interoperability problems for CAs that choose to include the authorityCertSerialNumber field in the Authority Key Identifier extension of certificates issued by their 1024-bit Root Certificates. Not sure what you mean here. Please see the follow-up comments from myself and Nelson. I hope they explain this issue enough. Am I trying to make things too complicated? Or does anybody think that this idea is worth considering? Definitely worth considering. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
On Thursday 05 June 2008 12:05:42 Eddy Nigg (StartCom Ltd.) wrote: Rob Stradling: Rob, in the past, any time that we have suggested that a CA issue a new root CA cert for any reason, even if only to change something minor, we've received much feedback saying that doing so represents a huge challenge and investment for the CAs, necessitating modifications to CPSes, triggering new audits, etc. etc. One gets the impression from those replies that this is something the CAs would rather avoid at (nearly) all cost. I'm not convinced a new audit would be required, and I don't think CPS changes are quite as expensive as the CAs you cite have suggested. Yes, I agree with you. I suppose that this is part of the key management a CA performs, which in itself is audited. Issuing new keys according to the defined procedures and CP/CPS doesn't require re-auditing per se, perhaps only if there were substantial other changes to the infrastructure which aren't related to the mere issuing of additional keys. Also...just a thought...I wonder if any part of the Mozilla CA Certificate Policy could be updated to make 1024-bit Root Certificate replacement less hassle? I don't agree however with this. CAs usually have to go through the full cycle for having roots included and we shouldn't make other exceptions. The EV inclusions were exceptionally rushed enough I'd say...Also it's an excellent opportunity to review CAs which sometimes never were really looked at. I have no objection to Mozilla reviewing CAs which sometimes never were really looked at in days gone by. :-) Additionally, most of the times the old and the new root will be both present in NSS for some time in order to allow a smooth transition, until the old root is being removed. Not so. With my proposal, the old and new roots would *not* both be present in any NSS versions. The old one would be removed when the new one gets added. Eddy, I think you've missed the main point of my proposal. I am suggesting that each existing valid-for-too-long 1024-bit RSA Root Certificate should be replaced with a valid-for-not-too-far-beyond-2010 1024-bit RSA Root Certificates *WITH THE SAME KEY*. On a kind-of-related note... Bug 406794. GlobalSign want to do something very similar No, this isn't the same really, it's not a new key per se. Precisely. So, as I said, it is the same thing. Could that behaviour of NSS be changed? If future NSS versions were to treat authorityCertSerialNumber as merely a hint, then I don't think that any certs would need to be reissued for my proposal to work. Mhhh, maybe I'm missing something here, but how should replacing a root with a different key and key size not have an effect on this? Certs will have to be issued from the new root at some point and I'm not sure how a certificate signed from a 1024 bit key doesn't require re-issuance from a new 2048 key if the old key becomes obsolete and the EE cert is still valid. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone:+1.213.341.0390 -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
On Thursday 05 June 2008 12:59:13 Eddy Nigg (StartCom Ltd.) wrote:
Rob Stradling:
Additionally, most of the times the old and the new root will be both
present in NSS for some time in order to allow a smooth transition,
until the old root is being removed.
Eddy, I think you've missed the main point of my proposal. I am
suggesting that each existing valid-for-too-long 1024-bit RSA Root
Certificate should be replaced with a valid-for-not-too-far-beyond-2010
1024-bit RSA Root Certificates *WITH THE SAME KEY*.
Sorry Rob, yes I missed that one. But why doing that? Why not replace
with something better and remove the offending root? Perhaps I'm not
objective enough because we actually replaced a small key with a bigger
one. What's the logic for having a pile of roots which expire in 2010?
I didn't say expire in 2010.
Sorry for being slow...can you explain to me the logic of your proposal
(again)?
I think the key issue is that we don't want users of Mozilla software to be
relying on 1024-bit RSA Root Keys too far beyond 2010.
If we were to remove any 1024-bit RSA Root Certificates from Mozilla today, it
would be damaging to the CAs (who rely on the good browser ubiquity provided
by these Roots).
But, if we instead wait until, say, 2013 to remove those Root Certificates
from NSS, some users would still be relying on those 1024-bit Root Keys until
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
I believe that my proposal solves both problems. The CAs' browser ubiquity
would not be damaged until such time that Mozilla decides the 1024-bit Keys
should be no longer be relied on. And in the future, Mozilla users (even
with...at that point in time...fairly out-of-date software) would be
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
by Mozilla arrives.
Regards
Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org
Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED]
Blog: Join the Revolution! http://blog.startcom.org
Phone:+1.213.341.0390
--
Rob Stradling
Senior Research Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
On Tuesday 03 June 2008 07:28:33 Michael Ströder wrote: Eddy Nigg (StartCom Ltd.) wrote: Paul, I think that the general idea (of Frank and others) is, to make a requirement on new roots and act on the 1024 bit keys at some point in the future. I also support the idea of throwing out 1024 bit keyed roots at a not so distant point in the future. For those 1024-bit RSA Root Certificates that are *already included* in Mozilla software, I think that a distinction should be drawn between: A. Those that expire before NIST's 2010 deadline. B. Those that expire soon after 2010. C. Those that expire well beyond 2010. For now, let soon after = before 2013 and well beyond = after 2013. I think that type A and B Root Certificates can be left to expire naturally before being removed from future versions of Mozilla software. I have a suggestion regarding what Mozilla could do *right now* with type C Root Certificates... 1. Remove each type C Root Certificate from Mozilla ASAP, but also... 2. Give each affected CA the opportunity to submit a replacement 1024-bit RSA Root Certificate for inclusion in new versions of Mozilla software. Each of these replacement Root Certificates would exactly match the to-be-removed Root Certificate (in terms of Subject name, Public Key and Subject Key Identifier), but would have a different Serial Number and a more acceptable Not After date. Advantages: + Mozilla would be able to prevent the reliance on 1024-bit RSA Root CA Keys according to a time schedule set by Mozilla. + This prevention time schedule would take effect ASAP. There would be no need to wait until 2013 to remove type C Root Certificates from Mozilla, which means that... + Versions of Mozilla software published between ASAP and 2013 would not trust any 1024-bit RSA Root Keys beyond 2013. (I think that, come 2013, we can expect some users to be using old versions of Mozilla software). Disadvantages: - Each affected CA would have to spend some time reissuing their Root Cetificate. - Mozilla representatives would have to spend some time checking the replacement certificates and writing patches to remove/include the original/replacement certificates. - There may be some (solvable, I think) interoperability problems for CAs that choose to include the authorityCertSerialNumber field in the Authority Key Identifier extension of certificates issued by their 1024-bit Root Certificates. Am I trying to make things too complicated? Or does anybody think that this idea is worth considering? I also hope that this will sort out some of the issues with root CA certs concerning so-called cross-signing and liberal use of sub CAs. are issued from that root since we've successfully transitioned to the newer 4096 bit root. FYI: A VPN product of a major vendor simply does not work with 4096 bit root. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Modulus length (was Re: Draft CA information checklist)
On Wednesday 04 June 2008 12:25:32 Kyle Hamilton wrote: There has been evidence of Microsoft, at the least, following this group and acting on good ideas that started here. While it'd be nice if that organization would comment here, I think that if they like this plan (or anything like this plan) they'll implement it and it'll end up being a fait accompli. FYI, Microsoft already require a minimum 2048-bit RSA key size for new Root Certificate submissions. http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true says... Updated: January 22, 2008 ... 4. Root certificates must comply with the Technical Requirements section below. In particular, we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. We prefer that new roots are valid for at least 8 years from date of submission but expire before the year 2030, especially if they have a 2048-bit RSA modulus. January 1 2009 particularly because it provides slightly less than 2 quarters of notice. Honestly, I would be quite happy if it went into effect immediately; however, I do know that some Cisco VPN equipment doesn't like 4096-bit root keys. I don't know if it likes 2048-bit keys. I would treat 'new' as 'new request'. And I don't know if anyone's tried to submit a 1024-bit root recently. -Kyle H On Wed, Jun 4, 2008 at 2:14 AM, Gervase Markham [EMAIL PROTECTED] wrote: Paul Hoffman wrote: Proposal: a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or 256 bit EC. Why January 1 2009 particularly? By new, do you mean newly-generated, or new to us? Has any CA actually attempted to get a recently-generated 1024-bit root included? b) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit EC. It would make most sense to coordinate such a policy with other browser vendors, if possible. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo request for EV root inclusion (COMODO Certification Authority)
Eddy, it was certainly never my intention to lead you to conclude that the COMODO Certification Authority root certificate will only issue EV certificates and should be enabled for EV only. What I actually said was: I can assure you that Comodo never issue DV and EV certs from the same *Intermediate* CA. I did not mention Root CAs in this statement. On reflection, it occurs to me that Intermediate and Root are perhaps not the best words to use, since the now widespread use of cross-certification blurs the distinction somewhat. Perhaps the following statement is clearer: I can assure you that Comodo never issue End-Entity DV and EV certs from the same Issuing CA. In the same message, I also said ...we really need to have generic (rather than purpose-specific) trust anchors. So, please change the details on the Pending page back to how they were. As per Bug #401587 Comment #0, we still really do want the COMODO Certification Authority to be enabled for All 3 purposes: DV, IV/OV and EV. Now, Frank has said At present there are two subordinate CAs under the COMODO Certification Authority root: COMODO EV SSL CA and COMODO EV SGC CA. These two subordinates are the issuing CAs for end entity certs. This statement is correct, as long as you don't interpret ...there are two... as ...there are only two and will only ever be two As it happens, we also have a further subordinate CA under COMODO Certification Authority, which we already use for issuing one of our brands of DV certificate. We also have plans to issue an IV/OV subordinate at some point. As before, I'll defer to Robin Alden to answer any CPS-related questions you may have about this. I apologize on behalf of Comodo if we have inadvertently omitted to draw your attention to some of this information sooner. I spoke to Robin Alden earlier today. He hopes to be able to reply to at least some of your questions today. On Tuesday 18 March 2008, Eddy Nigg (StartCom Ltd.) wrote: Frank Hecker: Comodo has applied to (among other things) add a new EV root CA certificate for the *COMODO Certification Authority* to the Mozilla root store, as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=401587 Note that this request specifically refers to the COMODO Certification Authority root CA certificate referenced in comment #16 to bug 401587: https://bugzilla.mozilla.org/show_bug.cgi?id=401587#c16 The details at the Pending page have been updated by Frank concerning this CA root. There are no objections to adding this root, but please note that this root will only issue EV certificates * and should be enabled for EV only, provided if and when we have that capability in NSS. Perhaps we want to open a catch-all bug for such roots which are added under this condition. * Confirmed by Rob Stradling from Comodo. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo request for EV-enabling 3 existing roots
Hi Eddy. I'm not the right person to answer your questions about our CPS. I have asked my colleague Robin Alden to join this newsgroup and answer each of your points. On Sunday 16 March 2008, Eddy Nigg (StartCom Ltd.) wrote: This is a revised version of my initial questions concerning the Comodo inclusion and upgrade requests. I've updated the sections which received a response from Frank and are solved from my point of view and added some more content where deemed necessary. 1.) The audit report for non-EV operations refers to the CA operation at Manchester. The audit report for EV refers to the CA operations at New Jersey. One of the roots is from a company operating in Sweden, one operating in Salt Lake City, Utah, USA and and one of Salford, GB. Can the relations between these locations and the general operation of Comodo and the audit reports be explained? Additionally I would like to know to whom belongs the company LITESSL CA, INC. and its relationship to Comodo CA Ltd. as referenced in the audit report from KPMG (https://cert.webtrust.org/SealFile?seal=636file=pdf). What are its relations to AddTrust AB, Sweden? In the audit reports no distinctions are made between the various companies and the audit reports are addressed only to Comodo CA Ltd. 2.) The Comodo Certification Practice Statement, Version 3.0 and other CPS amendments state that wild card certificates are domain name validated only (depending on product or trade mark). How does Comodo prevent or control misuse of wild card certificates, specially in relation to phishing attempts and other fraud, taking into consideration that these certificates are domain validated only? Does Comodo believe that such wild card certificates are issued according to verification requirements for this special type of certificates? 3.) The Comodo Certification Practice Statement, Version 3.0 and other CPS amendments state certificate validity of up to ten years and beyond. I couldn't find any provision in case the domain name expires. It isn't clear what happens if an identity or organization changes name, changes address, stops its operation, dies etc. How does Comodo guaranty the validity of these certificates throughout their lifetime? 4.) Frank, this one is for you: Since most (if not all) CA root certificates of Comodo were inherited from the Netscape era and never were properly evaluated by an inclusion process and in light of the questions above, isn't a thorough review of this CA in place in order to guaranty conformance to the Mozilla CA policy? Because an upgrade to EV would tie this CA further into NSS I believe that such a review should be performed prior to any other step. I haven't invested a lot of time into this request initially (as I haven't for other upgrade requests for EV during the comments period), but raised enough questions which might justify such a review. -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comodo request for EV-enabling 3 existing roots
SSL sites as valid SSL sites (as opposed to getting unknown root errors). Marking both the new EV roots and legacy roots with the EV OIDs was then a hack to get EV-aware browsers like (Firefox 3) to recognize EV certs no matter which cert chain the underlying PKI library decided to follow. Now that you have the context, let me get back to the Comodo application. Comodo's roots can be divided into three classes: 1. The new Comodo EV root (COMODO Certification Authority). 2. The three legacy Comodo roots that are specifically documented (i.e., in Comodo's EV CPS) as participating in Comodo's cross-signing scheme and thus could be encountered as trust anchors when processing cert chains from EV sites (AddTrust External CA Root, UTN - DATACorp SGC, and UTN-USERFirst-Hardware). 3. All other legacy Comodo roots, which might end up being involved in EV-related cross-signing schemes, but don't appear to be documented as doing so right now, based on the CPSs I've reviewed. Based on this division, I've done evaluations and preliminary approvals for the new EV root (class 1) and the three legacy roots in class 2, but I've postponed action on the remaining roots (class 3) until it's clearer whether I need to approve them for EV purposes, or can wait on this. Supposed an intermediate CA or CA root is dedicated for EV only, we might have much better control. Just imagine Comodo issues a DV cert with the EV bits onthoughts, suggestions? I think we've discussed a similar issue in relation to subordinate CAs. There's a trade-off here between maximum control and complexity. If we wanted maximum control then we would maintain data on every CA that issued (or could issue) end entity certificates -- basically every root CA and every subordinate CA under those roots, without exception. Then we could exercise very fine-grained control: We could say, this subordinate CA (which might be 3 or 4 levels down in the hierarchy from a given root) can do this (issue EV certs, issue email certs, whatever), while this other subordinate CA (somewhere else in the hierarchy under that root) can't. However exercising this amount of control would involve lots and lots of work on our part, and would require maintaining very large sets of CA-related data that we would either have to ship with Firefox or build a scheme to have Firefox automatically fetch. Quite frankly I think it's a non-starter. The scheme we have now trades off maximum control for implementability. We have relatively coarse-grained controls, and then we rely on CAs to implement more fine-grained controls (e.g., using certificatePolicies, EKU, etc.). This means that CAs in theory could abuse the scheme (e.g., by issuing EV certs from subordinates not intended to be used for this purpose). That's where we rely on auditors to verify that CAs are operating according to their stated plans. If that turns out not to be true in certain cases then we can look at those on a case-by-case basis and figure out if we need to or want to take certain actions. I can't write any more on this right now, but I hope the above addresses at least some of the questions you had. Frank -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
