[cabfpub] Proposed motion to modify EV domain verification section

Tue May 7 16:19:49 UTC 2013

I think we are waaay over complicating this.  Our role as CAs is two-fold:

1) Verify domain ownership/control

2) For OV and EV certs, verify the identity of the individual or organization to be named in the certificate Subject details to the degree prescribed by the BR or EV Guidelines respectively.

I have seen in this conversation, and in past conversations an attempt to tie those two roles together, which really can't be done effectively.  There is absolutely no way to guarantee that the party named in the cert ACTUALLY is the party running the site, or doing business on it, only that they have requested/authorized their identity to be used in association with it.  Likewise I have no sure way of verifying that the party who ACTUALLY owns the domain, i.e. purchased it directly from the registrar, is or is not the party named either in the certificate or on the WHOIS information.

An old adage in the SysAdmin world is, "If I have physical access to the box, I own the box."  The equivalent to that on the internet is, "If I control the DNS, I own the domain."  That takes care of #1 and any attempt we make to go further than that for the purpose of verifying domain ownership/control is really quite pointless.

As for #2 we verify that the named organization exists and that they did in fact request that this certificate be issued with their name on it.  That's it.  Very simple.  We CAN'T EVER be sure that that organization actually owns the domain, and that seems to be the main argument being presented.

Hypothetical:

Acme, Inc. owns example.com.  They have authorized Widgets, Inc. to operate a web site at widgets.example.com and obtain an EV certificate for it.

We attempt to verify to EV standards and in doing so we tell Widgets, Inc. that the WHOIS info is wrong and must be updated to show them as domain registrant.  Rather than jump through a bunch of needless hoops and involve an attorney, Acme, Inc. simply logs in, changes domain registrant to Widgets, Inc. while we take a screenshot of the WHOIS info, then they immediately change it back to say Acme, Inc. maybe even before the certificate is actually issued.

What exactly have we accomplished that we could not have accomplished equally well with an email sent to admin at example.com asking them to confirm authorization of the certificate request for widgets.example.com, or asking them to make an agreed upon change to the site at widgets.example.com?  Answer: Exactly nothing.  It was a complete waste of everyone's time.  Acme has always, and continues to own the domain, we just have a screenshot of some fleeting and inaccurate WHOIS information.  Nobody is any better off or more secure as a result.

Everyone seems to want to make the CA the be all end all of internet security.  We aren't and we can't be.  We can only do what we can do and putting up useless obstacles doesn't change that fact, it just makes our job more difficult and our customers more frustrated for no good reason.  It's really no wonder people get fed up with us.

ICANN can't enforce their standards.  Sounds like a problem for ICANN.  It's not my job to enforce their standards.  It's my job to verify that the Applicant has, in some manner, been authorized to use the domain for which they have requested a certificate, whether it be that they purchased that right directly from the registrar, or purchased that right from a third party that purchased it from the registrar, AND, as a separate process, verify that they are who they say they are.  There is no situation where I can do more than that.

Rich

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ben Wilson
Sent: Tuesday, May 07, 2013 10:57 AM
To: 'Ryan Hurst'; jeremy.rowley at digicert.com; 'Eddy Nigg (StartCom Ltd.)'; public at cabforum.org
Subject: Re: [cabfpub] Proposed motion to modify EV domain verification section

This thread brings up an important syntactical improvement that we need to make in the BRs and EV Guidelines.  We ought to start now with EV, since that is what we’re currently discussing.  Occasionally people will say we need to be more exact with terms like “domain name”, “FQDN”, etc.  While we have made great improvements since EV 1.0, there are still more to be made.  

Let’s say that the FQDN or sub-domain is controlled under a license granted by the domain name registrant, but the domain name registrant might be difficult to contact, etc.   It might be clear from the domain name registrant’s architecture/business model that the registrant’s usual practice is to assign subdomains or set up FQDNs.  Similarly, it might be clear from the EV applicant’s usual practice that they obtain an assignment of a particular subdomain or particular FQDN as a service provider to domain name registrants.  I can see a practical demonstration through DNSSEC routing to particular IP address blocks shows sufficient control.  By issuing the EV certificate, I do not think we are attesting to domain name registration.  In most cases, yes, but in some we are attesting to the entity behind the server, FQDN or sub-domain, in which cases the process for validation changes because the goal has changed.    

Even if you do not accept these two hypotheticals, we still need to go through both documents with a fine-toothed comb to remove potential ambiguities.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Hurst
Sent: Monday, May 06, 2013 10:56 PM
To: jeremy.rowley at digicert.com; 'Eddy Nigg (StartCom Ltd.)'; public at cabforum.org
Subject: Re: [cabfpub] Proposed motion to modify EV domain verification section

