Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

This does not resolve the issues mentioned.

On Thu, Jan 4, 2018 at 7:47 AM, Mads Egil Henriksveen via Public <
public@cabforum.org> wrote:

> Removing method  1 is not the only way to solve this ambiguity, it could
> also be solved by changing the language of 3.2.2.4.1 into something like
> this (changes are redlined in attached document):
>
>
>
> *3.2.2.4.1 Validating the Applicant as a Domain Name Registrant*
>
> Confirming the Applicant's control over the FQDN by validating the
> Applicant is the Domain Name Registrant. 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
> The Applicant identity and address must match the Domain Name Registrant.
>
> 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
> The Applicant must be the same legal entity as the Domain Name Registrant
>
>
>
> 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.
>
>
>
> This would also allow for using method 1 for the use cases I have
> identified.
>
>
>
> Regards
>
> Mads
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Jeremy
> Rowley via Public
> *Sent:* onsdag 3. januar 2018 23:25
> *To:* geo...@apple.com
> *Cc:* CA/Browser Forum Public Discussion List 
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
> The ambiguity is exactly why we need to remove method 1. I’ve seen all of
> the following:
>
> 1)  Approval based on a name match
>
> 2)  Approval based on an email match (same email as requester or the
> email is a corporate email) – note that this is a Domain Contact match
>
> 3)  Approval based on address and name match
>
> 4)  Approval based on a letter from the registrar
>
> 5)  Approval based on a call to the registrar
>
> 6)  Approval based on a validation email to the registrar
>
>
>
> All of these are equally permitted by the language, IMO, because “by
> validating the Applicant has the same name as the Domain Contact
> directly with the Domain Name Registrar” can mean a LOT of things.
>
>
>
> *From:* geo...@apple.com [mailto:geo...@apple.com ]
> *Sent:* Wednesday, January 3, 2018 2:54 PM
> *To:* Jeremy Rowley 
> *Cc:* CA/Browser Forum Public Discussion List ; Ryan
> Sleevi ; Adriano Santoni  it>
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
> It looks like we’re going to be removing 3.2.2.4.1, so this will be moot,
> but just to explain the interpretation, 3.2.2.4.1 says that what you are
> doing (this sentence is the entire description of the method, the rest of
> the section just limits its application) is "Confirming the Applicant's
> control over the FQDN by validating the Applicant is the Domain Contact
> directly with the Domain Name Registrar.”
>
>
>
> This is not a name match.  If the BRs wanted to say “by validating the
> Applicant has the same name as the Domain Contact”, they would say so.
> This is a one-and-the-same match, it uses the word “is”.  In the example
> below, the CA must ensure that “Google Inc., the Utah corporation” is the
> same one as shown in the WHOIS information, and all the WHOIS information
> is relevant in confirming this.
>
>
>
> Another important clarification is that if you use 3.2.2.1, it doesn’t
> just verify “the name of the applicant”; it says that "the CA SHALL
> verify the identity and address of the organization”, not just the name.
>  (Um… actually, if you read it closely, you might not verify the name at
> all, if you identify the organization in another way, maybe with some kind
> of ID number.  That’s probably a bug.)
>
>
>
> On 2 Jan 2018, at 8:47 pm, Jeremy Rowley 
> wrote:
>
>
>
> I disagree. The requirements do not specify that.  All that is required is
> the name of the applicant was verified under 3.2.2.1 and that the register
> specify the domain contact is the applicant. If Google, Inc. is specified
> as the domain contact, no address matching is required.
>
>
>
> *From:* geo...@apple.com [mailto:geo...@apple.com ]
> *Sent:* Tuesday, January 2, 2018 4:34 PM
> *To:* Jeremy Rowley ; CA/Browser Forum Public
> Discussion List 
> *Cc:* Ryan Sleevi ; Adria

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Mads Egil Henriksveen via Public]

Removing method  1 is not the only way to solve this ambiguity, it could also 
be solved by changing the language of 3.2.2.4.1 into something like this 
(changes are redlined in attached document):

3.2.2.4.1 Validating the Applicant as a Domain Name Registrant
Confirming the Applicant's control over the FQDN by validating the Applicant is 
the Domain Name Registrant. 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
The Applicant identity and address must match the Domain Name Registrant.
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
The Applicant must be the same legal entity as the Domain Name Registrant

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.

This would also allow for using method 1 for the use cases I have identified.

Regards
Mads

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 23:25
To: geo...@apple.com
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

The ambiguity is exactly why we need to remove method 1. I’ve seen all of the 
following:
1)  Approval based on a name match
2)  Approval based on an email match (same email as requester or the email 
is a corporate email) – note that this is a Domain Contact match
3)  Approval based on address and name match
4)  Approval based on a letter from the registrar
5)  Approval based on a call to the registrar
6)  Approval based on a validation email to the registrar

All of these are equally permitted by the language, IMO, because “by validating 
the Applicant has the same name as the Domain Contact directly with the Domain 
Name Registrar” can mean a LOT of things.

