Wayne and all, We can discuss these issues at the next Governance WG meeting.
Best regards, Virginia Fournier Senior Standards Counsel Apple Inc. ☏ 669-227-9595 ✉︎ [email protected] <mailto:[email protected]> On Jan 19, 2018, at 3:54 PM, [email protected] wrote: Send Public mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://cabforum.org/mailman/listinfo/public or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Public digest..." Today's Topics: 1. Re: Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation (Wayne Thayer) 2. Re: [EXTERNAL] Verification of Domain Contact and Domain Authorization Document (Geoff Keating) ---------------------------------------------------------------------- Message: 1 Date: Fri, 19 Jan 2018 13:30:37 -0700 From: Wayne Thayer <[email protected]> To: Virginia Fournier <[email protected]>, "CA/Browser Forum Public Discussion List" <[email protected]> Subject: Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation Message-ID: <CAJE6Z6cn0RXHBZWDNNS=qkvr6pmdvxmx1-+xwypbxvq+v8u...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Fri, Jan 19, 2018 at 12:03 PM, Virginia Fournier via Public < [email protected]> wrote: > Yes, a Working Group can form its own subcommittees within itself. > I don't think this statement is obviously true. The current bylaws define these "subcommittees" (called Working Groups) - the new bylaws do not. So one reasonable interpretation is that they can no longer exist. For example, if we go to appoint a chair and create a mailing list for a new "subcommittee", what are the odds that someone will say "you can't do that - there is no such thing as a subcommittee and what you're really doing is creating a new WG without following the process?" Someone asked whether all of the WGs would be subgroups under the Server > Certificate WG - and that is clearly not the intent. > > The new bylaws imply that the existing WGs will become new WGs in section 5.3.4 - Legacy Working Groups. However some fundamental flaws have been pointed out with this structure in the case where the WG's purpose involves server certificates. To reiterate, if the Validation WG recharters under the new bylaws, it will no longer be able to take its work product back to the Server Certificate WG for review and approval. Also, please note that the *same* Bylaws and IPR policy apply to all WGs. > > The structure is *intended to be different* from what we have now. It > needs to be different because right now IP commitments apply to all of the > Forum?s activities. Under the new structure, IP commitments will only > apply to the WGs in which a member is participating - this necessarily > makes the structure more complex. > > Yes, the structure is intended to be different to address IP issues, but I suspect the assumption has been made that the existing "subcommittee" system can continue under the new structure without exploring all of the implications. Someone also commented that we can all ask multiple questions and make > additional changes during the discussion period. I?m at a complete loss as > to why questions haven?t already been asked and comments not already made. > As you are all aware, we?ve been working on and discussing all of these > documents *for well over a year*. Please *engage in the process now*, > read the documents, and ask questions and make comments now, rather than > holding up the voting period when we get there. > > I am asking for the Governance WG to explain what is going to happen with each existing WG before we adopt the new bylaws. Given the concerns that have been raised, I do not believe this is an unreasonable request. > > Best regards, > > Virginia Fournier > Senior Standards Counsel > ? Apple Inc. > ? 669-227-9595 <(669)%20227-9595> > ?? [email protected] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://cabforum.org/pipermail/public/attachments/20180119/1ea5bdea/attachment-0001.html> ------------------------------ Message: 2 Date: Fri, 19 Jan 2018 15:54:48 -0800 From: Geoff Keating <[email protected]> To: Kirk Hall <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" > On Jan 19, 2018, at 12:16 PM, Kirk Hall <[email protected]> wrote: > > Sorry for the misquotation ? I left off ?*** directly with the Domain Name > Registrar,? which is generally what we have been discussing ? a WhoIs lookup > to see who owns the domain. That wasn?t my objection?it was to the words ?by verifying that?. > But do you see my point that ?validating the Applicant as the Domain Contact? > (current language) could simply be confirming a hacker in both roles, but > would not be validating the Registrant information as to the organization > that owns the domain? > > Which would not be sufficient to include the Registrant Organization name in > the O field of an OV or EV cert. That?s why we made the change, which makes > Method 1 more secure in our opinion. Are some CAs validating by saying that, for example, someone has control of cabforum.org and so based only on that and the whois information they can be issued a certificate with O=Go Daddy? That would be unfortunate. As a side note, do you think it would be helpful to put something in the BRs to basically say ?you still have to validate everything in a certificate; if these BRs appear to allow a process which is not an effective validation, or some choices in your implementation of the process makes it ineffective, you must do whatever additional process is necessary to ensure an effective validation?? An overall ?don?t be stupid? rule. > Again, Method 1 was the original validation method starting in the 1990s, and > I think it?s proven its worth over the years. Processes often work great until someone works out how to abuse them, and then they don?t, sadly. > > From: [email protected] [mailto:[email protected]] > Sent: Friday, January 19, 2018 11:52 AM > To: Kirk Hall <[email protected]> > Cc: CA/Browser Forum Public Discussion List <[email protected]>; Mads Egil > Henriksveen <[email protected]> > Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain > Authorization Document > > > > > On Jan 19, 2018, at 11:23 AM, Kirk Hall <[email protected] > <mailto:[email protected]>> wrote: > > First, I think everyone knows what CAs are supposed to do under Method 1 > > I?m fairly sure this is not the case? > > > , and the lack of misissuance reports means CAs are doing it right. Here?s > how Method 1 starts now: > > ?Conforming the Applicant's control over the FQDN by validating the Applicant > as the Domain Contact by verifying that: ***? > > You can see why I think CAs might not know what they?re supposed to do, > because the above quote is not the actual words from the the Baseline > Requirements! Right now, in BR 1.5.4, Method 1 starts with these words: > > Confirming the Applicant's control over the FQDN by validating the Applicant > is the Domain Contact directly with the Domain Name Registrar. This method > may only be used if: > > Your version prescribes a method. The actual current requirements specify an > objective and don?t specify a method. > > Now, I?m not against prescribing a method, but the method prescribed does > need to achieve the original objective, and I think the proposed method is > inadequate to do that? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://cabforum.org/pipermail/public/attachments/20180119/3087e6c6/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public ------------------------------ End of Public Digest, Vol 69, Issue 89 **************************************
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
