Policy 2.4 Proposal: Update required version number of Baseline Requirements to 1.3.7

[Gervase Markham]

Point 12 of the Inclusion section requires conformance to the Baseline
Requirements version 1.3, released on 16th April 2015. The current
version is 1.4.1.

I propose changing to version 1.3.7. This is the one before the version
which updated the domain validation requirements and which has had to be
walked back due to the IPR issues. Once the dust settles, we can look at
updating again. See the bug for more info on the logic here.

This is: https://github.com/mozilla/pkipolicy/issues/30

-------

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates

[Jeremy Rowley]

I agree with this approach. Nothing of note was include after the domain
validation passed so making 1.3.7 the effective version makes sense.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

Gerv,

I'd like to push a little and suggest that the IP issues are not a
significant reason for Mozilla not to formalize on 1.4.1 (e.g. with
169 included)

Notably, 1.3.7 also has IP encumbrances - and uncertainty - the same
as 1.4.1, so presumably, Mozilla is OK with having encumbered methods
included. Considering some of these exclusions have existed since the
BR's adoption, that doesn't seem an unreasonable conclusion.

So what's the difference between 1.3.7 and 1.4.1?
- A few methods were introduced which may or may not be encumbered
- The ability for the CA to select anything they want to argue is
equivalent is removed

I would presume that your contention with 139 is not because new
methods were (potentially) encumbered, but on the basis that it
removes the any other method. Given that there are other methods
available (as reaffirmed by Ballot 181) that have no encumbrances by
CA/B Forum members, and given that potentially *any or all* of the
methods used may be encumbered by non-Forum members (who have no
obligation to disclose), it does not seem that it creates any new
meaningful risk for Mozilla to impose 1.4.1 upon CAs.

Indeed, if anything, the recent events shown with GoDaddy hopefully
demonstrates to Mozilla that 1.4.1 (that is, with Ballot 169 included)
provides better security to your users and the Internet at large, by
formally prohibiting the use of methods outside of that list.

Given that you can always revisit it if a CA can provide demonstrable
evidence of concern and proposed alternatives, without waiting on the
CA/Browser Forum, I'd like to encourage you that 1.4.1 is no worse
than 1.3.7, either technically or from an IP encumbrance perspective,
but is significantly and substantially better.

[Gervase Markham]

On 13/01/17 01:56, Ryan Sleevi wrote:
> Notably, 1.3.7 also has IP encumbrances - and uncertainty - the same
> as 1.4.1, so presumably, Mozilla is OK with having encumbered methods
> included. Considering some of these exclusions have existed since the
> BR's adoption, that doesn't seem an unreasonable conclusion.

This is a fair point, to a degree. IP issues with the documented methods
are not avoided just because they are documented in a document which
existed before the disclosures were finally properly filed.

> So what's the difference between 1.3.7 and 1.4.1?
> - A few methods were introduced which may or may not be encumbered
> - The ability for the CA to select anything they want to argue is
> equivalent is removed
>
> I would presume that your contention with 139 is not because new
> methods were (potentially) encumbered, but on the basis that it
> removes the any other method.

Yes, I think that's more it. I was nervous about removing that "escape
hatch" for CAs before the IPR questions were more fully settled.

> Given that there are other methods
> available (as reaffirmed by Ballot 181) that have no encumbrances by
> CA/B Forum members, and given that potentially *any or all* of the
> methods used may be encumbered by non-Forum members (who have no
> obligation to disclose), it does not seem that it creates any new
> meaningful risk for Mozilla to impose 1.4.1 upon CAs.

It's true that the passing of 181, which had not happened when I
prepared my original thoughts for this Github issue, does clarify
matters. And it includes at least one 'unencumbered' automatable method.

> Given that you can always revisit it if a CA can provide demonstrable
> evidence of concern and proposed alternatives, without waiting on the
> CA/Browser Forum, I'd like to encourage you that 1.4.1 is no worse
> than 1.3.7, either technically or from an IP encumbrance perspective,
> but is significantly and substantially better.

The GoDaddy incident is relevant, I agree.

OK, sold. Many recent changes to the BRs have been
additionally-permissive, and so don't require a lead time for CAs to
adopt. The most recent change which is not so is ballot 174, which
changed the requirements about what CAs must put in their CPs and CPSes
when their issuance practices conflict with the BRs due to local law.
That passed on 29th August 2016, 4.5 months ago, and led to version
1.3.9. By the time we ship policy 2.4, I expect it'll be nearly 6 months.

So we could move to 1.3.7, 1.4.1, or 1.4.2. So the real policy question
here is:

"Does Mozilla want to leave the 'any other method' option open to CAs
and, if so, for how long?"