From: geo...@apple.com<mailto:geo...@apple.com> [mailto:geo...@apple.com]
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>
Cc: CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org>>; Ryan Sleevi 
mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but 
just to explain the interpretation, 3.2.2.4.1 says that what you are doing 
(this sentence is the entire description of the method, the rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

On 2 Jan 2018, at 8:47 pm, Jeremy Rowley 
mailto:jeremy.row...@digicert.com>> wrote:

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

From: geo...@apple.com<mailto:geo...@apple.com> [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>; CA/Browser 
Forum Public Discussion List mailto:public@cabforum.org>>
Cc: Ryan Sleevi mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document




On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public 
mailto:public@cabforum.org>> wrote:

The attack vector is easier than that.

  1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
  2.  I verify that Jeremy did indeed incorporate

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Jeremy Rowley via Public]

The ambiguity is exactly why we need to remove method 1. I’ve seen all of the 
following:

1.  Approval based on a name match
2.  Approval based on an email match (same email as requester or the email 
is a corporate email) – note that this is a Domain Contact match
3.  Approval based on address and name match
4.  Approval based on a letter from the registrar
5.  Approval based on a call to the registrar
6.  Approval based on a validation email to the registrar

 

All of these are equally permitted by the language, IMO, because “by validating 
the Applicant has the same name as the Domain Contact directly with the Domain 
Name Registrar” can mean a LOT of things.

 

From: geo...@apple.com [mailto:geo...@apple.com] 
Sent: Wednesday, January 3, 2018 2:54 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List ; Ryan Sleevi 
; Adriano Santoni 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but 
just to explain the interpretation, 3.2.2.4.1 says that what you are doing 
(this sentence is the entire description of the method, the rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

 

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

 

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

 

On 2 Jan 2018, at 8:47 pm, Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

 

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

 

From: geo...@apple.com <mailto:geo...@apple.com>  [mailto:geo...@apple.com] 
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org> >
Cc: Ryan Sleevi mailto:sle...@google.com> >; Adriano 
Santoni mailto:adriano.sant...@staff.aruba.it> 
>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 






On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public < 
<mailto:public@cabforum.org> public@cabforum.org> wrote:

 

The attack vector is easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning  
<http://google.com/> google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

 

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

It looks like we’re going to be removing 3.2.2.4.1, so this will be moot, but 
just to explain the interpretation, 3.2.2.4.1 says that what you are doing 
(this sentence is the entire description of the method, the rest of the section 
just limits its application) is "Confirming the Applicant's control over the 
FQDN by validating the Applicant is the Domain Contact directly with the Domain 
Name Registrar.”

This is not a name match.  If the BRs wanted to say “by validating the 
Applicant has the same name as the Domain Contact”, they would say so.  This is 
a one-and-the-same match, it uses the word “is”.  In the example below, the CA 
must ensure that “Google Inc., the Utah corporation” is the same one as shown 
in the WHOIS information, and all the WHOIS information is relevant in 
confirming this.

Another important clarification is that if you use 3.2.2.1, it doesn’t just 
verify “the name of the applicant”; it says that "the CA SHALL verify the 
identity and address of the organization”, not just the name.  (Um… actually, 
if you read it closely, you might not verify the name at all, if you identify 
the organization in another way, maybe with some kind of ID number.  That’s 
probably a bug.)

> On 2 Jan 2018, at 8:47 pm, Jeremy Rowley  wrote:
> 
> I disagree. The requirements do not specify that.  All that is required is 
> the name of the applicant was verified under 3.2.2.1 and that the register 
> specify the domain contact is the applicant. If Google, Inc. is specified as 
> the domain contact, no address matching is required.
>   <>
> From: geo...@apple.com [mailto:geo...@apple.com] 
> Sent: Tuesday, January 2, 2018 4:34 PM
> To: Jeremy Rowley ; CA/Browser Forum Public 
> Discussion List 
> Cc: Ryan Sleevi ; Adriano Santoni 
> 
> Subject: Re: [cabfpub] Verification of Domain Contact and Domain 
> Authorization Document
>  
>  
> 
> 
> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public  <mailto:public@cabforum.org>> wrote:
>  
> The attack vector is easier than that. 
> I use very stringent processes to verify that Google, Inc. is a legit company 
> in Utah.
> I verify that Jeremy did indeed incorporate Google, Inc. 
> I call Jeremy at the phone listed for Google, Inc., the Utah corporation
> The domain information shows Google, Inc. as owning google.com 
> <http://google.com/>
> Certificate issues.
>  
> Obviously this would be caught in every CA’s high risk checks, but the point 
> remains valid. Regardless of the expertise and thoroughness of the org check, 
> the specs lack any time between the verified org and the actual domain 
> because orgs are not unique on a global basis.
>  
>  
> For item 4, you have to verify that “the Applicant is the Domain Contact”.  
> Obviously it’s insufficient to just compare names—you must verify every 
> element of the WHOIS contact matches the Applicant, that’s typically name, 
> postal address, phone number, and e-mail.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Rich Smith via Public]

Notwithstanding potential discussions to revamp this method, I stand by removal 
at this time as it is currently dreadfully insecure and nowhere near equivalent 
to the other methods.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Doug Beattie via 
Public
Sent: Wednesday, January 3, 2018 2:30 PM
To: Ryan Sleevi ; CA/Browser Forum Public Discussion List 
; Kirk Hall 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

I think this is exactly the type of change that the validation working group 
should hash out and then propose a solution to the public list.  I’m actually 
surprised that Tim sent this out given this was on our agenda for tomorrow and 
he informally polled a number of us on the use of method 1.

 

I believe that with some additional checks, we can make method 1 sufficiently 
secure.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 3:17 PM
To: Kirk Hall mailto:kirk.h...@entrustdatacard.com> >; CA/Browser Forum Public Discussion 
List mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

Given the impact of this, while I don't suggest that the VWG shouldn't take 
this up, I also don't think that should be reason not to continue the 
discussion on the public list.

 

While I understand that Mads and Adriano have suggested they see value in 
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration that 
it remotely approaches the level of assurance of the other methods, or that it 
fundamentally can. Given that, I do not think 3.2.2.4.1 should be considered - 
even in modified form - to be equivalent.

 

In considering how one might theorhetically reform 3.2.2.4.1, I would suggest 
it's incumbent upon those supporting it to demonstrate how it could achieve 
that level of assurance. Barring that, we are much better as an industry and a 
Forum from removing 3.2.2.4.1 unless and until such time as an appropriate 
demonstration can be made. This avoids introducing significant security risk to 
the ecosystem due to the Forum's (rather slow) deliberative process.

 

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

Tim H, you are chairing the Validation Working Group now – can the VWG take up 
possible revisions to BR 3.2.2.4.1 as an agenda item?

 

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Adriano Santoni via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: public@cabforum.org <mailto:public@cabforum.org> 
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document

 

I also concur with Mads, and would support the addition of more requirements to 
method 3.2.2.4.1.

I like the solution proposed by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.

Adriano

Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley  <mailto:jeremy.row...@digicert.com> 
; CA/Browser Forum Public Discussion List  
<mailto:public@cabforum.org> ; geo...@apple.com 
<mailto:geo...@apple.com> 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 

Then I think we should change the requirements. 

 

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my 

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Doug Beattie via Public]

I think this is exactly the type of change that the validation working group 
should hash out and then propose a solution to the public list.  I’m actually 
surprised that Tim sent this out given this was on our agenda for tomorrow and 
he informally polled a number of us on the use of method 1.

I believe that with some additional checks, we can make method 1 sufficiently 
secure.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 3:17 PM
To: Kirk Hall ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

Given the impact of this, while I don't suggest that the VWG shouldn't take 
this up, I also don't think that should be reason not to continue the 
discussion on the public list.

While I understand that Mads and Adriano have suggested they see value in 
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration that 
it remotely approaches the level of assurance of the other methods, or that it 
fundamentally can. Given that, I do not think 3.2.2.4.1 should be considered - 
even in modified form - to be equivalent.

In considering how one might theorhetically reform 3.2.2.4.1, I would suggest 
it's incumbent upon those supporting it to demonstrate how it could achieve 
that level of assurance. Barring that, we are much better as an industry and a 
Forum from removing 3.2.2.4.1 unless and until such time as an appropriate 
demonstration can be made. This avoids introducing significant security risk to 
the ecosystem due to the Forum's (rather slow) deliberative process.

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public 
mailto:public@cabforum.org>> wrote:
Tim H, you are chairing the Validation Working Group now – can the VWG take up 
possible revisions to BR 3.2.2.4.1 as an agenda item?

From: Public 
[mailto:public-boun...@cabforum.org<mailto:public-boun...@cabforum.org>] On 
Behalf Of Adriano Santoni via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: public@cabforum.org<mailto:public@cabforum.org>
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document


I also concur with Mads, and would support the addition of more requirements to 
method 3.2.2.4.1.

I like the solution proposed by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.
Adriano

Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:
I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

Doug

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley 
<mailto:jeremy.row...@digicert.com>; CA/Browser 
Forum Public Discussion List <mailto:public@cabforum.org>; 
geo...@apple.com<mailto:geo...@apple.com>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document


Then I think we should change the requirements.

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
We must remember that the domain validation methods also are used for EV (and 
not only OV) and when we have a strongly validated and verified organization 
(e.g. based on the EV requirements) it makes sense to allow for the 
organization to apply for certificates including domain names owned by the 
organization itself.

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain ow

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Tim Hollebeek via Public]

