In response to Jeremy’s post, the Governance Reform WG could re-examine sections 2.2 and 2.3 of the Bylaws and make suggested improvements as the WG works on other sections of the Bylaws. The goal would be to write clearer rules on how ballots are to be submitted, interpreted, and incorporated into guidelines.
In response to Ryan’s comments below, I would like to emphasize the importance of the redlined version—it is by looking at how proposed edits to the official text (in between motion begins and motion ends), will be incorporated into the document that the ballot proposer (and we, who should all be reviewing the redline) can spot any inconsistencies. These inconsistencies happen too often, and we should be looking at ways to minimize their occurrence. (Also, if you have a ballot, there are currently two ways to create a redlined version—Github and Word versions on the wiki.) From: Public [mailto:[email protected]] On Behalf Of Ryan Sleevi via Public Sent: Tuesday, May 16, 2017 2:00 PM To: Kirk Hall <[email protected]> Cc: Ryan Sleevi <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] [EXTERNAL]Re: Revised Notice of Review Period - Ballot 198 - .Onion Revisions Right, to be clear, I was not suggesting you made a mistake. You did everything by the book :) Rather, your Review Notice included the balloted text (motion begins/motion ends), but not the redline. In Jeremy's "ballot-thing" (for I don't know what we want to term it), there was the text you included - and the redline. This is one of those ambiguities in the Bylaws and IP Policy that I was trying to call out. Is the Ballot (e.g. the thing called Ballot in the Bylaws) https://cabforum.org/pipermail/public/2017-April/010706.html ? If so, then the Ballot is 'both' the text you included, and the redlines. In Jeremy's case, the two were in conflict - the redline presented something different than the motion text. The Bylaws describe a Ballot as including a redline/comparison (which Jeremy did), but it's different than what the motion begins/ends text says. I can't seem to find any requirements on the form of Review Notice, but it sounds like we're in agreement that, regardless of what the Review Notice states, what it applies to is "the Ballot". If we agree the Ballot is the motion begins/ends text (e.g. what you've published in the Review Notice, and what was voted on), then that's what it applies to. If we agree the Ballot is on the redline text (e.g. what Ben shared), then the Review Notice and the Ballot are different, but the Ballot still supercedes the Review Notice. On Tue, May 16, 2017 at 3:43 PM, Kirk Hall <[email protected] <mailto:[email protected]> > wrote: I have not followed all the details of this discussion, but I will offer my opinion on one point: any errors in the Review Notice do not affect the ballot or results of voting on the ballot. For this ballot, if I included the wrong text in the Review Notice, can Jeremy please send me the correct text and I will circulate a corrected Review Notice and start the voting over again. I typically look for the original ballot on the list from the proposer that started the process (plus any revisions that occurred during the discussion period), and put that in the Review Notice after a successful vote. I’m not sure if that caused a mistake here. From: Public [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Ryan Sleevi via Public Sent: Tuesday, May 16, 2017 11:39 AM To: CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Cc: Ryan Sleevi <[email protected] <mailto:[email protected]> > Subject: [EXTERNAL]Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions As Ben has highlighted, the result of 198 created a new set of issues. Kirk's original message includes the full text of the ballot (MOTION BEGINS), which, unfortunately, used text different from what was adopted in Ballot 144 (and part of the current EVGs) when Jeremy made his modifications. In examining 198 - https://cabforum.org/pipermail/public/2017-April/010706.html - it's clear in Jeremy's redlined versions (which, mistakenly, I reviewed as truth), the 'intent' was a small change. See https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf However, as Balloted, it requires a full replacement of the text adopted in 144, in a way that's structurally incompatible with the ASN.1 encoding. Worse, this is something that was discussed during the voting reform discussions - both situations where redlines and text differ (as in this case) and questions about redlining as 'source of truth'. We tried to address it as best as possible, but also somewhat punted the issue as unlikely :) I think it's worth highlighting this concern broadly, because we have several possible interpretations: 1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has distributed) - In this case, we've now introduced a bug into the processing that is not easily undone. - Supporting Argument: This is how we've always done things. - Solution Suggestion: Hold a ballot immediately to try to fix this before the end of the IP review. - Approach 1: Nullify the ballot? That is, to keep the version of the BRs the same. - Approach 2: Direct the Chair not to publish any new versions of the BRs (thus triggering compliance for CAs) until the matter is resolved - Approach 3: Introduce a new ballot with a new OID for the service descriptor that restores the 144 text - Implications: - If folks don't vote on this, we're stuck in a bad place (effectively, no one should issue EV onion certs, because they'd post a compat/interop risk) 2) The redline text is authoritative (e.g. as Ben has distributed) - In this case, we're saying that the PDFs, not the ballot text, are what is authoritative. - This means you can no longer read ballots on our website "as is", but must ALSO view/post the supporting materials - Supporting Argument: The Bylaws seem to support this with respect to Section 2.3(a). - Solution Suggestion: Hold a ballot to agree on this interpretation for this specific ballot - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws clarify this for future ballots - Implications: - We should figure out what this means for future ballots if we go this route. - It also means our ballot postings to the website are probably incomplete 3) The ballot is invalid (due to the inconsistency) - In this case, we're saying the ballot is null because of the mismatch - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft Guideline Ballot proposing a Final Maintenance Guideline will include a redline or comparison, and that such redline or comparison be made against the Final Guideline section(s) as they exist at the time the ballot is proposed. Jeremy's redline was not against that section, ergo, was not a valid ballot. - Solution Suggestion: Hold a ballot to agree on this interpretation for this specific ballot - Solution Suggestion p2: Adopt it fixed In short, I think we should probably resolve this with a ballot - which can be completed in two weeks. The IP Review Notice has been triggered, but its unclear as to whether Review Notices need to also include the Ballot text itself (e.g. the Ballot is, presumably, what was posted to [email protected] <mailto:[email protected]> and voted on - which included the redline changes). That is, it's unclear whether the text Kirk included in the Review Notice - which is different than the ballot (since it omits the redlines) - supersedes/replaces the Ballot itself. Does this capture every possible interpretation? Are the others? On Tue, May 16, 2017 at 1:00 PM, Ben Wilson via Public <[email protected] <mailto:[email protected]> > wrote: All, Attached is the redlined version of Appendix F of the EV Guidelines (v.1.6.3) based on the language of the ballot. There was a discrepancy between the earlier PDF attachment to the ballot and the text in email that announced the ballot. It appears that the PDF was based on an old, out-of-date version of Appendix F . In the attached redlined version I have tried to preserve the intent of Ballot 198. I will be posting version 1.6.3 of the EV Guidelines to the CA/Browser Forum website shortly. All versions (PDF/Word/redlined/w-o redlining) will be uploaded to here https://cabforum.org/wiki/EV on the wiki as well. Yours truly, Ben Wilson From: Public [mailto:[email protected] <mailto:[email protected]> ] On Behalf Of Kirk Hall via Public Sent: Monday, May 8, 2017 5:18 PM To: CA/Browser Forum Public Discussion List <[email protected] <mailto:[email protected]> > Cc: Kirk Hall <[email protected] <mailto:[email protected]> > Subject: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions Sorry, got end date wrong before. End date in June 8 at 01:00 UTC. NOTICE OF REVIEW PERIOD – BALLOT 198 This Review Notice is sent pursuant to Section 4.1 of the CA/Browser Forum’s Intellectual Property Rights Policy (v1.2). This Review Period is for Final Maintenance Guidelines (30 day Review Period). A complete draft of the Draft Guideline that is the subject of this Review Notice is attached. Date Review Notice Sent: May 8, 2017 Ballot for Review: Ballot 198 - .Onion Revisions Start of Review Period: May 9, 2017 at 01:00 UTC End of Review Period: June 8, 2017 at 01:00 UTC Please forward any Exclusion Notice relating to Essential Claims to the Chair by email to <mailto:[email protected]> [email protected] before the end of the Review Period. See current version of CA/Browser Forum Intellectual Property Rights Policy for details. (Optional form of Exclusion Notice is attached) Ballot 198 - .Onion Revisions -- MOTION BEGINS – Revise Appendix F, Section 1 to read as follows: Appendix F – Issuance of Certificates for .onion Domain Names A CA may issue an EV Certificate containing the .onion Domain Name provided that issuance complies with the requirements set forth in this Appendix: 1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) The CAB Forum extension in of the TBSCertificate to convey hashes of keys related to .onion addresses. The CA MUST include the Tor Service Descriptor Hash extension using the following format: cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 } TorServiceDescriptorHash:: = SEQUENCE { algorithm AlgorithmIdentifier subjectPublicKeyHash BIT STRING } Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234) performed over the raw Public Key of the .onion service and SubjectPublicKeyHash is the value of the hash output of the raw Public Key. --Motion Ends-- _______________________________________________ Public mailing list [email protected] <mailto:[email protected]> https://cabforum.org/mailman/listinfo/public
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
