[cabfpub] Pre-Ballot 206 - Amendment to IPR Policy & Bylaws re Working Group Formation

Virginia Fournier vfournier at apple.com
Mon Jan 22 18:20:49 UTC 2018


Gerv - what do you mean by “new IPR signatures”?  Thanks.

Message: 1
Date: Mon, 22 Jan 2018 09:42:20 +0000
From: Gervase Markham <gerv at mozilla.org>
To: Wayne Thayer <wthayer at mozilla.com>, CA/Browser Forum Public
	Discussion List <public at cabforum.org>, Virginia Fournier
	<vfournier at apple.com>
Subject: Re: [cabfpub] Pre-Ballot 206 - Amendment to IPR Policy &
	Bylaws re Working Group Formation
Message-ID: <144e40cc-47ee-e3b9-a636-1e898106ec2c at mozilla.org>
Content-Type: text/plain; charset=utf-8

On 19/01/18 20:30, Wayne Thayer via Public wrote:
> 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?"

Well, you aren't creating a new WG because that would require a charter
and new IPR signatures and so on. If something is under the aegis of an
existing WG, that WG's charter and IPR signatures would continue to
apply, and only members of the WG could be involved in the
sub-committee. Meetings of such a group would be treated as meetings of
the whole insofar as minutes etc. were concerned, and anyone could
"join" or "leave" at any time.

I see sub-committees as like 4 people going off into a separate room for
half an hour at a face-to-face to hash out the technical details of a
particularly thorny problem, then coming back and presenting a proposal
to the group.

I can see how it might be useful to have this possibility at least
mentioned in the bylaws, for the avoidance of doubt, but I don't think
it's totally necessary.

> 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.

Yes. We definitely don't want multiple WGs covering server certificates.
The existing WGs in that category need to either go away, or become
subcommittees of the Server Certificate WG.

Gerv


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

Message: 2
Date: Mon, 22 Jan 2018 10:17:39 -0600
From: "Rich Smith" <richard.smith at comodo.com>
To: "'Mads Egil Henriksveen'" <Mads.Henriksveen at buypass.no>,
	"'CA/Browser Forum Public Discussion List'" <public at cabforum.org>,
	"'Gervase Markham'" <gerv at mozilla.org>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and
	Domain	Authorization Document
Message-ID: <02b801d3939c$87554510$95ffcf30$@comodo.com>
Content-Type: text/plain;	charset="us-ascii"

My position is that you can't verify domain ownership because the registrars
by and large do absolutely nothing to verify the information input by the
registrants.  What are you actually verifying?  As such technical
demonstration of domain control is the best we've got.  I liken it to the
old sysadmin adage, if I've got physical access to the box I own the box.
Likewise if I've got technical control of the domain I own the domain.

Regards,
Rich

-----Original Message-----
From: Mads Egil Henriksveen [mailto:Mads.Henriksveen at buypass.no] 
Sent: Saturday, January 20, 2018 6:49 AM
To: Rich Smith <richard.smith at comodo.com>; 'CA/Browser Forum Public
Discussion List' <public at cabforum.org>; 'Gervase Markham' <gerv at mozilla.org>
Subject: RE: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

Hi Rich

I understand your concern and position. 

I don't think the proposed new text for 3.2.2.4.1 by itself adds any new
assumption, but the overall process for issuing OV/EV certificates might be
subject to this. In your example the link between company A (the one you
register) and company B (the target) could be established by social
engineering independent of the proposed text. I could argue that the CA
should treat Company A as the Applicant and not Company B. In that case the
method cannot be used. If the CA treat Company B as the Applicant, then it
should be difficult to get the authenticity of the certificate request
established. 

In my opinion, your last statement summarizes what the discussion really is
about. Should we allow issuance of an SSL certificate based on domain
ownership by the Applicant at all or should this only be allowed based on
some technical demonstration of domain control? I think this is the core
issue. 

Regards
Mads

-----Original Message-----
From: Rich Smith [mailto:richard.smith at comodo.com]
Sent: fredag 19. januar 2018 20:37
To: Mads Egil Henriksveen <Mads.Henriksveen at buypass.no>; 'CA/Browser Forum
Public Discussion List' <public at cabforum.org>; 'Gervase Markham'
<gerv at mozilla.org>
Subject: RE: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

Mads,
I appreciate you trying to save this method, but IMO there is nothing that
can be done to strengthen this method enough to protect it against social
engineering.  Your proposal relies on the assumption that EVERY validation
agent of EVERY CA MUST have at least the same level of understanding of
corporate structures as the people in this Forum.  It's an unrealistic
assumption.  All I have to do is register a company called Google, Inc., in
SOME jurisdiction, get listed in SOME QIIS, then just convince a validation
agent from ANY CA that I am a local branch office of the real Google, Inc.
that we all know and love and bam, I've got a cert for google.com.

I picked Google because they are an easy example.  In reality I suspect
(hope) that no CA would fall for this particular example, but a less known
company?  Almost certainly.