I will not oppose any effort by CAs to discuss whatever improvements they want 
to make to any of the validation methods in the validation working group.  I 
don’t think stifling discussion is helpful.

 

As chair of the group, I am going to do my best to run it in a fair and 
responsible manner, even when the expressed opinions disagree with mine or 
those of my employer.  I’d rather hear people’s best arguments for their 
preferred course of action.

 

Any member who wants to be part of the discussion, please feel free to show up 
for tomorrow’s call.

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, January 3, 2018 1:17 PM
To: Kirk Hall ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

Given the impact of this, while I don't suggest that the VWG shouldn't take 
this up, I also don't think that should be reason not to continue the 
discussion on the public list.

 

While I understand that Mads and Adriano have suggested they see value in 
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration that 
it remotely approaches the level of assurance of the other methods, or that it 
fundamentally can. Given that, I do not think 3.2.2.4.1 should be considered - 
even in modified form - to be equivalent.

 

In considering how one might theorhetically reform 3.2.2.4.1, I would suggest 
it's incumbent upon those supporting it to demonstrate how it could achieve 
that level of assurance. Barring that, we are much better as an industry and a 
Forum from removing 3.2.2.4.1 unless and until such time as an appropriate 
demonstration can be made. This avoids introducing significant security risk to 
the ecosystem due to the Forum's (rather slow) deliberative process.

 

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public mailto:public@cabforum.org> > wrote:

Tim H, you are chairing the Validation Working Group now – can the VWG take up 
possible revisions to BR 3.2.2.4.1 as an agenda item?

 

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Adriano Santoni via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: public@cabforum.org <mailto:public@cabforum.org> 
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document

 

I also concur with Mads, and would support the addition of more requirements to 
method 3.2.2.4.1.

I like the solution proposed by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.

Adriano



Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley  <mailto:jeremy.row...@digicert.com> 
; CA/Browser Forum Public Discussion List  
<mailto:public@cabforum.org> ; geo...@apple.com 
<mailto:geo...@apple.com> 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 

Then I think we should change the requirements. 

 

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation methods also are used for EV (and 
>not only OV) and when we have a strongly validated and verified organization 
>(e.g. based on the EV requirements) it makes sense to allow for the 
>organization to apply for certificates including domain names o

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

Given the impact of this, while I don't suggest that the VWG shouldn't take
this up, I also don't think that should be reason not to continue the
discussion on the public list.

While I understand that Mads and Adriano have suggested they see value in
3.2.2.4.1, I do not think there's a sufficiently compelling demonstration
that it remotely approaches the level of assurance of the other methods, or
that it fundamentally can. Given that, I do not think 3.2.2.4.1 should be
considered - even in modified form - to be equivalent.

In considering how one might theorhetically reform 3.2.2.4.1, I would
suggest it's incumbent upon those supporting it to demonstrate how it could
achieve that level of assurance. Barring that, we are much better as an
industry and a Forum from removing 3.2.2.4.1 unless and until such time as
an appropriate demonstration can be made. This avoids introducing
significant security risk to the ecosystem due to the Forum's (rather slow)
deliberative process.

On Wed, Jan 3, 2018 at 11:08 AM, Kirk Hall via Public 
wrote:

> Tim H, you are chairing the Validation Working Group now – can the VWG
> take up possible revisions to BR 3.2.2.4.1 as an agenda item?
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Adriano
> Santoni via Public
> *Sent:* Wednesday, January 3, 2018 5:12 AM
> *To:* public@cabforum.org
> *Subject:* [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and
> Domain Authorization Document
>
>
>
> I also concur with Mads, and would support the addition of more
> requirements to method 3.2.2.4.1.
>
> I like the solution proposed by Mad, but (if I am not mistaken) there is
> not a specific Whois record field for that information (org number), and I
> would avoid inserting that information in a field that's not expressly
> designed for it.
>
> Other solutions may also work, and would be easier to implement, like e.g.
> mandating a full Registrant address, in the Whois record, which must be one
> of the official addresses of the Registrant as found in a QIIS/QGIS
> (excluding, however, all information sources that just publish
> self-reported organization information, which cannot be regarded as
> "qualified" information sources and IMO should not be used in the vetting
> process), and then the "reliable method of communication" should be one
> that is found in the matching QIIS/QGIS record.
>
> Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a
> sufficient discussion on it, and I am not sure how it can effectively be
> used "as is" to obtain a fraudulent certificate.
>
> Adriano
>
>
> Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:
>
> I agree with Mads and am also supportive of a ballot that removes
> 3.2.2.4.5 and adds some more detail to 3.2.2.4.1.
>
>
>
> Doug
>
>
>
> *From:* Public [mailto:public-boun...@cabforum.org
> ] *On Behalf Of *Mads Egil Henriksveen via
> Public
> *Sent:* Wednesday, January 3, 2018 7:11 AM
> *To:* Jeremy Rowley 
> ; CA/Browser Forum Public Discussion List
>  ; geo...@apple.com
> *Subject:* Re: [cabfpub] Verification of Domain Contact and Domain
> Authorization Document
>
>
>
>
>
> Then I think we should change the requirements.
>
>
>
> As a representative for a CA with a background in strong identity
> validation (both for natural and legal persons) I find these examples from
> Ryan and Jeremy to represent a very bad practice. If this really reflects
> the current practice in the industry, we need to tighten up the
> requirements and make them much more specific.
>
>
>
> From my point of view (and with my background) I find method 3.2.2.4.1
> useful. We must remember that the domain validation methods also are used
> for EV (and not only OV) and when we have a strongly validated and verified
> organization (e.g. based on the EV requirements) it makes sense to allow
> for the organization to apply for certificates including domain names owned
> by the organization itself.
>
>
>
> I understand that there are doubts about how to ensure that the
> organization really owns the domain (like in Jeremy’s example), but it
> should not be too hard to “strengthen” the link between the applicant and
> the domain owner in terms of rewriting section 3.2.2.4.1. A match in the
> organization name only should of course not be allowed.
>
>
>
> In Norway every organization is given a unique organization number by a
> national authority and in the registry for the TLD=.no domains (see
> www.norid.no) we find this organization number as a part of the domain
> name registrant information. In such cases, we allow for issuance based on
> 3.2.2.4.1 if the domain na

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Tim Hollebeek via Public]

It’s now on the agenda.  I suspect it might end up taking up most of the call, 
so we’ll address it first …

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Wednesday, January 3, 2018 9:09 AM
To: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

Tim H, you are chairing the Validation Working Group now – can the VWG take up 
possible revisions to BR 3.2.2.4.1 as an agenda item?

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Adriano Santoni 
via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: public@cabforum.org <mailto:public@cabforum.org> 
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document

 

I also concur with Mads, and would support the addition of more requirements to 
method 3.2.2.4.1.

I like the solution proposed by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.

Adriano



Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley  <mailto:jeremy.row...@digicert.com> 
; CA/Browser Forum Public Discussion List  
<mailto:public@cabforum.org> ; geo...@apple.com 
<mailto:geo...@apple.com> 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 

