[cabfpub] Proposed motion to modify EV domain verification section

[Eddy Nigg (StartCom Ltd.)]

On 05/07/2013 10:54 PM, From Rich Smith:
>
> 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./*
>

Yes, but it doesn't matter - if I validated PayPal, Inc. (the legal 
entity) and verify that paypal.com's WHOIS records contain the exact 
company details as we already established, then we can assume that 
PayPal owns paypal.com - In fact I'd require a domain control validation 
aka BR first and then make the WHOIS check.

It's not that we check the WHOIS records first and confirm that whoever 
claims to own paypal.com is actually PayPal, Inc.

> *//*
>
>
> 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./*
>

I was talking only about OV, not IV. As of now we probably will not have 
a chance to get individuals supports in the EV level due to browser 
objection.

> *//*
>
>
> 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.
> /*
>

I think it's necessary to establish the assurance we want for EV - I'd 
rather support to remove that sub-letting as you called it. Considering 
using the BR - it requires to validate the domain name and not control 
over a sub domain (when using email ping), so your argument from above 
doesn't really hold as there will be no improvement as I see it.


Regards
Signer: 	Eddy Nigg, COO/CTO
	StartCom Ltd. <http://www.startcom.org>
XMPP: 	startcom at 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/8222588c/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4540 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130508/8222588c/attachment-0001.p7s>