Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 09/05/17 18:25, Doug Beattie wrote: > I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by > 21st July 2017. > > I'm assuming this is the latest official draft: > > https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Yes :-) > Specifically, does this mean all new domain validations must conform to the > 10 methods, > or that all new issuance > must be based on domains validated with only these 10 methods? It means that all new validations must be done using one of the 10 methods. The rules for information reuse will, I hope, be clarified in an upcoming ballot in the CAB Forum. Assuming that ballot doesn't say anything ridiculous, Mozilla will allow reuse according to those rules. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
Gerv, I'm not clear on what you mean by CAs must use only the 10 Blessed Methods by 21st July 2017. I'm assuming this is the latest official draft: https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md Specifically, does this mean all new domain validations must conform to the 10 methods, or that all new issuance must be based on domains validated with only these 10 methods? Doug > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > Gervase Markham via dev-security-policy > Sent: Tuesday, May 9, 2017 12:58 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Policy 2.5 Proposal: Indicate direction of travel with respect to > permitted domain validation methods > > On 01/05/17 10:13, Gervase Markham wrote: > > This would involve replacing section 2.2.3 of the policy with: > > > > Incorporated as drafted. CAs should take note (from this change and from the > CA Communication) that Mozilla's policy is moving in the direction of > requiring > the 10 Blessed Methods alone, and that the deadline is 21st July 2017. > > Gerv > ___ > 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: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 01/05/17 10:13, Gervase Markham wrote: > This would involve replacing section 2.2.3 of the policy with: Incorporated as drafted. CAs should take note (from this change and from the CA Communication) that Mozilla's policy is moving in the direction of requiring the 10 Blessed Methods alone, and that the deadline is 21st July 2017. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 03/05/17 21:31, Han Yuwei wrote: > A question:How would a domain holder express denial for certain certificate > requests? Please can you post new questions as new threads rather than as replies to existing threads on another topic? The answer to your question is that they can define which CAs they allow using CAA (RFC 6844) but there is no mechanism yet for them to deny e.g. requests for a DV cert. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On Monday, 1 May 2017 22:02:58 UTC+1, Lee wrote: > Maybe it's because I've worked with some incredibly bad auditors, but > the way I read the proposal, doing anything other than one of those > exact 10 methods is risking an audit failure. > How would you word the policy to make it clear that while a CA is > required to use one of those 10 methods, the CA is also allowed to do > additional/stricter checks? I don't think it's necessary to spell out that a CA can do additional checks. The CA can also own a pizzeria, or teach all its employees to dance, and the policy rightly says nothing about that. On the other hand, whether other checks are "stricter" may be in the eye of the beholder. If they comply exactly with the relevant section of 3.2.2.4 then we know we're happy, otherwise who knows? Consider 3.2.2.4.6, a 112-bit random token chosen by a CA employee rolling a bunch of fair hexadecimal dice and writing down what they got is fine for passing 3.2.2.4.6. If a CA wishes to instead use UUIDs (assuming they have a good quality random number generator spitting out version 4 random UUIDs) that's fine too. Arguably implementing ACME http-01 validation is better, because that binds the validation to the applicant, closing a hole often found in validations today. But regardless of whether you think that's important, http-01 complies with 3.2.2.4.6 as well, aspects of 3.2.2.4.6 were actually modelled on it. On the other hand, maybe a CA comes up with something quite different, maybe they want to validate web sites by having a path famous-ca-name/validation.dll and they pass in an XML input which the remote server needs to process and respond to. What we do NOT want in this policy is to either make it Mozilla's job to examine every such new method and figure out if it's safe, or to just let the CA vouch for it as being "stricter" on their say so. Although we have occasionally caught CAs just straight up lying, much more often the problem is _incompetence_. The people running a CA are not experts on this stuff, so when they invent a new method there's a good chance it's flawed not because they intentionally designed in a weakness but because they lack the skills internally to identify a risk, and because they have no public review process by which others might spot it for them. So Ballot 169 (and this Mozilla policy) eliminate the problem by telling them not to roll their own. There will still probably be implementation flaws, that can't be entirely prevented, but I believe this (whether as Mozilla policy) or in the BRs represents a step firmly in the right direction. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 01/05/17 18:53, Lee wrote: > You seem to be replacing a "meets or exceeds" requirement with a > "strictly meets" requirement. That is not particularly the intention. I think that the Baseline nature of the Baseline Requirements means that CAs know it's generally OK to go above and beyond what it requires. > In other words, make it clear to an auditor that while the CA must > meet the baseline requirements, it's not an audit failure if they go > above & beyond the minimum requirements of domain validation. Well, CAs are not audited to the Mozilla Policy, they are audited to the BRs. :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On Mon, May 1, 2017 at 5:02 PM, Lee via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Maybe it's because I've worked with some incredibly bad auditors, but > the way I read the proposal, doing anything other than one of those > exact 10 methods is risking an audit failure. > Well, you can hopefully understand why requiring exactly those 10 methods IS desired :) > How would you word the policy to make it clear that while a CA is > required to use one of those 10 methods, the CA is also allowed to do > additional/stricter checks? I wouldn't think it would be necessary, any more than a CA that adds additional checks to identity validation (of which many do) doesn't require additional details to permit it :) The BRs define the minimum, not the absolute :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 5/1/17, Ryan Sleevi wrote: > On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 5/1/17, Gervase Markham via dev-security-policy >> wrote: >> > The last CA Communication laid down our policy of only permitting the >> > 10 >> > Blessed Methods of domain validation. A CA Communication is an official >> > vehicle for Mozilla Policy so this is now policy, but it's not >> > reflected >> > in the main policy doc. I was planning to wait until the latest version >> > of the BRs had all 10 methods in, but that ballot (ballot 190) seems to >> > be taking a bit of time to draft. So perhaps it would be good to add >> > language to indicate direction of travel. >> > >> > This would involve replacing section 2.2.3 of the policy with: >> > >> > "for a certificate capable of being used for SSL-enabled servers, the >> > CA >> > must ensure that the applicant has registered the domain(s) referenced >> > in the certificate or has been authorized by the domain registrant to >> > act on their behalf. This must be done using one or more of the 10 >> > methods documented in section 3.2.2.4 of version 1.4.1 (and not any >> > other version) of the CA/Browser Forum Baseline Requirements. The CA's >> > CP/CPS must clearly specify the procedure(s) that the CA employs, and >> > each documented procedure should state which subsection of 3.2.2.4 it >> > is >> > complying with. Even if the current version of the BRs contains a >> > method >> > 3.2.2.4.11, CAs are not permitted to use this method." >> >> You seem to be replacing a "meets or exceeds" requirement with a >> "strictly meets" requirement. >> >> I'd suggest something along the lines of >> The CA MUST use one of the allowed methods of domain validation >> () and, in addition, >> MAY use additional and/or stricter methods of domain validation. >> >> In other words, make it clear to an auditor that while the CA must >> meet the baseline requirements, it's not an audit failure if they go >> above & beyond the minimum requirements of domain validation. >> >> Regards, >> Lee > > > You can only go "above and beyond" if you're implementing those literal 10 > methods. That is, there is a real risk with that MAY that it may be > interpreted as reintroducing the "Any other method" loophole that's > explicitly trying to be avoided. > > Any CA who is "exceeding" this method strictly meets the definition. Maybe it's because I've worked with some incredibly bad auditors, but the way I read the proposal, doing anything other than one of those exact 10 methods is risking an audit failure. How would you word the policy to make it clear that while a CA is required to use one of those 10 methods, the CA is also allowed to do additional/stricter checks? Regards, Lee ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On Mon, May 1, 2017 at 1:53 PM, Lee via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 5/1/17, Gervase Markham via dev-security-policy > wrote: > > The last CA Communication laid down our policy of only permitting the 10 > > Blessed Methods of domain validation. A CA Communication is an official > > vehicle for Mozilla Policy so this is now policy, but it's not reflected > > in the main policy doc. I was planning to wait until the latest version > > of the BRs had all 10 methods in, but that ballot (ballot 190) seems to > > be taking a bit of time to draft. So perhaps it would be good to add > > language to indicate direction of travel. > > > > This would involve replacing section 2.2.3 of the policy with: > > > > "for a certificate capable of being used for SSL-enabled servers, the CA > > must ensure that the applicant has registered the domain(s) referenced > > in the certificate or has been authorized by the domain registrant to > > act on their behalf. This must be done using one or more of the 10 > > methods documented in section 3.2.2.4 of version 1.4.1 (and not any > > other version) of the CA/Browser Forum Baseline Requirements. The CA's > > CP/CPS must clearly specify the procedure(s) that the CA employs, and > > each documented procedure should state which subsection of 3.2.2.4 it is > > complying with. Even if the current version of the BRs contains a method > > 3.2.2.4.11, CAs are not permitted to use this method." > > You seem to be replacing a "meets or exceeds" requirement with a > "strictly meets" requirement. > > I'd suggest something along the lines of > The CA MUST use one of the allowed methods of domain validation > () and, in addition, > MAY use additional and/or stricter methods of domain validation. > > In other words, make it clear to an auditor that while the CA must > meet the baseline requirements, it's not an audit failure if they go > above & beyond the minimum requirements of domain validation. > > Regards, > Lee You can only go "above and beyond" if you're implementing those literal 10 methods. That is, there is a real risk with that MAY that it may be interpreted as reintroducing the "Any other method" loophole that's explicitly trying to be avoided. Any CA who is "exceeding" this method strictly meets the definition. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods
On 5/1/17, Gervase Markham via dev-security-policy wrote: > The last CA Communication laid down our policy of only permitting the 10 > Blessed Methods of domain validation. A CA Communication is an official > vehicle for Mozilla Policy so this is now policy, but it's not reflected > in the main policy doc. I was planning to wait until the latest version > of the BRs had all 10 methods in, but that ballot (ballot 190) seems to > be taking a bit of time to draft. So perhaps it would be good to add > language to indicate direction of travel. > > This would involve replacing section 2.2.3 of the policy with: > > "for a certificate capable of being used for SSL-enabled servers, the CA > must ensure that the applicant has registered the domain(s) referenced > in the certificate or has been authorized by the domain registrant to > act on their behalf. This must be done using one or more of the 10 > methods documented in section 3.2.2.4 of version 1.4.1 (and not any > other version) of the CA/Browser Forum Baseline Requirements. The CA's > CP/CPS must clearly specify the procedure(s) that the CA employs, and > each documented procedure should state which subsection of 3.2.2.4 it is > complying with. Even if the current version of the BRs contains a method > 3.2.2.4.11, CAs are not permitted to use this method." You seem to be replacing a "meets or exceeds" requirement with a "strictly meets" requirement. I'd suggest something along the lines of The CA MUST use one of the allowed methods of domain validation () and, in addition, MAY use additional and/or stricter methods of domain validation. In other words, make it clear to an auditor that while the CA must meet the baseline requirements, it's not an audit failure if they go above & beyond the minimum requirements of domain validation. Regards, Lee > > Once the BRs are back to the way they should be, a few edits to this > para should normalize the situation. > > There is a deadline associated with this change of July 21st 2017; > traditionally, we communicate deadlines for particular requirements > out-of-band. > > This is: https://github.com/mozilla/pkipolicy/issues/77 > > --- > > This is a proposed update to Mozilla's root store policy for version > 2.5. Please keep discussion in this group rather than on Github. Silence > is consent. > > Policy 2.4.1 (current version): > https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md > Update process: > https://wiki.mozilla.org/CA:CertPolicyUpdates > ___ > 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