Through the discussion I've been convinced that we should leave some version
of 3.2.2.4.1 (3) in place, but I don't think you'll ever convince me that
the other bits of 3.2.2.4.1 or 3.2.2.4.5 are, or ever can be made to be, as
secure as the weakest technical demonstration of domain control.

Regards,
Rich

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Mads Egil
Henriksveen via Public
Sent: Friday, January 19, 2018 6:59 AM
To: Gervase Markham <gerv at mozilla.org>; CA/Browser Forum Public Discussion
List <public at cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

Hi Gerv

The current version 3.2.2.4.1 says:
----
3.2.2.4.1 Validating the Applicant as a Domain Contact 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:
1. The CA authenticates the Applicant's identity under BR Section 3.2.2.1
and the authority of the Applicant Representative under BR Section 3.2.5, OR
2. The CA authenticates the Applicant's identity under EV Guidelines Section
11.2 and the agency of the Certificate Approver under EV Guidelines Section
11.8; OR 3. The CA is also the Domain Name Registrar, or an Affiliate of the
Registrar, of the Base Domain Name.

Note: Once the FQDN has been validated using this method, the CA MAY also
issue Certificates for other FQDNs that end with all the labels of the
validated FQDN. This method is suitable for validating Wildcard Domain
Names.
-----

Our proposal concentrates on the first part, i.e. the following statement: 
>> Confirming the Applicant's control over the FQDN by validating the
Applicant is the Domain Contact directly with the Domain Name Registrar.

Is to be replaced with:
<< Conforming the Applicant's control over the FQDN by validating the
Applicant as the Domain Name Registrant by verifying that: 
<< 1.	The name of the Domain Name Registrant matches the Applicant's name
AND
<< 2.	Additional information about the Domain Name Registrant in the WHOIS
meet the following requirements:
<<          i.	The Registrant's postal address in the WHOIS belongs to the
Applicant. CAs MUST verify this by matching it with one of the Applicant's
addresses in: (a) a QGIS, QTIS, or QIIS; or (b) a Verified Professional
Letter. 
<<                         Note: Address details in the WHOIS are required
to use this option. Address details must include at a minimum the Country
and either Locality, State or Province. OR 
<<          ii.	The WHOIS contains the Registration (or similar) Number
assigned to the Applicant by the Incorporating or Registration Agency in its
Jurisdiction of Incorporation or Registration as appropriate. CAs MUST
verify this by matching the Registration Number in the WHOIS with the
Applicant's Registration Number in a QGIS or a QTIS.

The first change is the use of Domain Name Registrant instead of Domain
Contact, i.e. the focus is on domain ownership. 

The proposal requires that the name of the Registrant (in WHOIS) matches 1)
the name of the Applicant AND either 2 i) the postal address of the
Registrant (in WHOIS) matches the postal address of the Applicant (in
sources accepted for EV validation) OR 2 ii) a Registration Number for the
Registrant (in WHOIS) matches the Registration Number of the Applicant (in a
QGIS or QTIS).

The proposal addresses threats due to that organization names are not
unique, the combination of organization name and address or organization
name and registration number should be unique. It also removes ambiguities
the current language permits (according to Jeremy - see attachment). 

Regards
Mads 

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: fredag 19. januar 2018 10:29
To: Mads Egil Henriksveen via Public <public at cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain
Authorization Document

On 19/01/18 06:51, Mads Egil Henriksveen via Public wrote:
> Buypass, Entrust Datacard and GlobalSign have been working on some 
> text to strengthen 3.2.2.4.1 instead of removing it - find the draft 
> text below. The draft was discussed in the Validation Working Group 
> meeting yesterday. We would like to offer this as an amendment to 
> Ballot
218.

Is it possible to provide a diff, e.g. by turning the new text into a Github
pull request, or some other mechanism?

Once we have a diff, might it be possible for rationale to be provided for
each change?

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public



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

Message: 3
Date: Mon, 22 Jan 2018 18:05:53 +0000
From: Bruce Morton <Bruce.Morton at entrustdatacard.com>
To: Geoff Keating <geoffk at apple.com>, CA/Browser Forum Public
	Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and
	Domain Authorization Document
Message-ID:
	<4dc0f281f6064ac18dea64bbfe63dd14 at PMSPEX04.corporate.datacard.com>
Content-Type: text/plain; charset="utf-8"

Geoff,

We put together an example of using method 1. Please see attached.

Bruce.

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Geoff Keating via Public
Sent: January 19, 2018 6:55 PM
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




On Jan 19, 2018, at 12:16 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto: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<http://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> [mailto:geoffk at apple.com]
Sent: Friday, January 19, 2018 11:52 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>; Mads Egil Henriksveen <Mads.Henriksveen at buypass.no<mailto: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/20180122/d442a14c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Example of domain validation using Method 1.pdf
Type: application/pdf
Size: 276446 bytes
Desc: Example of domain validation using Method 1.pdf
URL: <http://cabforum.org/pipermail/public/attachments/20180122/d442a14c/attachment.pdf>

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

Subject: Digest Footer

_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public


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

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




More information about the Public mailing list