[cabfpub] Public Digest, Vol 69, Issue 89

Sat Jan 20 00:19:14 UTC 2018

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
✉︎ vmf at apple.com <mailto:vmf at apple.com>

On Jan 19, 2018, at 3:54 PM, public-request at cabforum.org wrote:

Send Public mailing list submissions to
	public at cabforum.org

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
	public-request at cabforum.org

You can reach the person managing the list at
	public-owner at cabforum.org

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 <wthayer at mozilla.com>
To: Virginia Fournier <vfournier at apple.com>,  "CA/Browser Forum Public
	Discussion List" <public at cabforum.org>
Subject: Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy &
	Bylaws re Working Group Formation
Message-ID:
	<CAJE6Z6cn0RXHBZWDNNS=Qkvr6PmDvXMx1-+XwyPBxVq+V8uLJw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Fri, Jan 19, 2018 at 12:03 PM, Virginia Fournier via Public <
public at cabforum.org> 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>
> ?? vmf at apple.com
> 
> 
-------------- 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 <geoffk at apple.com>
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and
	Domain Authorization Document
Message-ID: <280AFA6E-CAB1-4673-8318-4FFBB733AF2D at apple.com>
Content-Type: text/plain; charset="utf-8"

> On Jan 19, 2018, at 12:16 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com> 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: geoffk at apple.com [mailto:geoffk at apple.com] 
> Sent: Friday, January 19, 2018 11:52 AM
> To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
> Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Mads Egil Henriksveen <Mads.Henriksveen at buypass.no>
> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document
> 
> 
> 
> 
> On Jan 19, 2018, at 11:23 AM, Kirk Hall <Kirk.Hall at entrustdatacard.com <mailto:Kirk.Hall at entrustdatacard.com>> 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
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

------------------------------

End of Public Digest, Vol 69, Issue 89
**************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180119/0b78db99/attachment-0002.html>