[cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

[Ben Wilson]

Here is another version of Ballot 146 based on discussions we had today during the Certificate Policy Review Working Group meeting.  This version removes the incorporation of the Network and Certificate System Requirements, which some members felt was too much to handle with this ballot.  I have retained the original endorsers, contingent on their continued support of the ballot and revised document.  

Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

The Certificate Policy Review Working Group was chartered by Ballot 128 to (i) consider existing and proposed standards, (ii) create a list of potential improvements based on the considered standards that improve the existing CAB Forum work product, (iii) evaluate the transition to a 3647 format based on the amount [of work involved].  One deliverable of the CP Review WG was to propose a ballot to improve CA infrastructure based on existing standards and documents and recommend whether to finish the 3647 conversion presented by Jeremy Rowley in January 2014.

The CP Review WG has met and concluded that the best path forward for the Forum is to complete a conversion to the RFC 3647 for the Baseline Requirements with an initial step that moves existing content from the Baseline Requirements into the RFC 3647 format.

Attached is an RFC-3647-formatted Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates. 

Ben Wilson of DigiCert made the following motion, Tim Hollebeek from Trustwave and Jody Cloutier from Microsoft have endorsed it.

Motion Begins

Be it resolved that the CA / Browser Forum adopts the attached CA/B Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, effective upon adoption.

Motion Ends

The review period for this ballot shall commence at 2200 UTC on   March 2015 and will close at 2200 UTC on   March 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on   March 2015.

Votes must be cast by posting an on-list reply to this thread. A vote in favor of the ballot must indicate a clear ‘yes’ in the response. A vote against the ballot must indicate a clear ‘no’ in the response. A vote to abstain must indicate a clear ‘abstain’ in the response. Unclear responses will not be counted. The latest vote received from any representative of a voting member before the close of the voting period will be counted.

Voting members are listed here: https://cabforum.org/members/. In order for the motion to be adopted, two thirds or more of the votes cast by members in the CA category and more than one half of the votes cast by members in the browser category must be in favor. Quorum is currently nine (9) members– at least nine members must participate in the ballot, either by voting in favor, voting against, or by abstaining for the vote to be valid.

-----Original Message-----
From: Dean Coclin [mailto:Dean_Coclin at symantec.com] 
Sent: Thursday, March 5, 2015 11:44 AM
To: Gervase Markham; kirk_hall at trendmicro.com; Ben Wilson; CABFPub
Subject: RE: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

While it may be true that she would have a one-time task to update the policy and wiki pages, the long term benefit is to relying parties, auditors and perhaps other root program owners that need to compare BRs to CPs and CPS documents.  But thanks for clarifying Mozilla's position.


-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org] 
Sent: Wednesday, March 04, 2015 11:13 AM
To: Dean Coclin; kirk_hall at trendmicro.com; Ben Wilson; CABFPub
Subject: Re: [cabfpub] Pre-Ballot 146 - Convert Baseline Requirements to RFC 3647 Framework

On 24/02/15 16:59, Dean Coclin wrote:
> Some of the beneficiaries are Browser root programs and relying parties.
> Having the BRs in this format makes it easier for Jody, Kathleen and 
> others to review CPS’ and compare to the sections in the BRs for 
> compliance.

I checked with Kathleen about this; she said:

"This is not something I asked for. I suspect that whoever asked for it thought that it would be nice for the BRs to line up with the way most CP/CPS documents are organized. But, it doesn't really matter to me.

If they change the ordering and the section numbering of the BRs, then I will have to update Mozilla's CA Certificate Policy and a bunch of wiki pages. So, it would be extra busy work for me."

So Mozilla is not against this change if other stakeholders see strong value in it, but we are not requesting it for ourselves.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CAB Forum BR 1.2.5-Ballot146.doc
Type: application/msword
Size: 506368 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150311/d6414bc5/attachment-0003.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150311/d6414bc5/attachment-0001.p7s>