[cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions
Ryan Sleevi
sleevi at google.com
Tue May 16 20:15:06 UTC 2017
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 <ben.wilson at digicert.com> 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:sleevi at google.com]
> *Sent:* Tuesday, May 16, 2017 12:39 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Ben Wilson <ben.wilson at digicert.com>
> *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
> public at cabforum.org 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 <
> public at cabforum.org> 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:public-bounces at cabforum.org] *On Behalf Of *Kirk
> Hall via Public
> *Sent:* Monday, May 8, 2017 5:18 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Kirk Hall <Kirk.Hall at entrustdatacard.com>
> *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 kirk.hall at entrustdatacard.com 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
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170516/90abd899/attachment-0003.html>
More information about the Public
mailing list