> 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