While I agree the syntactic checks prescribed in Report 58 will increase the accuracy of information in WHOIS, the fact is it is supposed to be accurate today even though we know registrars do a bad job at meeting the requirement and ICANN does a bad job at mandating they meet it.

When it comes to the policies we author, I think we should build them on what is required by the entities involved and build mitigations for the reality of their practices; in this case it means WHOIS data should be allowed but be syntactically validated and corroborated with other data sources.

As for allowing other forms of domain control verification, I am not opposed to supporting mechanism that actually allow verification of control of the domain but some technical verifications in use today do not do that, for example they may verify control of a host within the domain which is different than controlling the domain itself.

Even if we do that though I think it’s important we still allow for WHOIS based verification, just as I think it’s important the registrars and ICANN live up to their obligations to ensure it is accurate.

Ryan

From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com] 
Sent: Monday, May 06, 2013 9:40 PM
To: 'Ryan Hurst'; 'Eddy Nigg (StartCom Ltd.)'; public at cabforum.org
Subject: RE: [cabfpub] Proposed motion to modify EV domain verification section

I recognize that there is a self-reporting requirement and that SSAC Report #58 released this year has some recommendations that, if adopted, will greatly improve the WHOIS contents.  Considering the large number of WHOIS listings that are incorrect and that self-reported data is not permitted under EV, I think other verification requirements are more effective at determining the controller/owner of the website.

I think looking at what registrars do is a good way to expand the domain validation scope. However, I think the Forum already has several effective methods of verifying domain names in the BRs, and I do not see the harm in permitting these same procedures for EV.

Jeremy

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Hurst
Sent: Monday, May 06, 2013 10:23 PM
To: jeremy.rowley at digicert.com; 'Eddy Nigg (StartCom Ltd.)'; public at cabforum.org
Subject: Re: [cabfpub] Proposed motion to modify EV domain verification section

Since 2003 ICANN has required the information to be validated yearly - http://www.icann.org/en/resources/registrars/consensus-policies/wdrp the policy was poorly written, did not consider global privacy requirements and is not enforced but it is at least mandated; http://www.circleid.com/posts/20120719_a_confession_about_icann_whois_data_reminder_policy/ 

I understand one of the key reasons of non-enforcement is that ICANN feels they do not have the teeth to do so in the existing contracts with registrars.

I also understand that they have addressed this contractual teeth issue with the gTLD contracts.

As we look at this topic I believe it is best to consider both what registrars are required to do and build mitigations based on what they truly do.

Ryan

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Monday, May 06, 2013 9:00 PM
To: 'Eddy Nigg (StartCom Ltd.)'; public at cabforum.org
Subject: Re: [cabfpub] Proposed motion to modify EV domain verification section

We do require a human interaction (and that won’t change) when we verify the certificate requester.  However, that is separate from domain verification.  Considering that WHOIS information is essentially non-verified information, I don’t think the WHOIS check provides any insight about the domain’s operator.  Until ICANN requires verification of each domain applicant, the WHOIS information is less reliable (IMO) than several of the verification methods permitted under the baseline requirements.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Monday, May 06, 2013 9:56 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Proposed motion to modify EV domain verification section

On 05/06/2013 05:42 PM, From Rich Smith: 

What's more, the EV requirement around domain verification is currently LESS
SECURE than OV/DV in this regard as it ONLY requires looking at WHOIS.  To
the best of my knowledge there has never been a case of any mis-issuance of
a certificate to an unauthorized domain where a technical mechanism was used
to verify domain authorization.

If anything we should probably require a technical verification and a human interaction via WHOIS to really improve it.

I'm not sure... if we'd simply rely on technical verification under certain circumstances certificates could be issued unintentional and then in the EV level. I'm not very comfortable with the thought to solemnly rely on a domain control validation. 

Also EV certificates should probably identify the entity that stands behind the web site (even though the guidelines allow for authorization and delegation of sites to a validated entity), it requires either a lookup at the WHOIS records and/or web sites involved to confirm that.

It is also extremely frustrating for a customer who, for example, gets a
request from us to unmask whois, gets an email sent to a WHOIS contact and
responds to it, then gets another request that they now have go back in and
change the WHOIS info because we have found it to not match now that we can
see it.  From their point of view, the email established that they own the
domain so we are now just wasting their time.

Yes, probably most of us are aware of the difficulties with that, on the other hand it also relays to the parties involved that an EV isn't that easy to get. Agreed that your proposal would reduce some of the hassle with that and make EV more convenient.

Regards 

Signer: 

Eddy Nigg, COO/CTO

StartCom Ltd. <http://www.startcom.org> 

XMPP: 

startcom at startcom.org

Blog: 

Join the Revolution! <http://blog.startcom.org> 

Twitter: 

Follow Me <http://twitter.com/eddy_nigg> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130507/0c4fe711/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130507/0c4fe711/attachment-0003.bin>