Re: New wiki page on certificate revocation plans
On 04/08/14 18:16, Erwann Abalea wrote: I imagine you have access to more detailed information (OCSP URL, date/time, user location, ...), could some of it be open? Not necessarily; I suspect this data was gathered using Firefox Telemetry, where we try very hard to avoid violating a user's privacy. Aggregate pass/fail stats (and even failure reasons) are one thing; details of sites visited are another. It could be that we could break it down by CA (top level domain) without significant privacy intrusion, as most CAs secure many websites, but I suspect it would require more mods to Firefox to do that. OCSP is painful and costly to optimize, x509labs shows great availability and good performance for most CA/location combination, but this is in contradiction with real user measurements. Why, and how? Good question. Perhaps the point is that consumer internet connections are a lot flakier than the one x509labs uses. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On 05/08/14 09:34, Rob Stradling wrote: Kathleen, to work around the classic NSS path building behaviour you observed yesterday, we will issue another cross-certificate to USERTrust Legacy Secure Server CA, with a newer notBefore date, from our AddTrust External CA Root built-in root. Then, you can include this new cross-certificate in NSS instead of the one issued by the 2048-bit Entrust built-in root. We'll pull out all the stops and get this new cross-certificate issued today. Kai, just in case you were planning to tag NSS 3.16.4 within the next few hours...please wait, if you can. :-) We've issued this new cross-certificate and I've attached it to bug 1045189. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
- Original Message - From: Kurt Roeckx k...@roeckx.be To: Hubert Kario hka...@redhat.com Cc: Kathleen Wilson kwil...@mozilla.com, mozilla-dev-security-pol...@lists.mozilla.org Sent: Tuesday, August 5, 2014 12:44:13 AM Subject: Re: Removal of 1024 bit CA roots - interoperability On Mon, Aug 04, 2014 at 10:03:13AM -0400, Hubert Kario wrote: So I've analysed the data. Change (without-with) Count -+- complete -219 incomplete+120 untrusted +99 So this is in the order of 0.05% of the sites that would break? I'm happy to ignore that and just do it. 0.05% of sites doesn't mean 0.05% of users, especially if we look at local, not global, user share. Some of them are high profile sites, e.g.: volkswagen.at, dell.com, cadillaceurope.com, www.portaldasfinancas.gov.pt -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On 2014-08-05 14:22, Hubert Kario wrote: 0.05% of sites doesn't mean 0.05% of users, especially if we look at local, not global, user share. Some of them are high profile sites, e.g.: volkswagen.at, dell.com, cadillaceurope.com, www.portaldasfinancas.gov.pt It's not because they have an https site that people actually use it over https. so testing those sites: - dell.com: Doesn't work without www. It's not mentioned in your other mail, but dell.cl and dell.com.br are. They all send the same certificate, and that's not valid for those hostnames. - cadillaceurope.com: it's not valid without www. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New wiki page on certificate revocation plans
On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham g...@mozilla.org wrote: On 04/08/14 18:16, Erwann Abalea wrote: OCSP is painful and costly to optimize, x509labs shows great availability and good performance for most CA/location combination, but this is in contradiction with real user measurements. Why, and how? Good question. Perhaps the point is that consumer internet connections are a lot flakier than the one x509labs uses. It is also possible that x509labs is requesting OCSP response for the same cert over and over which means it is getting edge-cached replies. Users request responses for random certs, which could include certs just issued or rarely seen. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: New wiki page on certificate revocation plans
I think most CAs use CDNs to help serve OCSP responses quite fast and reliably. A breakdown of failure rates based on certificate provider could provide insight on what's going on. Is gathering this information too close to violating a user's privacy for Mozilla? Any chance of peering into this data further? Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Peter Bowen Sent: Tuesday, August 5, 2014 10:18 AM To: Gervase Markham Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans On Tue, Aug 5, 2014 at 2:02 AM, Gervase Markham g...@mozilla.org wrote: On 04/08/14 18:16, Erwann Abalea wrote: OCSP is painful and costly to optimize, x509labs shows great availability and good performance for most CA/location combination, but this is in contradiction with real user measurements. Why, and how? Good question. Perhaps the point is that consumer internet connections are a lot flakier than the one x509labs uses. It is also possible that x509labs is requesting OCSP response for the same cert over and over which means it is getting edge-cached replies. Users request responses for random certs, which could include certs just issued or rarely seen. Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CFCA Root Inclusion Request
On 7/29/14, 2:00 PM, Kathleen Wilson wrote: All, Thank you to those of you who have reviewed and commented on this inclusion request from CFCA. I will appreciate your opinions in response to my questions below regarding how to move forward with this request. Note that the “CFCA GT CA” root was included in Microsoft’s program in December 2012, and the “CFCA EV ROOT” root was included in Microsoft’s program in May 2013. On a matter of process/procedure, So, shall we proceed with approval/inclusion of the CFCA EV ROOT cert after verifying that CFCA has addressed the issues noted in this discussion? Or, shall we require another audit before we proceed with approval/inclusion of the CFCA EV ROOT cert? Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CFCA Root Inclusion Request
On Tue, August 5, 2014 10:26 am, Kathleen Wilson wrote: On 7/29/14, 2:00 PM, Kathleen Wilson wrote: All, Thank you to those of you who have reviewed and commented on this inclusion request from CFCA. I will appreciate your opinions in response to my questions below regarding how to move forward with this request. Note that the CFCA GT CA root was included in Microsofts program in December 2012, and the CFCA EV ROOT root was included in Microsofts program in May 2013. On a matter of process/procedure, So, shall we proceed with approval/inclusion of the CFCA EV ROOT cert after verifying that CFCA has addressed the issues noted in this discussion? Or, shall we require another audit before we proceed with approval/inclusion of the CFCA EV ROOT cert? Kathleen Kathleen, Given the compliance issues that were identified, and the number of them, it's difficult to believe the auditor matches the criteria of competent party, pursuant to sections 12 - 16 of the Mozilla Inclusion Policy. Per Section 16, it seems the burden is on the CA to establish the competence of the third party. This is somewhat distressing, since the auditor was PricewaterhouseCoopers, whose only other WebTrust audits (per https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/ ) is for the SECOM Roots. It's worth noting that the suitability of this auditor has been discussed in the past ( https://groups.google.com/d/msg/mozilla.dev.security.policy/riLXu3ZJNso/HPOvC_5c0sUJ ), and that PricewaterhouseCoopers was also responsible for the Diginotar Audit. While it is ultimately the decision of Mozilla, per the inclusion policy, as to whether the auditor meets criteria, the evidence and experience gathered so far I believe casts a serious shadow. Respectfully, and individually, I think the issues here are egregious enough, and in sufficient number, to request a new audit by a new auditor, pursuant with Mozilla's policies of requiring the CA to establish the competence of the auditor. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Regarding Mozilla auditors choosen standards
Hi Wallas,Setting aside Ryan's petulance, if I may, I think the simple answer to all your questions can be stated thusly: no one is in charge and we depend on people doing the right things.Mostly I think that works out OK but there's just no escaping that much of the PKI system relies on nothing more than "please don't do that" and "okay I promise I won't". Requirements and specifications and best practices and audits and open discussion forums such as this one all help but if any given actor chooses to lean in a different direction there is little recourse we can take. What's worse is that the rationale for taking any such action is so narrow that only the most egregious cases are ever pursued.The obvious poster child for egregious cases is DigiNotar. Cases which are not so clear cut would have to include the CFCA request under discussion right now and the TeliaSonera situation of the recent past. In both cases the concerns are real and justified and yet the available options seem limited. I'd like to see us improve upon that, but that's a whole other conversation.In any case, I hope this helps answer your questions.From: Ryan SleeviSent: Tuesday, July 29, 2014 10:47 AMOn Tue, July 29, 2014 2:01 am, Wallas Smith wrote: Thank you very much for your precise answers. This helped me to come to new questions :Which you will find already answered athttps://www.mozilla.org/en-US/about/governance/policies/security-group/certs/, as I suspected. 1) According to what I understand, when trying to express the chain of Certificate trust starting from a Mozilla User, the upper trust is placed into Governmental Regulations and/or Professional code of Conduct of auditors. Could you tell me more about the Governmental Regulations you were mentioning ? Also, is there a global regulation which gather all these governmental regulations, and who controls them ? In other words, who is on top of the chain of control ?This was already answered in my previous email, which provided enoughinformation for you to discover the relationship of ETSI and WebTrust (asAudit Frameworks) to the CA/Browser Forum's Baseline Requirements, and howthose flow into the Mozilla requirements.Which is, of course, also answered byhttps://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ 2) If I still understand you well, Mozilla never really check by themselves the good "quality" of a given CA at a specific date (by quality I am not talking about the required content which can be easily checked), but they report their responsibility to Auditors and Governmental Regulations. Do Mozilla still have some exceptional process for checking fully a CA by themselves, that could lead to the removal of a CA in their product?This is also already answered byhttps://www.mozilla.org/en-US/about/governance/policies/security-group/certs/https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/ 3) Finally, if Mozilla don't have contract with auditors, do Mozilla have contract(s) with any stratum of what I called the trust chain (with the CA itself or Governmental regulations, or above depending of your answer) to discharge their responsibility in case of failing CA? Who is responsible in case of failing/neglected/wrongly handled CA in front of the law ?Once again, already answered.https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/Also, read the CA's CPs/CPSes to understand what liabilities and how theyfit. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CFCA Root Inclusion Request
I agree with Ryan: new audit by new auditor. Since PWC did a mediocre job last time why would we expect a different result this time? Original Message From: Ryan Sleevi Sent: Tuesday, August 5, 2014 5:41 PM To: Kathleen Wilson Reply To: ryan-mozdevsecpol...@sleevi.com Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CFCA Root Inclusion Request On Tue, August 5, 2014 10:26 am, Kathleen Wilson wrote: On 7/29/14, 2:00 PM, Kathleen Wilson wrote: All, Thank you to those of you who have reviewed and commented on this inclusion request from CFCA. I will appreciate your opinions in response to my questions below regarding how to move forward with this request. Note that the CFCA GT CA root was included in Microsofts program in December 2012, and the CFCA EV ROOT root was included in Microsofts program in May 2013. On a matter of process/procedure, So, shall we proceed with approval/inclusion of the CFCA EV ROOT cert after verifying that CFCA has addressed the issues noted in this discussion? Or, shall we require another audit before we proceed with approval/inclusion of the CFCA EV ROOT cert? Kathleen Kathleen, Given the compliance issues that were identified, and the number of them, it's difficult to believe the auditor matches the criteria of competent party, pursuant to sections 12 - 16 of the Mozilla Inclusion Policy. Per Section 16, it seems the burden is on the CA to establish the competence of the third party. This is somewhat distressing, since the auditor was PricewaterhouseCoopers, whose only other WebTrust audits (per https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/included/ ) is for the SECOM Roots. It's worth noting that the suitability of this auditor has been discussed in the past ( https://groups.google.com/d/msg/mozilla.dev.security.policy/riLXu3ZJNso/HPOvC_5c0sUJ ), and that PricewaterhouseCoopers was also responsible for the Diginotar Audit. While it is ultimately the decision of Mozilla, per the inclusion policy, as to whether the auditor meets criteria, the evidence and experience gathered so far I believe casts a serious shadow. Respectfully, and individually, I think the issues here are egregious enough, and in sufficient number, to request a new audit by a new auditor, pursuant with Mozilla's policies of requiring the CA to establish the competence of the auditor. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