Then I think we should change the requirements. 

 

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation methods also are used for EV (and 
>not only OV) and when we have a strongly validated and verified organization 
>(e.g. based on the EV requirements) it makes sense to allow for the 
>organization to apply for certificates including domain names owned by the 
>organization itself. 

 

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed. 

 

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no) we find this organization number as a part of the domain name 
registrant information. In such cases, we allow for issuance based on 3.2.2.4.1 
if the domain name registrant information exactly match organization 
information (i.e. by country, organization name and organization number).  I 
think this is a reasonable use case for method 3.2.2.4.1. 

 

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

 

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

 

Regards

Mads  

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com <mailto:geo...@apple.com> ; CA/Browser Forum Public 
Di

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Kirk Hall via Public]

Tim H, you are chairing the Validation Working Group now – can the VWG take up 
possible revisions to BR 3.2.2.4.1 as an agenda item?

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Adriano Santoni 
via Public
Sent: Wednesday, January 3, 2018 5:12 AM
To: public@cabforum.org
Subject: [EXTERNAL]Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document


I also concur with Mads, and would support the addition of more requirements to 
method 3.2.2.4.1.

I like the solution proposed by Mad, but (if I am not mistaken) there is not a 
specific Whois record field for that information (org number), and I would 
avoid inserting that information in a field that's not expressly designed for 
it.

Other solutions may also work, and would be easier to implement, like e.g. 
mandating a full Registrant address, in the Whois record, which must be one of 
the official addresses of the Registrant as found in a QIIS/QGIS (excluding, 
however, all information sources that just publish self-reported organization 
information, which cannot be regarded as "qualified" information sources and 
IMO should not be used in the vetting process), and then the "reliable method 
of communication" should be one that is found in the matching QIIS/QGIS record.

Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be used 
"as is" to obtain a fraudulent certificate.
Adriano


Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:
I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

Doug

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley 
<mailto:jeremy.row...@digicert.com>; CA/Browser 
Forum Public Discussion List <mailto:public@cabforum.org>; 
geo...@apple.com<mailto:geo...@apple.com>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document


Then I think we should change the requirements.

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
We must remember that the domain validation methods also are used for EV (and 
not only OV) and when we have a strongly validated and verified organization 
(e.g. based on the EV requirements) it makes sense to allow for the 
organization to apply for certificates including domain names owned by the 
organization itself.

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed.

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no<http://www.norid.no>) we find this organization number as a part 
of the domain name registrant information. In such cases, we allow for issuance 
based on 3.2.2.4.1 if the domain name registrant information exactly match 
organization information (i.e. by country, organization name and organization 
number).  I think this is a reasonable use case for method 3.2.2.4.1.

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

Regards
Mads

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com<mailto:geo...@apple.com>; CA/Browser Forum Public 
Discussion List <mailto:public@cabforum.org>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

From: geo...@apple.com<mailto:geo...@apple.com>

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Adriano Santoni via Public]

I also concur with Mads, and would support the addition of more 
requirements to method 3.2.2.4.1.


I like the solution proposed by Mad, but (if I am not mistaken) there is 
not a specific Whois record field for that information (org number), and 
I would avoid inserting that information in a field that's not expressly 
designed for it.


Other solutions may also work, and would be easier to implement, like 
e.g. mandating a full Registrant address, in the Whois record, which 
must be one of the official addresses of the Registrant as found in a 
QIIS/QGIS (excluding, however, all information sources that just publish 
self-reported organization information, which cannot be regarded as 
"qualified" information sources and IMO should not be used in the 
vetting process), and then the "reliable method of communication" should 
be one that is found in the matching QIIS/QGIS record.


Not sure about method 3.2.2.4.5, at this time, as I have not yet seen a 
sufficient discussion on it, and I am not sure how it can effectively be 
used "as is" to obtain a fraudulent certificate.


Adriano



Il 03/01/2018 13:27, Doug Beattie via Public ha scritto:


I agree with Mads and am also supportive of a ballot that removes 
3.2.2.4.5 and adds some more detail to 3.2.2.4.1.


Doug

*From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of 
*Mads Egil Henriksveen via Public

*Sent:* Wednesday, January 3, 2018 7:11 AM
*To:* Jeremy Rowley ; CA/Browser Forum 
Public Discussion List ; geo...@apple.com
*Subject:* Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document


Then I think we should change the requirements.

As a representative for a CA with a background in strong identity 
validation (both for natural and legal persons) I find these examples 
from Ryan and Jeremy to represent a very bad practice. If this really 
reflects the current practice in the industry, we need to tighten up 
the requirements and make them much more specific.


From my point of view (and with my background) I find method 3.2.2.4.1 
useful. We must remember that the domain validation methods also are 
used for EV (and not only OV) and when we have a strongly validated 
and verified organization (e.g. based on the EV requirements) it makes 
sense to allow for the organization to apply for certificates 
including domain names owned by the organization itself.


I understand that there are doubts about how to ensure that the 
organization really owns the domain (like in Jeremy’s example), but it 
should not be too hard to “strengthen” the link between the applicant 
and the domain owner in terms of rewriting section 3.2.2.4.1. A match 
in the organization name only should of course not be allowed.


In Norway every organization is given a unique organization number by 
a national authority and in the registry for the TLD=.no domains (see 
www.norid.no <http://www.norid.no>) we find this organization number 
as a part of the domain name registrant information. In such cases, we 
allow for issuance based on 3.2.2.4.1 if the domain name registrant 
information exactly match organization information (i.e. by country, 
organization name and organization number).  I think this is a 
reasonable use case for method 3.2.2.4.1.


Personally I am more concerned about the possibility we give to any 
stakeholder in the ecosystem who takes a role in controlling a domain 
to get an OV (and EV) certificate based on domain control only. This 
was discussed also in the F2F meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.


Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and 
keep 3.2.2.4.1 but strengthen this up to allow for use cases like the 
one described above.


Regards

Mads

*From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of 
*Jeremy Rowley via Public

*Sent:* onsdag 3. januar 2018 05:47
*To:* geo...@apple.com; CA/Browser Forum Public Discussion List 

*Subject:* Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document


I disagree. The requirements do not specify that.  All that is 
required is the name of the applicant was verified under 3.2.2.1 and 
that the register specify the domain contact is the applicant. If 
Google, Inc. is specified as the domain contact, no address matching 
is required.


*From:* geo...@apple.com <mailto:geo...@apple.com> 
[mailto:geo...@apple.com]

*Sent:* Tuesday, January 2, 2018 4:34 PM
*To:* Jeremy Rowley <mailto:jeremy.row...@digicert.com>>; CA/Browser Forum Public 
Discussion List mailto:public@cabforum.org>>
*Cc:* Ryan Sleevi mailto:sle...@google.com>>; 
Adriano Santoni <mailto:adriano.sant...@staff.aruba.it>>
*Subject:* Re: [cabfpub] Verification of Domain Contact and Domain 
Authorization Document


On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public
mailto:public@cabforum

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Doug Beattie via Public]

I agree with Mads and am also supportive of a ballot that removes 3.2.2.4.5 and 
adds some more detail to 3.2.2.4.1.

 

Doug

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Mads Egil 
Henriksveen via Public
Sent: Wednesday, January 3, 2018 7:11 AM
To: Jeremy Rowley ; CA/Browser Forum Public 
Discussion List ; geo...@apple.com
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 

