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

[Ryan Sleevi]

On Mon, Dec 4, 2017 at 1:42 PM, Geoff Keating <geoffk at apple.com> wrote:

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


Other potential issues with (i)(2)

- "reliable individual or firm" is undefined. For example, is Google Maps
sufficiently reliable, as some CAs assert? The business information may be
community submitted, derived from OCR in the images ("machine learning"),
or potentially from other sources (e.g. web crawls)
- (a)'s enumerations of verification are illustrative, non-normative
- (b) indicates that the CA must determine this, but does not affect the
conclusion
- (c) indicates that the CA must determine this, but does not affect the
conclusion
- (d) indicates that the CA must determine this, but does not affect the
conclusion
- (e) requires photos, but no binding of those photos to the ID

When we consider the holistic EV ecosystem, the complete and abject failure
of all of these controls in the face of common sense does not itself
represent misissuance - it's totally valid, and thus would be hard to fault
a CA for doing what is totally valid. Further, when approached to obtain a
certificate, the same hardship that has lead to some CAs proposing weaker
checks (due to having to deny potential customers as a result of the
current checks) also incentivizes CAs to favor the applicant. There's a
compelling benefit to the CA if it can sell an EV certificate to a customer
that fully complies with the EV Guidelines, particularly if anything bad
happens is "not their fault, but the fault of the guidelines".

Further, coupled with the liability requirements that don't trigger based
on issuance, but based on provable misuse (which such proof being
impossible to reliably demonstrate using existing technology), there's very
little downside to the CA.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171204/8df8b11d/attachment-0003.html>