[cabfpub] Proposed motion to modify EV domain verification section

Wed May 8 16:00:28 UTC 2013

It has been brought to my attention that my responses to this thread may be 
leading some to believe that I am trying to do away with/ban reliance on WHOIS 
information.  While I personally consider checking WHOIS to be about the least 
trustworthy method of verifying domain ownership/control, it is not my intent 
to convince the entire industry to abandon WHOIS, and I may still use it 
myself in a pinch.

My arguments against WHOIS are being used to demonstrate that if we are 
verifying domain control via email, site change or DNS then WHOIS is 
irrelevant and SHOULD NOT be REQUIRED.  If you want to use it, fine, but in 
the current ecosystem it is less reliable than technical methods, and I don't 
think that the EV Guidelines or the BR should dictate that WHOIS MUST be 
consulted because it simply isn't trustworthy at the end of the day.  Let me 
ignore it if I choose to do so as long as I'm verifying domain control in a 
reliable fashion.

My core argument is simply that, with the exception of #7 which, as Jeremy has 
pointed out, is probably too vague to allow for EV, the other acceptable 
methods described in the BR are AT LEAST as reliable as looking at WHOIS info 
(I consider most of them superior) so they should be allowed for EV.

Rich

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On 
Behalf Of Rich Smith
Sent: Tuesday, May 07, 2013 3:55 PM
To: 'Eddy Nigg (StartCom Ltd.)'; public at cabforum.org
Subject: Re: [cabfpub] Proposed motion to modify EV domain verification 
section

My responses inline below:

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On 
Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Tuesday, May 07, 2013 3:13 PM

On 05/07/2013 07:19 PM, From Rich Smith:

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.

If that is true, could be please perhaps help me understand what the 
differences between BR OV and EV effectively are? Or in other words, what 
would we have to adjust besides your proposal to make OV and EV exactly the 
same thing?

[RWS] The difference lies in #2, the level of identity checking, not in #1, 
the domain verification.  IMO, unless and until ICANN and their registrars get 
their respective acts together the ONLY piece of information contained in 
WHOIS that should come into consideration for a CA are the contact email 
addresses and possibly the phone numbers, and those ONLY to establish a way to 
contact the domain owner via phone or email to verify the certificate request. 
The other details in WHOIS info are completely unverified and therefore 
unreliable and irrelevant.

If your suggestion and proposal will be acceptable to the CABF members 
including the browser vendors, we might want to align BR OV and EV further to 
the point so that OV could be basically relinquished. Considering that browser 
don't make any effort for BR IV/OV anyway, we might pursue such an effort.

[RWS] I'm completely open to that possibility, but currently there are 
individuals and still some organization types which don't qualify for EV, but 
do value some level of identity checking even though the browsers won't 
differentiate it.  If we can revise the EV requirements sufficiently to allow 
those to obtain them then I would love to discuss deprecating IV/OV.

It might reduce the quality of EV slightly, but with the benefit for higher 
adoption. I was always under the impression that EV means EXTENDED 
validation - and one of the goals is to clearly identify the entity to a 
visitor that he would expect to see at the site/certificate. E.g. somebody 
visiting paypal.com expects to see PayPal, Inc. (US) and not SomeISP, LLC 
(US).

[RWS] To a point you're right, but we can't DEFINITIVELY do that.  There is 
nothing in the EV Guidelines which prevents PayPal from sub-letting a 
sub-domain to a third party for instance, and the EV Guidelines allow for 
that, but currently both the Applicant and PayPal have to jump through what I 
see as unnecessary hoops to do it.  There is also nothing, not even the 
aforementioned hoops, to stop PayPal from obtaining an EV cert for a 
sub-domain of paypal.com in their own name and then allowing some third party 
to use that sub-domain and it's certificate to do some other unrestricted and 
unrelated business on that sub-domain.  The domain is PayPal's property.  What 
they do with that property in this regard is completely outside the scope of 
what we do as CAs.  We can't control it, we can't police it, and IMO it is 
outside our scope legally, and ethically to try.  It's their property.  Our 
job is simply to verify the details in the certificate and to verify that both 
the domain owner, and whatever entity is named in the certificate, whether the 
same or different, approve the issuance of the certificate.  Anything beyond 
that is, of necessity, between the domain owner, the site operator, and the 
end user.  IMO we go too far if we are trying to insert ourselves into that, 
and there is no practical way to do so reliably even if you think we should, 
which I do not.

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/20130508/7c654c35/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/20130508/7c654c35/attachment-0003.bin>