Then I think we should change the requirements. 

 

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

 

>From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
>We must remember that the domain validation methods also are used for EV (and 
>not only OV) and when we have a strongly validated and verified organization 
>(e.g. based on the EV requirements) it makes sense to allow for the 
>organization to apply for certificates including domain names owned by the 
>organization itself. 

 

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed. 

 

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no <http://www.norid.no> ) we find this organization number as a part 
of the domain name registrant information. In such cases, we allow for issuance 
based on 3.2.2.4.1 if the domain name registrant information exactly match 
organization information (i.e. by country, organization name and organization 
number).  I think this is a reasonable use case for method 3.2.2.4.1. 

 

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

 

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

 

Regards

Mads  

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

 

From: geo...@apple.com <mailto:geo...@apple.com>  [mailto:geo...@apple.com] 
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org> >
Cc: Ryan Sleevi mailto:sle...@google.com> >; Adriano 
Santoni mailto:adriano.sant...@staff.aruba.it> 
>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 

 

On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:

 

The attack vector is easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning  
<http://google.com/> google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

 

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Mads Egil Henriksveen via Public]

Then I think we should change the requirements.

As a representative for a CA with a background in strong identity validation 
(both for natural and legal persons) I find these examples from Ryan and Jeremy 
to represent a very bad practice. If this really reflects the current practice 
in the industry, we need to tighten up the requirements and make them much more 
specific.

From my point of view (and with my background) I find method 3.2.2.4.1 useful. 
We must remember that the domain validation methods also are used for EV (and 
not only OV) and when we have a strongly validated and verified organization 
(e.g. based on the EV requirements) it makes sense to allow for the 
organization to apply for certificates including domain names owned by the 
organization itself.

I understand that there are doubts about how to ensure that the organization 
really owns the domain (like in Jeremy’s example), but it should not be too 
hard to “strengthen” the link between the applicant and the domain owner in 
terms of rewriting section 3.2.2.4.1. A match in the organization name only 
should of course not be allowed.

In Norway every organization is given a unique organization number by a 
national authority and in the registry for the TLD=.no domains (see 
www.norid.no<http://www.norid.no>) we find this organization number as a part 
of the domain name registrant information. In such cases, we allow for issuance 
based on 3.2.2.4.1 if the domain name registrant information exactly match 
organization information (i.e. by country, organization name and organization 
number).  I think this is a reasonable use case for method 3.2.2.4.1.

Personally I am more concerned about the possibility we give to any stakeholder 
in the ecosystem who takes a role in controlling a domain to get an OV (and EV) 
certificate based on domain control only. This was discussed also in the F2F 
meeting in Bilbao last year – see 
https://cabforum.org/2016/05/25/2016-05/#The-Role-of-Identity-in-TLS-Certificates.

Therefore, I am supportive for a ballot which removes 3.2.2.4.5 and keep 
3.2.2.4.1 but strengthen this up to allow for use cases like the one described 
above.

Regards
Mads

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: onsdag 3. januar 2018 05:47
To: geo...@apple.com; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

From: geo...@apple.com<mailto:geo...@apple.com> [mailto:geo...@apple.com]
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley 
mailto:jeremy.row...@digicert.com>>; CA/Browser 
Forum Public Discussion List mailto:public@cabforum.org>>
Cc: Ryan Sleevi mailto:sle...@google.com>>; Adriano Santoni 
mailto:adriano.sant...@staff.aruba.it>>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document



On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public 
mailto:public@cabforum.org>> wrote:

The attack vector is easier than that.

  1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
  2.  I verify that Jeremy did indeed incorporate Google, Inc.
  3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
  4.  The domain information shows Google, Inc. as owning 
google.com<http://google.com/>
  5.  Certificate issues.

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.


For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Jeremy Rowley via Public]

I disagree. The requirements do not specify that.  All that is required is the 
name of the applicant was verified under 3.2.2.1 and that the register specify 
the domain contact is the applicant. If Google, Inc. is specified as the domain 
contact, no address matching is required.

 

From: geo...@apple.com [mailto:geo...@apple.com] 
Sent: Tuesday, January 2, 2018 4:34 PM
To: Jeremy Rowley ; CA/Browser Forum Public 
Discussion List 
Cc: Ryan Sleevi ; Adriano Santoni 

Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 





On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:

 

The attack vector is easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning  
<http://google.com/> google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

 

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public  
> wrote:
> 
> The attack vector is easier than that. 
> I use very stringent processes to verify that Google, Inc. is a legit company 
> in Utah.
> I verify that Jeremy did indeed incorporate Google, Inc. 
> I call Jeremy at the phone listed for Google, Inc., the Utah corporation
> The domain information shows Google, Inc. as owning google.com 
> 
> Certificate issues.
>  
> Obviously this would be caught in every CA’s high risk checks, but the point 
> remains valid. Regardless of the expertise and thoroughness of the org check, 
> the specs lack any time between the verified org and the actual domain 
> because orgs are not unique on a global basis.
>  

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Jeremy Rowley via Public]

The attack vector is easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

Jeremy

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, December 21, 2017 9:58 AM
To: Adriano Santoni ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

Adriano,

 

Do you have an example of how you believe 3.2.2.4.1 can be used correctly? 

 

Specifically, it does not describe the process for validating that the 
Applicant is the Domain Contact with the Registrar - this isn't equivalent to 
using WHOIS.

 

Here's just one scenario:

- I ("Ryan Sleevi") apply to Foo CA for example.com <http://example.com> , 
which is owned by "Andriano Santoni's Lightly Validated Certificates" - you.

- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)

  - Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV certs, 
thus automatically met, but lets pretend its OV

  - They verify "Andriano Santoni's Lightly Validated Certificates" is a real 
company with a real existence using a QGIS. That's all that's needed - there's 
no binding to the Applicant, just an existence proof of the data.

  - Alternatively, I send a photoshopped letter claiming your company exists, 
valid under 3.2.2.1(4)

  - Alternatively, the CA declares that "Google Maps" is a Reliable Data Source 
