Re: GoDaddy Misissuance Action Items
On 13/02/17 23:53, Wayne Thayer wrote: > Gerv - this makes sense and it is GoDaddy's intent to perform these steps > within 3 months. No significant objections have been put forward about this action plan, and so I have filed a Bugzilla bug to track GoDaddy's implementation: https://bugzilla.mozilla.org/show_bug.cgi?id=1341014 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 23:13, Santhan Raj wrote: > One thing to highlight here is that the WebTrust audits are performed > against the BRs and not against the root program requirements. This is true, although (apart from the relative importance of domain validation) this is similarly true of many items in the Mozilla requirements which we cannot directly check. > So hopefully > 169 makes it's way to BR soon. I am hopeful that most or all of the methods will be back in the BRs soon. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: GoDaddy Misissuance Action Items
> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Gervase > Markham via dev-security-policy > Here is our proposed remediation plan for GoDaddy. > > 1) As with all CAs, update all their domain validation code to use one of the > 10 > approved methods; > > 2) Implement comprehensive automated testing for their domain validation > code for all issuance systems; > > 3) Make sure those tests automatically run when any change is made to the > code, before deployment, such that deployment is gated on a pass; > > 4) Get a statement from their auditors that these tests have been created > and positioned correctly in the deployment workflow. > > All steps to be completed within 3 months. > > Comments on this plan are welcome, including from GoDaddy. > Gerv - this makes sense and it is GoDaddy's intent to perform these steps within 3 months. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On Monday, February 13, 2017 at 3:14:06 PM UTC-8, Santhan Raj wrote: > On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote: > > > That is why, despite some IPR-related tangles, Mozilla will be requiring > > in its next CA Communication that all CAs move to using only those > > documented methods in a fairly short timeframe, regardless of what the > > BRs say. CAs may wish to not wait for that communication to arrive > > before starting to adapt their systems. > > Grev, > > One thing to highlight here is that the WebTrust audits are performed against > the BRs and not against the root program requirements. I.e., unless ballot > 169 makes it to the BRs, a (naughty) CA may still chose to use "any other > method" and it will not be flagged in the audit report, provided they > disclose as such in the CP/CPS. This means, Mozilla will have to review > (each) CA's CP/CPS to determine whether it validates _only_ using methods > specified in "the documented methods" and will have to do so for each CP/CPS > update. So hopefully 169 makes it's way to BR soon. > > -Santhan And sorry I misspelled you name!!! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote: > That is why, despite some IPR-related tangles, Mozilla will be requiring > in its next CA Communication that all CAs move to using only those > documented methods in a fairly short timeframe, regardless of what the > BRs say. CAs may wish to not wait for that communication to arrive > before starting to adapt their systems. Grev, One thing to highlight here is that the WebTrust audits are performed against the BRs and not against the root program requirements. I.e., unless ballot 169 makes it to the BRs, a (naughty) CA may still chose to use "any other method" and it will not be flagged in the audit report, provided they disclose as such in the CP/CPS. This means, Mozilla will have to review (each) CA's CP/CPS to determine whether it validates _only_ using methods specified in "the documented methods" and will have to do so for each CP/CPS update. So hopefully 169 makes it's way to BR soon. -Santhan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 16:41, Nick Lamb wrote: > GoDaddy came up with). Thus, even though some of the methods from > Ballot 169 are not included in the Baseline Requirements today, > Mozilla intends to oblige root programme members to pick from those > ten methods. Yes. And this is permitted by the BRs because they currently have an "any other method" method, which could cover any of the ones whose actual text is missing. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/17 14:34, Nick Lamb wrote: > I don't think Ballot 169 represents best practices per se. Instead as > with the rest of the Baseline Requirements what we have here are > _minimums_, we aren't asking that CAs should do no more than what is > described, but that they must do at least what is described. Well, OK. That wasn't really the focus of the statement. I suspect that the ballot 169 methods are bar-raising for most CAs, even if they aren't yet as watertight as they could be. > Anyway, I have a nitpick for your GoDaddy remediation plan. I think > in item (1) it's not clear that it's fine for a CA to choose to > implement many or even all ten methods, and even for them to have > other methods - what's important is that for any particular name > validated their process ensures at least one of the ten Ballot 169 > methods was used. That is my intent; I'm happy to make that clear. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On 13/02/2017 16:15, Jürgen Brauckmann via dev-security-policy wrote: > Gervase Markham via dev-security-policy schrieb: >> 1) As with all CAs, update all their domain validation code to use one >> of the 10 approved methods; > > I'm probably confused regarding BRs pre/post Ballot 181: Aren't there > only 4 methods per Ballot 181? My understanding is that while Ballot 181 included only those methods from Ballot 169 that were not affected by any patent exclusion notices, plus "any other method", Mozilla will disallow "any other method" and instead ask CAs to limit their validation methods to the ones from Ballot 169. This approach would still be compliant with the BRs because the 6 methods affected by the patent exclusions can be counted as implementations of "any other method". ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
On Monday, 13 February 2017 15:15:47 UTC, Jürgen Brauckmann wrote: > I'm probably confused regarding BRs pre/post Ballot 181: Aren't there > only 4 methods per Ballot 181? > > Jürgen Ballot 169 identified exactly 10 methods. Although this ballot passed unanimously, meaning that both CA members and Browser members on the whole supported these 10 methods, subsequently the CA/B effectively undid the changes from Ballot 169 because of patent concerns. Mozilla's position as I understand it is that regardless of what happens with patents, they don't want CAs to continue inventing their own ad hoc validation methods (witness the flaws in the method GoDaddy came up with). Thus, even though some of the methods from Ballot 169 are not included in the Baseline Requirements today, Mozilla intends to oblige root programme members to pick from those ten methods. So far as I can see three factors might cause a CA to decide it's necessary in their opinion to reject any particular method. These are 1. The method isn't allowed for them under the BRs, or another root programmes rules. 2. The method is subject to patent or other legal rights and they're unable or unwilling to agree acceptable terms to use the method. 3. The method is incompatible with the CA's business model or doesn't meet their own standards for validation. For (1) I believe the BRs currently allow all ten Ballot 169 methods because they have an "any method" escape clause. If a CA believes another root programme requirement conflicts this would be the right forum for the CA to tell Mozilla about it. For (2) where a CA is aware of such rights and they weren't already revealed to the CA/B it'd sure be helpful to know about them here. For (3) I don't see any problem unless the CA rules out all ten methods. If any CA is on the verge of doing that they should definitely reach out to us in m.d.s.policy to explain their thinking. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GoDaddy Misissuance Action Items
Gervase Markham via dev-security-policy schrieb: > 1) As with all CAs, update all their domain validation code to use one > of the 10 approved methods; I'm probably confused regarding BRs pre/post Ballot 181: Aren't there only 4 methods per Ballot 181? Jürgen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
GoDaddy Misissuance Action Items
As members of the group will be aware, last month GoDaddy filed an incident report concerning a problem with their domain validation system. Domain validation is the most important task a CA can undertake, any any flaws in it are serious. This is why the CAB Forum has been working for some time on carefully documenting best practice in domain validation, and passed ballot 169 to incorporate them into the Baseline Requirements. The problem experienced by GoDaddy is one explicitly foreseen by the drafters of those best-practice validation methods. That is why, despite some IPR-related tangles, Mozilla will be requiring in its next CA Communication that all CAs move to using only those documented methods in a fairly short timeframe, regardless of what the BRs say. CAs may wish to not wait for that communication to arrive before starting to adapt their systems. We note that GoDaddy's response to this issue was delayed because it was not submitted through their expected channels. We will be working in the CAB Forum to get the CAB Forum to host a master list of CA security contacts, open both to CAs who are and are not members of the Forum, to try and reduce the likelihood of this happening in future. We asked GoDaddy for a list of domains where they revoked the cert because they could not re-do the validation, and compared them to the Alexa top 1M domains. There were no hits in the top 10,000, and only 15 in the top 100,000. As attackers tend to target popular domains, we feel it is _unlikely_ that any certs ended up in the wrong hands as a result of this problem. So we do not plan to add any of the 8951 certs to OneCRL. Here is our proposed remediation plan for GoDaddy. 1) As with all CAs, update all their domain validation code to use one of the 10 approved methods; 2) Implement comprehensive automated testing for their domain validation code for all issuance systems; 3) Make sure those tests automatically run when any change is made to the code, before deployment, such that deployment is gated on a pass; 4) Get a statement from their auditors that these tests have been created and positioned correctly in the deployment workflow. All steps to be completed within 3 months. Comments on this plan are welcome, including from GoDaddy. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