If the answer is no, we should adopt 1.4.1 and require strict compliance
(i.e. you can't actually use 1.4.2 or later) for section 3.2.2.4,
although we might allow any later version for all other sections.

If the answer is yes, we should adopt 1.4.2, and permit compliance to
later versions. When we decide to stop permitting "any other method", we
either update the version number to a later version of the BRs if it has
that option removed by then, or we simply state that we don't allow it
any more.

Google's policy, AIUI, is that they are requiring strict 10-method
compliance by the original effective date of ballot 169, which is 1st
March 2017. I suspect we won't ship CA Policy 2.4 before that, although
I'd like to ship soon after. Because of Google's requirement, I expect
most CAs will be working towards that date anyway. So we could probably
piggy-back on that.

Comments?

Gerv

[Ryan Sleevi]

On Mon, Jan 16, 2017 at 3:30 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 13/01/17 01:56, Ryan Sleevi wrote:

>> Notably, 1.3.7 also has IP encumbrances - and uncertainty - the same
>> as 1.4.1, so presumably, Mozilla is OK with having encumbered methods
>> included. Considering some of these exclusions have existed since the
>> BR's adoption, that doesn't seem an unreasonable conclusion.
>

> This is a fair point, to a degree. IP issues with the documented methods
> are not avoided just because they are documented in a document which
> existed before the disclosures were finally properly filed.
>

>> So what's the difference between 1.3.7 and 1.4.1?
>> - A few methods were introduced which may or may not be encumbered
>> - The ability for the CA to select anything they want to argue is
>> equivalent is removed
>>
>> I would presume that your contention with 139 is not because new
>> methods were (potentially) encumbered, but on the basis that it
>> removes the any other method.
>

> Yes, I think that's more it. I was nervous about removing that "escape
> hatch" for CAs before the IPR questions were more fully settled.
>

>> Given that there are other methods
>> available (as reaffirmed by Ballot 181) that have no encumbrances by
>> CA/B Forum members, and given that potentially *any or all* of the
>> methods used may be encumbered by non-Forum members (who have no
>> obligation to disclose), it does not seem that it creates any new
>> meaningful risk for Mozilla to impose 1.4.1 upon CAs.
>

> It's true that the passing of 181, which had not happened when I
> prepared my original thoughts for this Github issue, does clarify
> matters. And it includes at least one 'unencumbered' automatable method.
>

>> Given that you can always revisit it if a CA can provide demonstrable
>> evidence of concern and proposed alternatives, without waiting on the
>> CA/Browser Forum, I'd like to encourage you that 1.4.1 is no worse
>> than 1.3.7, either technically or from an IP encumbrance perspective,
>> but is significantly and substantially better.
>

It depends on what your view is with respect to the 'minimum' version
that is required under the existing Mozilla Policy.

BRs 1.3.0 ( https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
) already include the clause (in Section 2.2) that:
"The CA SHALL publicly give effect to these Requirements and represent
that it will adhere to the latest published version."

So despite Mozilla Policy requiring 1.3.0, up until the passage of
Ballots 180/181, CAs were already on the hook and expected to comply
with the BRs 1.4.1 - meaning implementing the methods of Ballot 169 by
1 March 2017.

Up until the questions by Apple in the Forum, there had not been any
debate or disagreement about what the 'latest published version' was,
either within the Forum or within mozilla.dev.security.policy. It's
unclear whether Mozilla shares Apple's interpretation about the
legitimacy of all versions of the BRs prior to 1.4.2, but based on
your replies, it does not seem you agree on substance. That is, BRs
1.3.0 were/are a valid version of the BRs, at least within the spirit
and intent of the Mozilla policy, and so too by that logic are
versions 1.3.7, 1.4.1, and 1.4.2, which were passed in the same
manner.

I mention all of this to highlight that, up until the passage of
Ballots 180/181, and the adoption of 1.4.2, Mozilla Policy was already
requiring that CAs comply with 169 by 1 March 2017, by virtue of
Section 2.2. If Mozilla agrees that Ballot 169 is still valuable, then
it seems something that can be simply be done as a CA communication
prior to/independent of the adoption of Mozilla Policy 2.4, and it
seems that the reference to a specific version in Policy 2.4 is
perhaps superflous, so long as the Section 2.2 remains in force in the
BRs.

Nothing in Ballot 169 would inherently contradict the text in Ballots
180/181. However, a CA conforming only to the BRs 1.4.2 would not be
sufficient, as Mozilla would simply communicate the above-and-beyond
expectation (using a CA communication), and then include it in the set
of updates for Policy 2.4 if the Forum hasn't already resolved the
issue(s) by then. But if your concern is that CAs haven't had time or
a clear communication about what's expected of them, hopefully Section
2.2 shows that they have (up until Jan 7 of this year).

[Gervase Markham]

On 17/01/17 23:32, Ryan Sleevi wrote:
> BRs 1.3.0 ( https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.pdf
> ) already include the clause (in Section 2.2) that:
> "The CA SHALL publicly give effect to these Requirements and represent
> that it will adhere to the latest published version."

Hmm. I was not aware of that. I wonder how many CAs are aware that
according to the BRs, any changes to the BRs by default come in
immediately the motion is passed and the document is updated. Perhaps
I'm the only person who didn't know this.

> So despite Mozilla Policy requiring 1.3.0, up until the passage of
> Ballots 180/181, CAs were already on the hook and expected to comply
> with the BRs 1.4.1 - meaning implementing the methods of Ballot 169 by
> 1 March 2017.
>
> Up until the questions by Apple in the Forum, there had not been any
> debate or disagreement about what the 'latest published version' was,
> either within the Forum or within mozilla.dev.security.policy.

You'll need to give me a more specific reference; I don't remember any
such question, and a quick scan back through top-level posts from Apple
employees hasn't revealed it.

> It's
> unclear whether Mozilla shares Apple's interpretation about the
> legitimacy of all versions of the BRs prior to 1.4.2, but based on
> your replies, it does not seem you agree on substance. That is, BRs
> 1.3.0 were/are a valid version of the BRs, at least within the spirit
> and intent of the Mozilla policy, and so too by that logic are
> versions 1.3.7, 1.4.1, and 1.4.2, which were passed in the same
> manner.

Yes, that's my view.

> and it
> seems that the reference to a specific version in Policy 2.4 is
> perhaps superflous, so long as the Section 2.2 remains in force in the
> BRs.

So the suggestion is that we just update our policy to require adherence
to the latest version of the BRs, on the basis that this is what the BRs
require anyway?

Gerv

[Ryan Sleevi]

On Wed, Jan 18, 2017 at 7:16 AM, Gervase Markham <ge...@mozilla.org> wrote:

> On 17/01/17 23:32, Ryan Sleevi wrote:
> > BRs 1.3.0 ( https://cabforum.org/wp-content/uploads/CAB-Forum-BR-
> 1.3.0.pdf

> > ) already include the clause (in Section 2.2) that:
> > "The CA SHALL publicly give effect to these Requirements and represent
> > that it will adhere to the latest published version."
>

> Hmm. I was not aware of that. I wonder how many CAs are aware that
> according to the BRs, any changes to the BRs by default come in
> immediately the motion is passed and the document is updated. Perhaps
> I'm the only person who didn't know this.
>

I am surprised, since we discussed it during the Scottsdale F2F in the
CA/Browser Forum :)

