Geoff, a few quick responses to your points below: 1. I think you are proposing the CA confirm the address information by sending (mail, delivery) a confirmation message with a shared secret to the customer, and requiring a response back using the shared secret. I think that's a good idea - it might get problematic for a big company (for Apple, we might have to mail to you at 1 Infinity Loop - how long would it take for you to receive it?).
2. We can also require a Face-to-Face requirement to discourage potential fraudsters, maybe limited to companies less than 1 year old (less than 6 months old?) and with net worth (as reported in a third party business data source) of less than $1 million (?) - financial estimates like that are made by the third party data source, and are not self-reported. Maybe we also should limit the mailing address confirmation the same way - only require for companies that are less than 1 year old (6 months old?) and with new worth (as reported in a third party business data source) of less than $1 million. 3. Geoff, while it's true that third party data sources will start with self-reported data (like name and address), the rest of the data they use is typically compiled by the third party data source, not just from self-reported data or copied from public government data bases. Remember, the main customers of Hoover's and D&B are using the data to make major credit decisions, not just to confirm addresses or incorporation status, and the third party data sources use their own data (including credit reporting from vendors who work with the subject company) and their own anti-fraud algorithms to avoid broadcasting false data. -----Original Message----- From: Public [mailto:[email protected]] On Behalf Of Geoff Keating via Public Sent: Monday, December 4, 2017 10:42 AM To: Wayne Thayer <[email protected]>; CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing > On 29 Nov 2017, at 9:44 am, Wayne Thayer via Public <[email protected]> > 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. _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
