Yup. I'm curious for Apple's and Amazon's feedback, since they've been most active in bylaw discussions :)
We've got several paths to clear this up, hence my straw poll outlining options I could think of that would allow us to do so (trying to do so w/in 2 weeks - e.g. prior to the IP Review period expiring) On Tue, May 16, 2017 at 3:44 PM, Ben Wilson <[email protected]> wrote: > I think the end goal is to have a version 1.6.3 of the EV Guidelines with > the language indicated in the redlined version of Appendix F that I > circulated a short while ago. So I’d prefer that we find there was no > ambiguity and that Kirk start the review period over with the correct > language and we call that good, but of course the cleanest route would be > that Ballot 198 be declared defective because of ambiguity and a new ballot > be presented for a new vote. Fortunately this issue only affects the EV > Guidelines, which doesn’t have any ballots in play, as far as I know. > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Tuesday, May 16, 2017 12:39 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Cc:* Ben Wilson <[email protected]> > *Subject:* 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] 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]> 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]] *On Behalf Of *Kirk > Hall via Public > *Sent:* Monday, May 8, 2017 5:18 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Cc:* Kirk Hall <[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 [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] > https://cabforum.org/mailman/listinfo/public > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
