Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Gervase Markham via dev-security-policy]

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

[Doug Beattie via dev-security-policy]

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

[Gervase Markham via dev-security-policy]

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

[Gervase Markham via dev-security-policy]

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

[Nick Lamb via dev-security-policy]

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

Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Han Yuwei via dev-security-policy]

A question:How would a domain holder express denial for certain certificate 
requests?
___
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

[Gervase Markham via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Lee via dev-security-policy]

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

[Ryan Sleevi via dev-security-policy]

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

[Lee via dev-security-policy]

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

Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

[Gervase Markham via dev-security-policy]

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."

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