[cabfpub] Root Store Policy 2.5: Call For Review and Phase-In Periods

[Gervase Markham]

Hi everyone,

I've made the last change I currently intend to make for version 2.5 of
Mozilla's Root Store Policy. The last task before shipping it is to
assess whether any of the changes require a phase-in period, i.e. for
some reason, they can't be applicable immediately.

CAs and others are requested to comment, with rationale, in the
mozilla.dev.security.policy group (i.e. not here on cabfpub) as to why
particular changes will need a phase-in period and what period they are
proposing as appropriate. This is also an opportunity for interested
parties to do a general final review.

I hope to ship the policy immediately after the CAB Forum meeting in
Berlin, which is happening from the 20th to the 22nd of June.

You can see the differences between version 2.4.1 and version 2.5 here
in diff format (click "Files Changed" and then "Load Diff"):
https://github.com/mozilla/pkipolicy/compare/2.4.1...master

or here in a more rich format:
https://github.com/mozilla/pkipolicy/compare/2.4.1...master?short_path=b7447c8
(click "Files Changed" and scroll down).

The CCADB Policy changes are trivial and can be ignored.

Here is my summary of what's changed that's significant (with section
numbers in brackets), although you should not rely on it to be complete:


1) Certificates with anyEKU have been added to the scope. (1.1)

2) CAs are required to "follow industry best practice for securing their
networks, for example by conforming to the CAB Forum Network Security
Guidelines or a successor document". (2.1)

3) Accounts which perform "Registration Authority or Delegated Third
Party functions" are now also required to have multi-factor auth. (2.1)

4) CAs are required to follow, but not required to contribute to,
mozilla.dev.security.policy. (2.1)

5) CAs are required to use only the 10 Blessed Methods for domain
validation. (2.2) This requirement has already had a deadline set for it
in the most recent CA Communication; that deadline is 21st July 2017.

6) WebTrust BR audits must now use version 2.2 or later of the audit
criteria. (3.1.1)

7) The ETSI audit criteria requirements have been updated to be
accurate. (3.1.2.2). ETSI TS 102 042 and TS 101 456 audits will only be
accepted for audit periods ending in July 2017 or earlier.

8) There are further requirements on the information that needs to be
contained in publicly-available audit information. (3.1.3)

9) Mozilla now requires that auditors be qualified in the scheme they
are using, unless agreed in writing beforehand. (3.2)

10) When CAs do their BR-required yearly update of their CPs and CPSes,
they MUST indicate this by incrementing the version number and adding a
dated changelog entry. (3.3)

11) The Mozilla CCADB Policy has been merged into the Root Store Policy,
but the requirements have not changed. (4.1/4.2)

12) CA are required at all times to operate in accordance with the
applicable CP and CPS. (5.2)

13) The requirements for what constitutes a TCSC for email have been
reformed to actually make some sense - the cert now has to have
meaningful technical constraints on rfc822Name. (5.3.1)

14) New intermediates must be disclosed in the CCADB within a week. (5.3.2)

15) Requirements for revocation are now delegated to the BRs rather than
being explicitly enumerated. (6)

16) Section 7.4 ("Transfers") has been replaced by a new section 8 which
requires CAs to notify of various operational changes. This is a
merge-in of text equivalent to the existing Root Transfer Policy which
was documented on our wiki. (8)


Gerv