On Thu, 13 Sep 2018 12:26:55 -0700 Wayne Thayer via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> https://wiki.mozilla.org/CA:Visa_Issues Thanks for this list Wayne, you do a valuable task in assembling lists like this for us to ponder. > I would like to request that a representative from Visa engage in this > discussion and provide responses to these issues. And I look forward to that. Meanwhile. For Issue D: This looks like the problem we saw with CrossCert where nobody is keeping proper records OR where they know the records they're keeping are sub-par so they refuse to show them to auditors, which has much the same effect. There's a good chance if this CA issues a cert we later conclude was bogus, they are unable to produce any meaningful evidence of how it came to be issued, and we're just back to Symantec-style "We've fired the employee who did it" which is not a basis on which we can have confidence in the operation of the CA. Others: I'd also like to understand whether this CA root exists for the Web PKI or if in fact Visa operates it for some other reason, and the issuance of certificates valid in the Web PKI is a secondary or tertiary function. That is: CT logs show only a handful per month of new certificates issued by this CA, but are there in fact more (perhaps far more) issued that aren't for the Web PKI but are issued by this same root ? In Bug #1315016 Visa's representative says the certificates discussed were part of a "Visa product" as distinct from being separately replaceable components. To the extent that in fact trust in the Web PKI is orthogonal to Visa's needs here, it may actually make sense for Visa to take the lead in separating from the Web PKI rather than waiting to get kicked out of root programmes. The reason is that we've seen previously (e.g. with SHA-1) that financial services companies like Visa proactively choose higher risk profiles than would be acceptable for the Web PKI. But remaining trusted in the Web PKI means foregoing the economic incentives for these practices - in practice this will mean Visa gets itself needlessly into trouble, as happened for Issue C where Visa decided it had its own "exception policy" that allowed it to violate the root programme rules. CT: My understanding is that Mozilla intends for some future Firefox to do SCT checking as Chrome does already. It appears Visa either never or rarely logs certificates, so their sites (these names mostly belong to Visa, to subsidiary or related organisations) would fail these checks. It may be that if such SCT checks are in Firefox in the foreseeable future that has the effect that these certs cease to impact on Firefox at all. At which point, why would Mozilla keep Visa in the root trust programme ? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
