[cabfpub] Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub
kirk_hall at trendmicro.com
kirk_hall at trendmicro.com
Wed Nov 4 20:07:30 MST 2015
Ben, I have two questions/observations on these two Ballots:
(1) Is it wise to specify a particular app in a Ballot - here, GitHub? What if a better app comes along, or we decide GitHub isn't working? Will we have to propose and vote on another app, or cancelling this ballot?
We never had an earlier ballot saying that .doc or pdfs were the official canonical version for CABF documents - wasn't needed.
I am perfectly satisfied if you and others want to use GitHub as the official canonical version for CABF documents for the next several months so we can all see how this will work. But do you have to specify GitHub in your Ballot? Why not take that out so we don't ever have to vote to use another app instead?
(2) On putting all the other documents in RFC 3647 format - I'm not sure of the utility of that, and our vetting and security staff let out a collective groan when they heard about this proposal. They will have to change a lot of documents and check sheets if the numbering is changed, and they question the benefit.
But here's a specific question on how this is going to work. On authentication, RFC 3647 puts most everything in to Section 3.2, and in the BRs we already have a Sec. 3.2.1 through 3.2.6 for DV and OV authentication. How will you number (renumber) the EV Guidelines to an RFC 3647 format? Will you start at Sec. 3.2.7? But then you will never be able to add a Sec. 3.2.7 to the BRs, because it will be taken by the EVGL.
I have the same question about reformatting the numbers of the Network Security guidelines - will you have to renumber using new numbers not already used in the BRs? If so, why not just add them to the BRs?
Some people were enthusiastic about putting all these documents in the same RFC 3647 format on GitHub, and then they can munge all the documents together in a single grand standards / requirements document. But that won't work at all if the Section numbers overlap.
Finally, I'd notice that most of the EV Guidelines relate to VERY complicated vetting procedures, all of which will go into RFC 3647 Sec. 3.2. For example, in the current EVGL there is already a Section 11.2.2 (4)(A)(iii)1.a. What will this become in RFC 3647 format? New Section 22.214.171.124.2 (4)(A)(iii)1.a?? That's way too complicated, and where is the benefit?
What are your thoughts on these two questions?
From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Tuesday, November 03, 2015 11:46 AM
Subject: [cabfpub] Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub
Ballots 154 and 155 - Convert to RFC 3647 Framework and GitHub
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.
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 framework for the EV Guidelines and the Network and Certificate System Security Requirements and to post them on GitHub as the canonical versions of those documents.
Ben Wilson of DigiCert makes the following motions, and Dean Coclin from Symantec and Gerv Markham from Mozilla have endorsed them.
- - - - Motion for Ballot 154 - - - -
Be it resolved that the CA / Browser Forum directs the Certificate Policy Review Working Group to prepare a version of the EV Guidelines that moves existing content into the RFC 3647 format;
Be it further resolved that the CA / Browser Forum also directs the Certificate Policy Review Working Group to post the RFC-3647-formatted EV Guidelines on GitHub to serve, upon formal adoption by the Forum in a future ballot, as the canonical version of the EV Guidelines.
- - - - Motion Ends - - - -
- - - - Motion for Ballot 155 - - - -
Be it resolved that the CA / Browser Forum directs the Certificate Policy Review Working Group to prepare a version of the Network and Certificate System Security Requirements that moves existing content into the RFC 3647 format;
Be it further resolved that the CA / Browser Forum also directs the Certificate Policy Review Working Group to post the RFC-3647-formatted Network and Certificate System Security Requirements on GitHub to serve, upon formal adoption by the Forum in a future ballot, as the canonical version of the Network and Certificate System Security Requirements.
- - - - Motion Ends - - - -
The review period for these ballots shall commence at 2200 UTC on Tuesday, 3 November 2015 and will close at 2200 UTC on Tuesday, 10 November 2015. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on Tuesday, 17 November 2015.
Votes must be cast by posting an on-list reply to this thread. A vote in favor of each ballot must indicate a clear 'yes' in the response. A vote against each 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.
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public