(it isn't, but again, underspecified), and verifies that there's an entry under 
3.2.2.1(2) - despite the fact I just added the entry

- They then need to verify whether or not I'm authorized to speak for your 
company.

  - The information used in 3.2.2.1 doesn't have to be used ("the CA MAY use 
..."), but remember, I may have made it up under 3.2.2.1

  - The CA can directly call me, Ryan Sleevi, asking if I'm authorized ("the CA 
MAY establish the authenticity of the certificate request directly with the 
Applicant Representative")

  - The requirement to use an RMOC simply means that Foo CA could decide to 
call up Jeremy, since Jeremy knows me, and say "Hey, does Ryan work for Adriano 
Santoni" - that's all that's required.

- Finally, the CA contacts the registrar, and says "Hey, does Adriano Santoni's 
Lightly Validated Certificates own example.com <http://example.com> " - and the 
registrar says sure

  - Note: There's no consensus whether we're talking about the same 
organization - perhaps I created a version incorporated in the US, but you're 
incorporated in Italy

 

These are just a few of the legal-but-bad things you can do. I'm sure we'll see 
the normal rush from some CAs saying "Yes, but we'd never do that" - while 
ignoring the fact that some could, as it's valid under the language, and we 
consistently see "That which is valid (or subject to misinterpretation) is 
possible to use"

 

 

Could you provide an example of how you believe 3.2.2.4.1 "should" work and 
offer the same level of assurance as the other methods, without normatively 
prescribing the data sources used? From conversations with both current and 
past employees of CAs, I am adamantly convinced that there is not a consistent 
standard of reliableness being applies. Google Maps being used as a Reliable 
Data Source is not a hypothetical, despite it allowing community edits.

 

 

On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public 
mailto:public@cabforum.org> > wrote:

Jeremy, I am not sure I fully understand the problems you describe. 

Would it be possible for you to provide some concrete example related to method 
#1, with some details, without of course mentioning specific certificates 
and/or organizations?

 

Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:

Hi all, 

 

When reviewing the Symantec validation methods and the customers using each 
method, I found an alarming number of customers verified under 3.2.2.4.1 
(Verification of a Domain Contact) or 3.2.2.4.5 (Domain Authorization Document) 
where the domain is not technically associated with the entity. These two 
methods need improvement or removal as the way they are currently lacks 
sufficient controls to associate the domain veri

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

I don't think we could support such a ballot, without having an explanation
of why you believe method #1 is valuable and equivalent - even if tightened
up - to the other methods of validation.

On Fri, Dec 22, 2017 at 2:22 AM, Adriano Santoni via Public <
public@cabforum.org> wrote:

> Ryan,
>
> I think I see what you mean, but I also believe that the problem is not in
> method #1 per se, but rather in the "degrees of freedom" with which it may
> be implemented, as allowed by the BRs.
>
> In particular, I believe that establishing the authenticity of the request
> directly with the Applicant's Representative is a bad practice, regardless
> of the DCV method employed.
>
> I'd suggest to try and improve (tighten) the BRs, instead of killing DCV
> methods that make sense, per se, but should be implemented in a more robust
> way.
> For instance, I'd favour zapping the words "directly with the Applicant's
> Representative or" from the second paragraph of BR §3.2.5. Would not that
> be an improvement?
>
> Adriano
>
>
>
> Il 21/12/2017 17:57, Ryan Sleevi ha scritto:
>
> Adriano,
>
> Do you have an example of how you believe 3.2.2.4.1 can be used correctly?
>
> Specifically, it does not describe the process for validating that the
> Applicant is the Domain Contact with the Registrar - this isn't equivalent
> to using WHOIS.
>
> Here's just one scenario:
> - I ("Ryan Sleevi") apply to Foo CA for example.com, which is owned by
> "Andriano Santoni's Lightly Validated Certificates" - you.
> - Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)
>   - Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV
> certs, thus automatically met, but lets pretend its OV
>   - They verify "Andriano Santoni's Lightly Validated Certificates" is a
> real company with a real existence using a QGIS. That's all that's needed -
> there's no binding to the Applicant, just an existence proof of the data.
>   - Alternatively, I send a photoshopped letter claiming your company
> exists, valid under 3.2.2.1(4)
>   - Alternatively, the CA declares that "Google Maps" is a Reliable Data
> Source (it isn't, but again, underspecified), and verifies that there's an
> entry under 3.2.2.1(2) - despite the fact I just added the entry
> - They then need to verify whether or not I'm authorized to speak for your
> company.
>   - The information used in 3.2.2.1 doesn't have to be used ("the CA MAY
> use ..."), but remember, I may have made it up under 3.2.2.1
>   - The CA can directly call me, Ryan Sleevi, asking if I'm authorized
> ("the CA MAY establish the authenticity of the certificate request directly
> with the Applicant Representative")
>   - The requirement to use an RMOC simply means that Foo CA could decide
> to call up Jeremy, since Jeremy knows me, and say "Hey, does Ryan work for
> Adriano Santoni" - that's all that's required.
> - Finally, the CA contacts the registrar, and says "Hey, does Adriano
> Santoni's Lightly Validated Certificates own example.com" - and the
> registrar says sure
>   - Note: There's no consensus whether we're talking about the same
> organization - perhaps I created a version incorporated in the US, but
> you're incorporated in Italy
>
> These are just a few of the legal-but-bad things you can do. I'm sure
> we'll see the normal rush from some CAs saying "Yes, but we'd never do
> that" - while ignoring the fact that some could, as it's valid under the
> language, and we consistently see "That which is valid (or subject to
> misinterpretation) is possible to use"
>
>
> Could you provide an example of how you believe 3.2.2.4.1 "should" work
> and offer the same level of assurance as the other methods, without
> normatively prescribing the data sources used? From conversations with both
> current and past employees of CAs, I am adamantly convinced that there is
> not a consistent standard of reliableness being applies. Google Maps being
> used as a Reliable Data Source is not a hypothetical, despite it allowing
> community edits.
>
>
> On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public <
> public@cabforum.org> wrote:
>
>> Jeremy, I am not sure I fully understand the problems you describe.
>>
>> Would it be possible for you to provide some concrete example related to
>> method #1, with some details, without of course mentioning specific
>> certificates and/or organizations?
>>
>>
>> Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:
>>
>> Hi all,
>>
>>
>>
>> When reviewing the Symantec validation methods and the customers using
>> each method, I found an alarming number of customers verified under
>> 3.2.2.4.1 (Verification of a Domain Contact) or 3.2.2.4.5 (Domain
>> Authorization Document) where the domain is not technically associated with
>> the entity. These two methods need improvement or removal as the way they
>> are currently lacks sufficient controls to associate the domain
>> verification with the actual certificate approver. I’ve had too many calls
>> with customers explaining re-

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Adriano Santoni via Public]

Ryan,

I think I see what you mean, but I also believe that the problem is not 
in method #1 per se, but rather in the "degrees of freedom" with which 
it may be implemented, as allowed by the BRs.


In particular, I believe that establishing the authenticity of the 
request directly with the Applicant's Representative is a bad practice, 
regardless of the DCV method employed.


I'd suggest to try and improve (tighten) the BRs, instead of killing DCV 
methods that make sense, per se, but should be implemented in a more 
robust way.


For instance, I'd favour zapping the words "directly with the 
Applicant's Representative or" from the second paragraph of BR §3.2.5. 
Would not that be an improvement?


Adriano



Il 21/12/2017 17:57, Ryan Sleevi ha scritto:

Adriano,

Do you have an example of how you believe 3.2.2.4.1 can be used 
correctly?


Specifically, it does not describe the process for validating that the 
Applicant is the Domain Contact with the Registrar - this isn't 
equivalent to using WHOIS.


Here's just one scenario:
- I ("Ryan Sleevi") apply to Foo CA for example.com 
, which is owned by "Andriano Santoni's Lightly 
Validated Certificates" - you.

- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)
  - Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV 
certs, thus automatically met, but lets pretend its OV
  - They verify "Andriano Santoni's Lightly Validated Certificates" is 
a real company with a real existence using a QGIS. That's all that's 
needed - there's no binding to the Applicant, just an existence proof 
of the data.
  - Alternatively, I send a photoshopped letter claiming your company 
exists, valid under 3.2.2.1(4)
  - Alternatively, the CA declares that "Google Maps" is a Reliable 
