[cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

[Geoff Keating]

> On 29 Nov 2017, at 9:44 am, Wayne Thayer via Public <public at cabforum.org> wrote:
> 
> The EV process is intended to gather a robust body of information about the Subject that, when viewed collectively, "provides users with a trustworthy confirmation of the identity of the entity". James and later Ryan have pointed out a weakness in the standard where incorrect data from a single data source (QGIS) could be used to obtain a "properly validated" EV certificate containing that incorrect data.
> 
> A positive outcome from this discussion would be for the Validation WG to review this information and propose changes to the EVGLs (such as a requirement for face-to-face validation mentioned by Jeremy) that mitigate this weakness.

I’m not sure how face-to-face validation helps here, other than it means the applicant now has a chance to lie to your face, which at least adds a personal touch…

I understand that the flaw being discussed is that the physical address data reported by QGISs/etc. may be self-reported by the entity and not immediately (or ever) validated.   That seems like a problem, and really strikes at the heart of the 11.4.1(A) address verification.  Unless it can be fixed I would think we have to remove those methods and leave just (i)(2), (2), and (3).  [It would be nice if we could renumber this section so that it did not go (i)(1) (i)(2) (2) (3) (4).]

Is there any way we can make such a check reliable?  Some methods I have thought of that won’t work are:

- There could be an aging requirement, on the grounds that a renewal notice is sent—but if the renewal is paid anyway, perhaps online, we’d be relying on the letter being returned undeliverable and the Registration Authority noticing this fact, which seems unreliable.
- It seems like all the various information sources copy each other so we can’t rely on multiple sources.
- If any information sources actually validate the data, they don’t seem to say so, so it’s probably useless to require use of only information sources that say they validate the address.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171204/be17fdd1/attachment-0002.p7s>