See
https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Compliance-Assessment-Coordination-with-auditors-and-browsers

"Some CAs say they were audited to an older version of the BRs; therefore
it would appear that the CA only thinks the need to comply with the older
version of the BRs. This is not correct as the BRs state that the CA has to
have a CPS statement that they comply with the latest version of the BRs."

> You'll need to give me a more specific reference; I don't remember any
> such question, and a quick scan back through top-level posts from Apple
> employees hasn't revealed it.
>

There's not some single top-level post that states this - but it was the
whole purpose of Ballots 180/181, which is the view that the Forum did not
follow its Bylaws (with respect to either voting vs IP review period or
with respect to the formation of a PAG following disclosures, going back to
the first adoption of the BRs) therefore invalidates the adoption. Which is
why we had Ballots 180/181 - to ensure that all members were happy that
'the process' was followed and all documents produced were done so in a way
consistent with the Bylaws.

It's procedural administrivia, certainly, and not one anyone advanced until
Apple raised concerns, largely in part do to the proposed ways of resolving
the lack of disclosure notices being provided during much of Dean's
chairing.

> So the suggestion is that we just update our policy to require adherence
> to the latest version of the BRs, on the basis that this is what the BRs
> require anyway?

Yes.

That gets you to Ballot 181 / v 1.4.2. However, you would then need to
clarify (at least for 1.4.2) that the only acceptable forms of any other
are the 169 methods.

[Gervase Markham]

On 12/01/17 16:45, Gervase Markham wrote:
> Point 12 of the Inclusion section requires conformance to the Baseline
> Requirements version 1.3, released on 16th April 2015. The current
> version is 1.4.1.
>
> I propose changing to version 1.3.7. This is the one before the version
> which updated the domain validation requirements and which has had to be
> walked back due to the IPR issues. Once the dust settles, we can look at
> updating again. See the bug for more info on the logic here.

Resolution: updated to require "the latest version", together with a
little wordsmithing to more generically describe the existing list of
exceptions to the BRs, so it could be more easily added to in the future.

Gerv