Data Source (it isn't, but again, underspecified), and verifies that 
there's an entry under 3.2.2.1(2) - despite the fact I just added the 
entry
- They then need to verify whether or not I'm authorized to speak for 
your company.
  - The information used in 3.2.2.1 doesn't have to be used ("the CA 
MAY use ..."), but remember, I may have made it up under 3.2.2.1
  - The CA can directly call me, Ryan Sleevi, asking if I'm authorized 
("the CA MAY establish the authenticity of the certificate request 
directly with the Applicant Representative")
  - The requirement to use an RMOC simply means that Foo CA could 
decide to call up Jeremy, since Jeremy knows me, and say "Hey, does 
Ryan work for Adriano Santoni" - that's all that's required.
- Finally, the CA contacts the registrar, and says "Hey, does Adriano 
Santoni's Lightly Validated Certificates own example.com 
" - and the registrar says sure
  - Note: There's no consensus whether we're talking about the same 
organization - perhaps I created a version incorporated in the US, but 
you're incorporated in Italy


These are just a few of the legal-but-bad things you can do. I'm sure 
we'll see the normal rush from some CAs saying "Yes, but we'd never do 
that" - while ignoring the fact that some could, as it's valid under 
the language, and we consistently see "That which is valid (or subject 
to misinterpretation) is possible to use"



Could you provide an example of how you believe 3.2.2.4.1 "should" 
work and offer the same level of assurance as the other methods, 
without normatively prescribing the data sources used? From 
conversations with both current and past employees of CAs, I am 
adamantly convinced that there is not a consistent standard of 
reliableness being applies. Google Maps being used as a Reliable Data 
Source is not a hypothetical, despite it allowing community edits.



On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public 
mailto:public@cabforum.org>> wrote:


Jeremy, I am not sure I fully understand the problems you describe.

Would it be possible for you to provide some concrete example
related to method #1, with some details, without of course
mentioning specific certificates and/or organizations?



Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:


Hi all,

When reviewing the Symantec validation methods and the customers
using each method, I found an alarming number of customers
verified under 3.2.2.4.1 (Verification of a Domain Contact) or
3.2.2.4.5 (Domain Authorization Document) where the domain is not
technically associated with the entity. These two methods need
improvement or removal as the way they are currently lacks
sufficient controls to associate the domain verification with the
actual certificate approver. I’ve had too many calls with
customers explaining re-verification where the domain holder
didn’t understand that a cert issued for the domain. Although the
organization verification was successfully complete, the only tie
between the domain and organization is a call to the organization
that happened within the last years to approve the account for
issua

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

Adriano,

Do you have an example of how you believe 3.2.2.4.1 can be used correctly?

Specifically, it does not describe the process for validating that the
Applicant is the Domain Contact with the Registrar - this isn't equivalent
to using WHOIS.

Here's just one scenario:
- I ("Ryan Sleevi") apply to Foo CA for example.com, which is owned by
"Andriano Santoni's Lightly Validated Certificates" - you.
- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)
  - Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV certs,
thus automatically met, but lets pretend its OV
  - They verify "Andriano Santoni's Lightly Validated Certificates" is a
real company with a real existence using a QGIS. That's all that's needed -
there's no binding to the Applicant, just an existence proof of the data.
  - Alternatively, I send a photoshopped letter claiming your company
exists, valid under 3.2.2.1(4)
  - Alternatively, the CA declares that "Google Maps" is a Reliable Data
Source (it isn't, but again, underspecified), and verifies that there's an
entry under 3.2.2.1(2) - despite the fact I just added the entry
- They then need to verify whether or not I'm authorized to speak for your
company.
  - The information used in 3.2.2.1 doesn't have to be used ("the CA MAY
use ..."), but remember, I may have made it up under 3.2.2.1
  - The CA can directly call me, Ryan Sleevi, asking if I'm authorized
("the CA MAY establish the authenticity of the certificate request directly
with the Applicant Representative")
  - The requirement to use an RMOC simply means that Foo CA could decide to
call up Jeremy, since Jeremy knows me, and say "Hey, does Ryan work for
Adriano Santoni" - that's all that's required.
- Finally, the CA contacts the registrar, and says "Hey, does Adriano
Santoni's Lightly Validated Certificates own example.com" - and the
registrar says sure
  - Note: There's no consensus whether we're talking about the same
organization - perhaps I created a version incorporated in the US, but
you're incorporated in Italy

These are just a few of the legal-but-bad things you can do. I'm sure we'll
see the normal rush from some CAs saying "Yes, but we'd never do that" -
while ignoring the fact that some could, as it's valid under the language,
and we consistently see "That which is valid (or subject to
misinterpretation) is possible to use"


Could you provide an example of how you believe 3.2.2.4.1 "should" work and
offer the same level of assurance as the other methods, without normatively
prescribing the data sources used? From conversations with both current and
past employees of CAs, I am adamantly convinced that there is not a
consistent standard of reliableness being applies. Google Maps being used
as a Reliable Data Source is not a hypothetical, despite it allowing
community edits.


On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public <
public@cabforum.org> wrote:

> Jeremy, I am not sure I fully understand the problems you describe.
>
> Would it be possible for you to provide some concrete example related to
> method #1, with some details, without of course mentioning specific
> certificates and/or organizations?
>
>
> Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:
>
> Hi all,
>
>
>
> When reviewing the Symantec validation methods and the customers using
> each method, I found an alarming number of customers verified under
> 3.2.2.4.1 (Verification of a Domain Contact) or 3.2.2.4.5 (Domain
> Authorization Document) where the domain is not technically associated with
> the entity. These two methods need improvement or removal as the way they
> are currently lacks sufficient controls to associate the domain
> verification with the actual certificate approver. I’ve had too many calls
> with customers explaining re-verification where the domain holder didn’t
> understand that a cert issued for the domain. Although the organization
> verification was successfully complete, the only tie between the domain and
> organization is a call to the organization that happened within the last
> years to approve the account for issuance. I wanted to bring it up here
> because I’ve always thought these methods were less desirable than others.
> I think other large CAs use this method quite a bit so I’m hoping to get
> clarity on why these methods are permitted when the domain verification
> seems more “hand-wavy” than other methods.
>
>
>
> Method 3.2.2.4.1 permits a CA to issue a certificate if the certificate is
> an EV or OV cert. With EV certificates, there is a call to a verified
> telephone number that confirms the requester’s affiliation with the
> organization. I can see this method working for EV.  For OV certificates,
> there is a reliable method of communication that confirms the account
> holder as affiliated with the organization.  Unlike EV, for OV certs there
> is no tie between the requester and their authority to request a
> certificate. Once the organization is verified, the BRs permit
> auto-i

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Adriano Santoni via Public]

Jeremy, I am not sure I fully understand the problems you describe.

Would it be possible for you to provide some concrete example related to 
method #1, with some details, without of course mentioning specific 
certificates and/or organizations?




Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:


Hi all,

