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: 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. * 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
tdCBmw7xyIFVtd2VsdDBUpFIw 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: 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
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: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 13/09/13 04:52, Julien Pierre wrote: 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
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 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
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 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 16/08/13 23:05, Wan-Teh Chang wrote: 8. Authentication: RSA before ECDSA a. RSA before ECDSA : performance b. DSA last: not in use ... 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: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On 16/08/13 16:18, Ryan Sleevi wrote: On Fri, August 16, 2013 6:36 am, Rob Stradling wrote: 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. I think the point was that fingerprinting the TLS handshake has some positive value, and is not inherently negative - as demonstrated by that OpenSSL patch. Ah, of course. Thanks Ryan. That's not to suggest that every UA shold report the UA string in the TLS handshake, but just pointing out that when mistakes (in implementations) happen, it's "nice" to be able to identify them and work around. Agreed. (Now, if I could just persuade the OpenSSL team to commit that patch... ;-) ) Cheers, Ryan 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 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 -- 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 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: Introductions - want to contribute to NSS developer friendliness
On 17/06/13 18:58, Chris Newman wrote: 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
Re: Root Certificates in Firefox OS (was Re: NSS in Firefox OS)
On 18/04/13 13:54, Rob Stradling wrote: On 20/10/12 18:33, Brian Smith wrote: 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] https://bugzilla.mozilla.org/show_bug.cgi?id=787155#c10 seems to answer my question. "...B2G doesn't have an EV indicator anyway". 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 -- 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: 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 -- 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
On 10/02/12 11:02, Erwann Abalea wrote: Le mercredi 8 février 2012 21:57:09 UTC+1, Kai Engert a écrit : My criticism: (a) I don't like it that the amount of CRLs will be a subset of all CRLs. What about all the revoked certificates that aren't included in the list? With a dynamic mechanism like OCSP (and in the future OCSP stapling) you don't have to make a selection. OCSPStapling doesn't work. You can have only one OCSP response by the standard, while you need at least 2. It was defined that way in 2006 (RFC4366), and confirmed in 2011 (RFC6066). The fact that only 1 OCSP Response can be stapled is not a problem...if we could just find a different way to improve revocation checking of the intermediate CA certificate(s) in the chain. Since there are probably very few revoked intermediate CA certificates in the wild, why not use CRLSets just for intermediate revocation checking? (I'd expect the size of this data to be well under 100K !) -- 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
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=97640&view=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: 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: 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: 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: > 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. 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: > - 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 14:29:43 Rob Stradling wrote: > On Tuesday 03 November 2009 13:42:14 David Stutzman wrote: > > 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. 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: Basic ECC in NSS 3.12.4 with NSPR 4.8
On Tuesday 03 November 2009 13:42:14 David Stutzman wrote: > 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. > 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: Making OCSP soft fail smarter
Gerv, have you read the current "security.OCSP.require in Firefox" thread on mozilla.dev.security? Daniel Veditz said yesterday... "An alternate approach I'd like to lobby our front-end guys on would be to put up a scary red bar when we can't validate OCSP. Users can still get to their sites so they won't ditch us for another browser, site owners are still getting traffic so they won't be breathing down _our_ neck (too much), but the site will look a little scary and link to an explanation so site owners can take the issue up with their CA and users have the opportunity to decide not to submit sensitive data over the connection." This morning I suggested changing the boolean user pref of which you speak into 3 radio buttons: "When an OCSP server connection fails: o ignore the problem o show a warning (the new default) o treat the certificate as invalid" So rather than just "OK" and "Not OK", I'd like to see 3 categories: 1. OK. Continue to download and display the webpage. 2. Maybe OK. Display a warning message about problems with the response from, or problems accessing, the CA's OCSP Responder. Continue to download and display the webpage. 3. Not OK. Display a message that the certificate is revoked. Block access to the webpage. "Maybe OK" would be treated as "OK" if "ignore the problem" is selected, or as "Not OK" if "treat the certificate as invalid" is selected. I would treat No Response, 400 response, 500 response and "tryLater" as "Maybe OK"s. On Tuesday 13 October 2009 14:54:01 Gervase Markham wrote: > Firefox uses OCSP but, by default, any response other than a definite > "is revoked" response is treated as "is not revoked". There is a user > pref that allows the user to change that, so that any response other > than "is not revoked" is treated as "is revoked". > > IMO, we need to be smarter about that. > Here's a straw man: > > OK: > 200 response with OK > No response (network problems) > > Not OK: > 200 response with revocation > 400 response (OCSP responder actively denying response) > 500 response (OCSP responder broken) > > What do people think? Putting 400 and 500 in "not OK" makes it harder to > inject a failure in order to get Firefox to pass a cert. Although one > can still inject an OCSP tryLater . > > Gerv -- 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: 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: client certificates unusable?
On Saturday 21 March 2009 23:51:40 Kyle Hamilton wrote: > The problem isn't just on the server side, it's not just on the client > side, it's also on the CA side. The CA/B forum should have brought > Server vendors into the mix, too, to explain their plights. Kyle, that's an interesting thought. I've just posted a message to the CA/Browser Forum mailing list to suggest that the Forum could invite server software vendors to participate. If anything happens, I'll report back here. -- 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
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 +0000 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
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
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: > > > > 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: Suggestion: Announce date for MD5 signature deactivation
On Monday 12 January 2009 20:28:25 Eddy Nigg wrote: > On 01/12/2009 09:20 PM, Paul Hoffman: > > No, because it is not true. What is true is that signing with MD5 is now > > considered to be insecure, and what Mozilla will do about it. > > > >> Should every possible algorithm be listed there too? > > > > Probably, yes. That is, every allowed signing algorithm should be listed; > > we obviously don't need a list of the non-allowed algorithms. > > > >> Does your CA policy and practice statements list any algorithm you don't > >> intend to use for the same reasons? > > > > We should not be relying on CA's CPSs: we should be relying on our own > > view of what is good-enough security. > > This was a question directed to Rob, not Mozilla :-) Eddy, I do think that the Mozilla CA Certificate Policy should cover *all* "actual" problematic practices. In this particular case, I think that a blacklist of unsupported/non-allowed/not-recommended algorithms and/or a whitelist of supported/allowed/recommended algorithms would be very useful information for the CAs. If Mozilla ever does decide to pull a CA's Root for whatever reason, wouldn't it be so much better if Mozilla could say to them... "CA X, you have no excuse. You have clearly violated clause N of version Y.Z of the Mozilla CA Certificate Policy, which you had previously agreed to adhere to" ...rather than... "CA X, you took your eyes off the ball. You really should have been following all of the discussions on mozilla.dev.tech.crypto more closely and assuming that any opinion expressed might become Mozilla's official policy at any moment. And you really should have assumed that violating any 'potentially problematic practice' could give us cause to pull your Root at any time" ? To put it simply: I would really like Mozilla's expectations of the CAs to be, on an ongoing basis, 100% clear. > >> Or supposed Mozilla deems certain practices in relation to RAs and/or > >> intermediate CAs an unnecessary risk and problematic, does this have to > >> be explicitly stated in the Mozilla CA Policy? > > > > Yes. > > > >> If yes, what else must be stated there or is the intend of the policy > >> clear enough? > > > > Everything that we know that some CAs might do wrong that is not > > acceptable to Mozilla should be listed there. As we discover new > > categories (in this case, "uses unsafe algorithm"), it should be added. > > That list is not going to be long, but it *will* be valuable. > > OK, I'm not sure if this is/was the intention of Frank and the > objectives of the Mozilla CA Policy. > > Nevertheless I suggest to start the work for a possible change to the > policy in order to address those issues now. Changes have been made to > the policy within relative short time in order to address EV, it's > entirely possible to get it accomplished with reasonable effort and > useful time-frame. -- 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 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
Re: Cert expiry with Key Continuity Management
On Monday 12 January 2009 13:07:17 Eddy Nigg wrote: > 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
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 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: 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
"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: 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. >
Re: CAs and external entities (resellers, outsourcing)
Yes, Reseller and RA are 2 distinct roles. However, in some cases, a single entity may choose (and be approved) to perform both of these roles. I fully agree that the Reseller role "should not perform any validation procedures at all". On Wednesday 31 December 2008 00:29:17 Eddy Nigg wrote: > On 12/31/2008 01:27 AM, Frank Hecker: > > One reason I say this is "good CA practice" as opposed to a mandatory > > requirement, is because of cases like enterprise PKIs where the > > enterprises might act as RAs and do verification based on their own > > internal systems (e.g., HR databases). > > I think this is what we want to avoid actually, don't we? Or perhaps we > could leave it as is, since the Mozilla CA Policy is actually clear in > relation to validations. > > Incidentally I had previously a problem with Microsoft's policy to > disallowing certain enterprise scenarios, hereby it might make some > sense. But even then, the proposal would actually call for an > attestation, whereas the attestation itself hasn't been defined yet. I > think this is what also Kay proposed. > > Now, we must not forget what an RA is, what a reseller is and what an > enterprise scenario is. RAs are interesting for the verification and > validation of identity documents in person for example. Or organizations > for that matter. Since RAs always have to interact with the CA at some > point, I believe incorporating domain/email validation is more than > easy. Even in enterprise settings is that possible. > > Resellers should not perform any validation procedures at all. They > should sell certificates and not be involved with any of the technical > sides of he procedures. Reseller != RA. > > As such, I believe that it would be good to improve the Mozilla CA > Policy and work towards better definitions and requirements. Even if the > validation aspect is clearly defined and *required*, we might exclude > certain practices outright. There are of course other points I'd like to > have improved. -- 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: 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 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 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/ > 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: SECOM Trust EV root inclusion request
On Saturday 06 December 2008 06:33:13 Frank Hecker wrote: > * 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: Microtec CA inclusion request
On Wednesday 15 October 2008 15:14:10 István Zsolt BERTA wrote: > > 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. > > Theoretically, we could issue such a certificate, but we would like to > avoid this if possible. > Our current root certificate is already used in many systems and many > applications, and it also appears in a vast number of timestamped > signatures (of ETSI TS 101 903 format). I am afraid, we would not be > able to forget about our current root certificate completely, but we > would need to use the two roots in parallel. As many of these systems > or applications are not under our control, the two roots could lead to > problems we cannot foresee. István, I must confess that I'm not too familiar with the ETSI TS 101 903 timestamped signature format. Do these signatures include a copy of your current root certificate? If yes, then I agree that there might be "problems we cannot foresee". It might interest you to know that GlobalSign have recently "refreshed" their Root Certificate in Mozilla NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=406794 Presumably GlobalSign don't foresee any problems with using "two roots in parallel". But then, I guess GlobalSign may not be intending to support the same range of systems and applications that Microsec support. > I have also reread relevant sections from RFC 5280 and X.509, and I > have not found any requirement for checking the revocation status for > trust anchors. I found that a trust anchor is an input to the path > validation algorithm, and - even if it is presented as a self-signed > certificates - it is not included as a part of the certification path. > The path validation algorithm checks the revocation status of members > of the certification path only. > > However, I do accept that it is awkward to have an OCSP AIA extension > in a root certificate. > > 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: 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
On Monday 13 October 2008 15:36:02 István Zsolt BERTA wrote: > > - 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: 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 06 October 2008 08:53:01 Rob Stradling wrote: > 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. Then, on Monday 06 October 2008 11:01:19 Nelson B Bolyard wrote: > Some of us hope someday soon to treat certs for which we receive > invalid OCSP responses (as opposed to NO OCSP responses) as revoked. > If we have admitted CAs that are known to produce certs that will not > work in that case, I think that becomes a strong disincentive to ever > institute that stronger interpretation of invalid responses. :( In that case Nelson, I withdraw my "...if Microsec don't think it's a problem, then it's not a problem" statement. > 2. Incentives to be accurate - > > They have different financial liability limits for each class of cert > that they issue, and according to comment 10 in that bug, for one of their > classes (class2 non-qualified certificates), that limit is ZERO. > > For their qualified certs, they include an extension that reports the > limit of their liability, as an integer number of Hungarian Forints (HUF). > (Tell me, do you know how much money 100K HUF is? Does is surprise you > to learn that 1 HUF is about half a penny? 100K HUF is ~500 USD.) > Browsers do not show this information to users. Hungarian representatives > have requested that Mozilla browsers should do so. See bug 277797. > Even if browsers did show this information, users are not likely to know > the value of the monetary units of various European nations. > > They do not claim to include this information in non-qualified certs. > Apparently the absence of an explicit liability limit should be understood > to mean no liability. > > Any cert for which the issuer has no liability is a cert for which the > issuer has no incentive to be accurate. If a CA has no liability for > doing so, what stops it for issuing lots of certs for paypal.com? > I would advise Mozilla against trusting certs from a CA that disclaims > liability for the information in any of its cert classes. > > 3. Inclusion of unrecognized critical certificate extensions > > When bug 277797 was filed, it was claimed that Hungarian law required > Hungarian CAs to include in their qualified certificates a certain > extension, marked critical, that is relatively unknown. This meant that > those certificates were rejected by Mozilla software, because Mozilla > software complies with the IETF RFC that requires relying party software > to reject certs with critical extensions that it does not completely > understand and honor. > > IMO, Mozilla definitely should not add a root CA cert for a CA whose > certs will be rejected for that reason. > > Hungary has legislated much of this. Perhaps their legislators thought > they could pressure the browsers and other software for relying parties > into displaying this liability limit information. > > In summary, although they may be able to claim that they are in conformance > with Hungarian law, given these other issues, I'm not convinced this is > really a service of value to typical Mozilla product users. That's my > opinion. > ___ > 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: > * 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: questions on root creation
On Wednesday 24 September 2008 01:30:15 Paul Hoffman wrote: > At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote: > >There also products today that cannot handle SHA-2 hashes, and that limit > >RSA key/signature sizes to 2k bits. I would not advise any CA to limit > >itself to those limits just for those few straggling products. The problem for CAs is... If potential customers for certificates find out that CA 1's certificates work with "those few straggling products", but CA 2's certificates don't, whose certificates do you think they're more likely to buy (assuming the prices are not wildly different)? > >Much as > >I don't like to say it, the big question is: does MSIE support it? > >If IE and FF both support SHA-2, then go for it. If users say "I have to > >switch away from to MSIE to shop at site xxx.com", > >you can be sure that other products will play catch-up, quickly. > > I think it is the opposite. Last I heard, MSIE didn't support > RSA-with-SHA256 on XP but did on Vista. I heard conflicting stories > about Microsoft's intention to fix that in an XP upgrade. Others on > this list certainly know more about this than I do (and may even be > able to test it). FYI, the "Overview of Windows XP Service Pack 3" document available at... http://www.microsoft.com/downloads/details.aspx?FamilyId=68C48DAD-BC34-40BE-8D85-6BB4F56F5110&displaylang=en ...says that Windows XP Service Pack 3... "Implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in X.509 certificate validation. This has been added to the crypto module rsaenh.dll. XP SP2 crypto modules Rsaenh.dll/Dssenh.dll/Fips.sys had been certified according to FIPS 140-1 specifications. The Federal Information Processing Standard (FIPS) 140-1 standard has been replaced by FIPS 140-2, and these modules have been validated and certified according to this standard. For more information, see the Microsoft Kernel Mode Cryptographic Module." Here's the FIPS 140-2 cert: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#997 Of course, Windows XP/SP1/SP2 and Windows 2000 still don't support anything stronger than SHA-1, so we're still stuck with using RSA-with-SHA1 in order to maintain compatibility with IE5/6/7 on those platforms. -- 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: UTN-USERFirst-Object - "Can't verify signature
Brian, something else you might like to try... The "UTN-USERFirst-Object" Root CA happens to be cross-certified by the "AddTrust External CA Root" Root CA. Both Roots are owned by Comodo, and both are trusted by Firefox for the purpose of signing code. You can download the cross-certificate from: http://crt.comodoca.com/UTNAddTrustObjectCA.crt If you include that cross-certificate when you sign your .jar, it just might work around the problem. (Note: I haven't tested this, so it might not work. Either way, some feedback would be appreciated :-) ). On Tuesday 12 August 2008 05:42:35 Nelson B Bolyard wrote: > bmo wrote, On 2008-08-11 20:22: > > Summary: I suspect that there's something wrong with the BUILT-IN Root > > CA cert UTN-USERFirst-Object in Firefox 3.0.1. > > Or perhaps something is wrong with the code that tells you about that > cert. > > > We were issued a code signing certificate which was signed by the UTN- > > USERFirst-Object cert built into Firefox (Comodo issues these). We > > have successfully signed our jar file with the certificate (verified > > with jarsigner -verify, etc.), however on Firefox 3.0.1 (on macosx), > > when our jar is loaded, we get a 'this applet was signed by > name> however we cannot verify the signature' do you want to trust > > this applet? > > > > Showing the details lists our certificate, derived from the built-in > > UTN-USERFirst-Object certificate. > > Is your cert issued directly by the UTN-USERFirst-Object cert? Or is > there an intermediate CA certificate in between your cert and that one? > > > Looking at the built-in certificates (using Preferences->Advanced-> > > Encryption, View Certificates) and scrolling down to The USERTrust > > Network list of certs -- pick the last one in the list, Viewing the > > certificate shows the message "Can't verify signature of this > > certificate for unknown reasons". > > Yeah, I think that's a bug in the PSM UI code that displays that page. > I think it says the cert is not verifiable when it actually is. > > > I suspect that that is the problem; I do note that firefox 2.x on > > Windows does NOT display the scary dialog, and accepts the jar as > > signed. It also displays the 'Can't verify signature of this > > certificate for unknown reasons' message when viewing the built-in > > certificate (Which, in reading the archives of bugs from 2005, may > > mean something else entirely). > > Those facts alone should be pretty convincing that the cert is actually > OK, but the UI says it's not for some unknown reason. :) (It's unknown > why the UI says it can't be verified, and it's unknown why the UI says > the reason is unknown.) > > > Can someone tell me: > > 1) Why the built-in UTN-USERFirst-Object cert is not verifiable (why > > is it in Firefox, then?) > > Let's call it a bug in the UI code. I'm pretty sure there's a really OLD > bug filed about that UI code. Let's see... > https://bugzilla.mozilla.org/show_bug.cgi?id=289988 filed in 2005 for FF1 > https://bugzilla.mozilla.org/show_bug.cgi?id=293154 > https://bugzilla.mozilla.org/show_bug.cgi?id=300071 > > > 2) Why the behavior (if it's the same certificate in FF 2.x and > > 3.0.1) is different between FF versions? > > That's a good question. Here are some things to investigate. > > Look at your cert in FF2. Look at the cert chain. Do you see only two > certs? or three? or more? > > If you see a third cert in between yours and the "root" cert at the top, > look for that cert in the Authorities tab, and see if it is in the > "Builtin Object Token" or the "Software Security Device". > Also, look in the tab for "your certificates" and see if your code signing > cert is listed there. > Then repeat these steps with FF3 and see if anything is different. > Let us know. > ___ > 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 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 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: 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 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: Debian Weak Key Problem
"Comodo is offering a free replacement SSL certificate to any affected business, regardless of their original provider...No mention of any CA actively contacting affected customers, much less revoking any certs." That is now old news. I'm pleased to announce that... 1. Our systems will now use the very latest blacklists from the openssl-blacklist project to identify and reject CSRs with weak keys. This will prevent us from issuing any further certificates with weak keys. 2. We have analyzed all of the unexpired, unrevoked certificates that we've issued. Approximately 1.5% were found to contain weak keys. 3. We have emailed all of our affected customers to: i. alert them to the security risk and to offer them a free replacement certificate. ii. advise them that we plan to revoke all certificates with weak keys soon. 4. We have been monitoring the rate at which customers are replacing their installed certificates. 24 hours after emailing them, we estimate that 8% had done so. We will continue to monitor this. On Friday 13 June 2008 22:19:09 Paul Hoffman wrote: > http://news.netcraft.com/archives/2008/06/12/ssl_certificates_vulnerable_to >_openssl_flaw_on_debian.html > > The last paragraph says: > > = > Although a number of certificate authorities have offered free > replacement certificates to customers affected by the Debian OpenSSL > vulnerability, it has been reported that they have not been getting a > big response. Comodo is offering a free replacement SSL certificate > to any affected business, regardless of their original provider, > while VeriSign is offering free reissuance for both SSL certificates > and code signing certificates. GeoTrust and Thawte also offer free > SSL certificate reissuance, and RapidSSL certificates can be renewed > for free at GeoTrust's website. > = > > No mention of any CA actively contacting affected customers, much > less revoking any certs. > ___ > 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 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_date"s to match
NIST's recommendations, but the "hard_insecure_after_date"s 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 Thursday 05 June 2008 15:46:54 Kyle Hamilton wrote:
> I must also point out something:
>
> NSS (at least up until 2004 -- I don't know if this has been changed,
> but the MoFo position espoused by I believe Nelson and Frank was that
> it wouldn't change) doesn't rely on any of the X.509v3 certificate
> fields of embedded trust anchors when figuring out whether to extend
> trust. Thus, changing it won't have any practical value anyway.
Are you saying that NSS *never* checks the "notAfter" dates of its built-in
Root Certificates?
If so, does this mean that products relying on NSS will still trust built-in
Root Certificates after those Root Certificates have expired?
> (The argument was that X.509 makes a good container format for
> distributing trust anchors -- the public keys -- along with display
> metadata, but that the trust anchor itself could be distributed
> separately from the X.509 container and thus should not be subject to
> any policy statements included in that container. Which didn't make
> any sense to me at the time, and still doesn't -- since that container
> is signed by that key anyway, and I would expect it to adhere to the
> CPS espoused by that key -- but that's how it was explained.)
>
> -Kyle H
>
> 2008/6/5 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>:
> > Rob Stradling:
> >
> > 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".
> >
> >
> > You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little
> > bit for clarity...
> >
> > 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.
> >
> >
> > Correct.
> >
> > 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).
> >
> >
> > Also correct.
> >
> > 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).
> >
> >
> > Update rates are apparently not so bad, but supposed CAs would replace
> > their keys with new and bigger ones, having a target date, when the old
> > roots will be removed, they would make sure that subscribers are using
> > certificates issued by a new root.
> >
> > 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.
> >
> > Well, I think you are introducing an extra step here. Supposed that CAs
> > indeed would agree to re-issue their current 1024 and smaller keys with a
> > expiration date at some time around 2010, those CAs will most likely also
> > want to have a new root with a bigger key size ready from which they'll
> > want to issue certificates. Because the old root wouldn't be valid
> > anymore in 2010, they really would be at a disadvantage because they
> > won't have enough time to transition to a newer one.
> >
> > Now, in practical terms such a process and transition takes about three
> > years from the moment the new root is created, submitted for inclusion,
> > starting to issue from the new root and make the old root obsolete. One
> > must take into account at least a one year transition period for the EE
> > certs which are still valid (there are some rumors that some CAs issue
> > certs with a validity of 10 years, so they would have to get new certs
> > anyway during that time ;-) ) and CRLs still must be issued from that
> > root until the lasts certificate expires or is revoked.
> >
> > With your proposal, CAs would have first to change their 1024 bit keys to
> > an earlier expiration date, then obviously request to add a new root
> > anyway. I wouldn't want to be in the situation to have a root with
> > validity to only 2010 (or valid-for-not-too-far-beyond) without a
> > acceptable replacement and time to transition.
> >
> > And in the future, Mozilla users (even
> > with...at that point in t
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]
> 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: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] > 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 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 Wednesday 04 June 2008 21:32:17 Nelson B Bolyard wrote: > Rob Stradling wrote, On 2008-06-04 04:45: > > 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. > > That plan appeals to me. :-) > > Disadvantages: > > - Each affected CA would have to spend some time reissuing their Root > > Cetificate. > > 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. 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? On a kind-of-related note... Bug 406794. GlobalSign want to do something very similar to what I've suggested, albeit with a 2048-bit Root Key and extending (rather than reducing) the expiry date. It's obviously not too much of "a huge challenge and investment" for them. > > - 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. > > Yes, that's also an issue. NSS treats AKID extensions as requirements. > When the issuer says to the relying party, through an AKID extension, > "you must rely on the issuer cert with this issuer name and serial number" > NSS does so. I'm afraid the solution, for CAs that used that field, > may be for them to reissue certs with the offending AKID extension. 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. > We keep telling CAs NOT to include the part of an AKID that names the > issuer's issuer and the issuer's serial number, but many CAs keep on doing > it anyway. The OpenSSL programs that create certs do that by default, > IINM, requiring extra work (I gather) to avoid including that info in the > AKID. I have suspected for some time now that the reason CAs keep > including that info is because they haven't figured out how to stop the > OpenSSL program from doing so. :( > > ___ > 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: 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: Comodo request for EV root inclusion (COMODO Certification Authority)
On Wednesday 19 March 2008, Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > > 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." > > The naming convention suggest that these intermediate CAs will issue > (only) EV certificates. I'm sorry that I misunderstood that. Sorry, I fear I've confused you even further. Those two intermediate CAs will issue only EV Certificates. The naming convention is correct to imply that this is the case. > > 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. > > Are you issuing DV certificates from the intermediate CA certificates > mentioned above? No. Absolutely not. > Or are there other intermediate CA certificates > operating under this root besides the two mentioned above? Yes. To repeat what I said... "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. > > Great, looking forward to that. 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: 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=636&file=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
use the legacy root as a trust anchor and in other cases to > use the new EV-specific root as a trust anchor. > > So, to summarize the situation as I understand it: Adding new EV roots > was basically a hack to get IE7 on XP to treat EV certs properly. > Cross-signing using legacy roots was then a hack to get older browsers > (like Firefox 2) to recognize EV 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
