[cabfpub] Verification of Domain Contact and Domain Authorization Document

Wed Jan 3 13:11:59 UTC 2018

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-bounces at cabforum.org] *On Behalf Of 
> *Mads Egil Henriksveen via Public
> *Sent:* Wednesday, January 3, 2018 7:11 AM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum 
> Public Discussion List <public at cabforum.org>; geoffk at 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-bounces at cabforum.org] *On Behalf Of 
> *Jeremy Rowley via Public
> *Sent:* onsdag 3. januar 2018 05:47
> *To:* geoffk at apple.com; CA/Browser Forum Public Discussion List 
> <public at 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:* geoffk at apple.com <mailto:geoffk at apple.com> 
> [mailto:geoffk at apple.com]
> *Sent:* Tuesday, January 2, 2018 4:34 PM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com 
> <mailto:jeremy.rowley at digicert.com>>; CA/Browser Forum Public 
> Discussion List <public at cabforum.org <mailto:public at cabforum.org>>
> *Cc:* Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>>; 
> Adriano Santoni <adriano.santoni at staff.aruba.it 
> <mailto:adriano.santoni at 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
>     <public at cabforum.org <mailto:public at 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 owninggoogle.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 at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180103/d4a1ee42/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4025 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.cabforum.org/pipermail/public/attachments/20180103/d4a1ee42/attachment-0003.p7s>