When reviewing the Symantec validation methods and the customers using 
each method, I found an alarming number of customers verified under 
3.2.2.4.1 (Verification of a Domain Contact) or 3.2.2.4.5 (Domain 
Authorization Document) where the domain is not technically associated 
with the entity. These two methods need improvement or removal as the 
way they are currently lacks sufficient controls to associate the 
domain verification with the actual certificate approver. I’ve had too 
many calls with customers explaining re-verification where the domain 
holder didn’t understand that a cert issued for the domain. Although 
the organization verification was successfully complete, the only tie 
between the domain and organization is a call to the organization that 
happened within the last years to approve the account for issuance. I 
wanted to bring it up here because I’ve always thought these methods 
were less desirable than others. I think other large CAs use this 
method quite a bit so I’m hoping to get clarity on why these methods 
are permitted when the domain verification seems more “hand-wavy” than 
other methods.


Method 3.2.2.4.1 permits a CA to issue a certificate if the 
certificate is an EV or OV cert. With EV certificates, there is a call 
to a verified telephone number that confirms the requester’s 
affiliation with the organization. I can see this method working for 
EV.  For OV certificates, there is a reliable method of communication 
that confirms the account holder as affiliated with the organization.  
Unlike EV, for OV certs there is no tie between the requester and 
their authority to request a certificate. Once the organization is 
verified, the BRs permit auto-issuance for any domain that reflects an 
affiliation with the verified entity for up to 825 days. There’s no 
notice to the domain contact that the certificate was requested or 
approved.  Perhaps this is sufficient as the account has been 
affiliated with the organization through the reliable method of 
communication and because CT will soon become mandatory.


Method 3.2.2.4.5 permits a CA to issue a certificate using a legal 
opinion letter for the domain. Unfortunately the BRs lack clear 
requirements about how the legal opinion letter is verified. If I want 
a cert for Google.com and the CA is following the bare minimum, all I 
need to do is copy their letterhead and sign the document. Magically, 
a certificate can issue.  This method lacks a lot of controls of 
method 1 because there is no requirement around verification of the 
company. I can list as many domains in the letter as I’d like provided 
the entity listed in the corresponding WHOIS’s letterhead is used.


I’m looking to remove/fix both of these methods as both these methods 
lack the necessary controls to ensure that the verification ties to 
the domain holder. These methods probably should have been removed 
back when we passed 169/182. Would anyone being willing to endorse a 
ballot killing these or making some necessary improvements?


Jeremy



___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public




smime.p7s
Description: Firma crittografica S/MIME
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Rich Smith via Public]

Jeremy, I would also happily endorse a ballot removing both these methods.

 

-Rich

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Tuesday, December 19, 2017 4:03 PM
To: Jeremy Rowley ; CA/Browser Forum Public 
Discussion List 
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

 

 

On Tue, Dec 19, 2017 at 4:30 PM, Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:

I’m looking to remove/fix both of these methods as both these methods lack the 
necessary controls to ensure that the verification ties to the domain holder. 
These methods probably should have been removed back when we passed 169/182. 
Would anyone being willing to endorse a ballot killing these or making some 
necessary improvements? 

 

Certainly, the concerns you raise with 3.2.2.4.5 are ones we shared, such as 
during the discussion in the Berlin F2F regarding the use of Delegated Third 
Parties for Domain Control Validation. During that discussion, we spent some 
time discussing how that particular validation method allows for a host of 
risks associated with issuance - and for the ambiguity as to how the CA 
appropriately validates the authenticity and the credentials.

 

I'm not sure I share your optimism for 3.2.2.4.1 with respect to EV.

 

In discussions about why site operators might want to limit what methods a CA 
can use to issue, these two methods are both examples of less than ideal 
methods, and so I'm thrilled to see others recognize it, while simultaneously 
disheartened at how many customers were validated through those methods.

 

We'd be happy to endorse removal of both of those methods.

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Ryan Sleevi via Public]

On Tue, Dec 19, 2017 at 4:30 PM, Jeremy Rowley via Public <
public@cabforum.org> wrote:
>
> I’m looking to remove/fix both of these methods as both these methods lack
> the necessary controls to ensure that the verification ties to the domain
> holder. These methods probably should have been removed back when we passed
> 169/182. Would anyone being willing to endorse a ballot killing these or
> making some necessary improvements?
>

Certainly, the concerns you raise with 3.2.2.4.5 are ones we shared, such
as during the discussion in the Berlin F2F regarding the use of Delegated
Third Parties for Domain Control Validation. During that discussion, we
spent some time discussing how that particular validation method allows for
a host of risks associated with issuance - and for the ambiguity as to how
the CA appropriately validates the authenticity and the credentials.

I'm not sure I share your optimism for 3.2.2.4.1 with respect to EV.

In discussions about why site operators might want to limit what methods a
CA can use to issue, these two methods are both examples of less than ideal
methods, and so I'm thrilled to see others recognize it, while
simultaneously disheartened at how many customers were validated through
those methods.

We'd be happy to endorse removal of both of those methods.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Verification of Domain Contact and Domain Authorization Document

[Jeremy Rowley via Public]

Hi all, 

 

When reviewing the Symantec validation methods and the customers using each
method, I found an alarming number of customers verified under 3.2.2.4.1
(Verification of a Domain Contact) or 3.2.2.4.5 (Domain Authorization
Document) where the domain is not technically associated with the entity.
These two methods need improvement or removal as the way they are currently
lacks sufficient controls to associate the domain verification with the
actual certificate approver. I've had too many calls with customers
explaining re-verification where the domain holder didn't understand that a
cert issued for the domain. Although the organization verification was
successfully complete, the only tie between the domain and organization is a
call to the organization that happened within the last years to approve the
account for issuance. I wanted to bring it up here because I've always
thought these methods were less desirable than others. I think other large
CAs use this method quite a bit so I'm hoping to get clarity on why these
methods are permitted when the domain verification seems more "hand-wavy"
than other methods. 

 

Method 3.2.2.4.1 permits a CA to issue a certificate if the certificate is
an EV or OV cert. With EV certificates, there is a call to a verified
telephone number that confirms the requester's affiliation with the
organization. I can see this method working for EV.  For OV certificates,
there is a reliable method of communication that confirms the account holder
as affiliated with the organization.  Unlike EV, for OV certs there is no
tie between the requester and their authority to request a certificate. Once
the organization is verified, the BRs permit auto-issuance for any domain
that reflects an affiliation with the verified entity for up to 825 days.
There's no notice to the domain contact that the certificate was requested
or approved.  Perhaps this is sufficient as the account has been affiliated
with the organization through the reliable method of communication and
because CT will soon become mandatory. 

 

Method 3.2.2.4.5 permits a CA to issue a certificate using a legal opinion
letter for the domain. Unfortunately the BRs lack clear requirements about
how the legal opinion letter is verified. If I want a cert for Google.com
and the CA is following the bare minimum, all I need to do is copy their
letterhead and sign the document. Magically, a certificate can issue.  This
method lacks a lot of controls of method 1 because there is no requirement
around verification of the company. I can list as many domains in the letter
as I'd like provided the entity listed in the corresponding WHOIS's
letterhead is used.

 

I'm looking to remove/fix both of these methods as both these methods lack
the necessary controls to ensure that the verification ties to the domain
holder. These methods probably should have been removed back when we passed
169/182. Would anyone being willing to endorse a ballot killing these or
making some necessary improvements?  

 

Jeremy

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public