[cabfpub] Proposed motion to modify EV domain verification section

[Rich Smith]

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/20130507/4a3426de/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/4a3426de/attachment-0003.bin>