[cabfpub] Re-draft Ballot for BR corrections

Peter Bowen pzb at amzn.com
Wed Apr 20 21:21:01 UTC 2016

I’ve been reminded that there is a standing request for more background on the rationale for ballots being proposed.

Last month there discussion on the public@ list on a ballot for updating membership requirements.  In that discussion Kirk Hall ask “can we combine with some of the other non-controversial BR changes that have been circulating (I can't remember what they are)in a 'miscellaneous' ballot?” Steven Davidson, Doug Beattie, and I all responded with some changes.  Dean then asked that the membership requirements ballot be limited to Bylaw changes, ending the discussion of BR changes for that ballot.

Based on Dean’s request to have a separate ballot for BR changes, I started a new thread about creating a BR ballot including all the items Steven, Doug, and I had suggested.  Moudrick Dadashov and Gervase Markham identified additional items for the ballot which included one item previously requested by Carl Mehner.  It also addresses an issue raised by Eneli Kirme back in January regarding whether SHA-256 signed OCSP responses violate the BRs.

After some discussion on the list, I removed several items from this ballot that were somewhat controversial to have them placed on their own ballots, including the wildcard definition.  As described below, I have also attempted to address the issue raised by Jeremy in the prior ballot version.

As this is technically a new ballot, it needs to be endorsed to move forward.  Can I get two endorsers?


> On Apr 19, 2016, at 8:52 PM, Peter Bowen <pzb at amzn.com> wrote:
> It appears that ballot 167 is going to fail due to lack of quorum presumably due to the concern of the BRs conflicting with RFC 5280 that Jeremy raised.
> I did a review the BRs, and found several cases where the BRs appear to allow things that may not be not allowed by RFCs 5280, 6818, 3279, 4055, 5480, 5756, or 5758:
> - The ‘*’ character is allowed in DNS names (to support wildcard certificates)
> - The Name Constraints extension is allowed to be non-critical
> - CA certificates can contain key purposes in the extended key usage extension that are used to constrain allowed key purposes in end-entity certificates
> (If anyone sees other places where there may be a conflict, please add to this list.)
> To resolve this, I made two changes to the ballot:
> 1) Added to the end of the section 7 modifications: “If there is a conflict between these Requirements and the aforementioned RFCs, these Requirements control.”
> - This should make it clear that this ballot is not changing the existing requirements.
> 2) In section, replace the text with “The cA field MUST NOT be true.”
> - This changes from “MUST be false”, which could be interpreted to mean the value must be explicitly encoded, to “MUST NOT be true”, which clearly includes the default false value as acceptable.
> I hope that this addresses the concerns.  Are there any other concerns or would anyone like to endorse this revised ballot?
> Thanks,
> Peter
> Ballot 168: Baseline Requirements Corrections (Revised)
> The following motion has been proposed by Peter Bowen of Amazon and endorsed by ___________________:
> Background:
> A number of small corrections and clarifications to the Baseline Requirements have been identified.  These are, in general, changes that reflect the existing understanding of the Baseline Requirements by the Forum.  Due to the understanding that these primarily represent existing practice, they are combined for efficiency.
> Effective the date of passage, the following modifications to the Baseline Requirements are adopted:
> In Section 1.6.1:
> - In the definition of "Applicant Representative", replace "and agrees to the Certificate Terms of Use" with "the Terms of Use" and append "or is the CA" at the end of the definition;
> - In the definition of "Country", replace "sovereign nation" with "Sovereign State";
> - In the definition of "Terms of Use", append "or is the CA" at the end of the definition;
> In Section 1.6.3:
> - Delete RFC2560;
> - Insert "RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013.";
> - Delete X.509v3;
> - Insert "X.509, Recommendation ITU-T X.509 (10/2012) | ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks." 
> Move the content in section 3.3.1 to section 4.2.1 to become the third paragraph in 4.2.1 and leave section 3.3.1 blank.
> In section 4.9.9, replace all occurrences of "RFC2560" with "RFC6960".
> In section 5.2.2, insert "CA" immediately before "Private Key".
> In section 6.1.2, append "without authorization by the Subscriber" to the end of the first sentence.
> In section 6.1.6, update the last citation to read: "[Source: Sections and, respectively, of NIST SP 56A: Revision 2]"
> In section 6.2, in the second sentence, insert "CA" immediately before both instances of "Private Key".
> In section 6.2.5, append "without authorization by the Subordinate CA" to the end of the sentence.
> In section 7, insert the following introduction paragraph:
> "All Certificates and Certificate Revocation Lists SHALL comply with RFC 5280 and RFC 6818.  They SHALL additionally comply with RFC3279, RFC4055, RFC5480, RFC5756, RFC5758 as appropriate based on the Subject Public Key Info and the Signature Algorithm present in the certificate. If there is a conflict between these Requirements and the aforementioned RFCs, these Requirements control."
> In sections and change the organizationName line to read:
> "-  organizationName (OID This field MUST be present and the contents MUST contain either the Subject CA’s name or DBA as verified under Section The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the CA MAY use “Company Name Inc.” or “Company Name”.”
> In section, replace the text with “The cA field MUST NOT be true."
> Replace "Subordiate" with "Subordinate" in the title of
> In section 9.6.1 item 6:
> - Insert "are the same entity or" immediately prior to "are Affiliated";
> - Remove "and accepted".
> In section 9.6.3, replace "agreement to the Terms of Use agreement." with "acknowledgement of the Terms of Use."
> In section 9.6.3 item 2, replace "maintain sole control" with "assure control".
> In the following sections, replace all occurrences of "Subscriber or Terms of Use Agreement" with "Subscriber Agreement or Terms of Use".
> - Section 1.6.1, in the definition of "Subscriber"
> - Section 4.1.2
> - Section
> - Section 4.9.11
> - Section 9.6.1
> - Section 9.6.3
> The review period for this ballot shall commence at 2200 UTC on __ April 2016, and will close at 2200 UTC on __ April 2016. Unless the motion is withdrawn during the review period, the voting period will start immediately thereafter and will close at 2200 UTC on _____ 2016. Votes must be cast by posting an on-list reply to this thread.
> A vote in favor of the motion must indicate a clear 'yes' in the response. A vote against 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/
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

More information about the Public mailing list