Visa Issues

[Wayne Thayer]

Visa recently delivered new qualified audit reports for their eCommerce
Root that is included in the Mozilla program. I opened a bug [1] and
requested an incident report from Visa.

Visa was also the subject of a thread [2] earlier this year in which I
stated that I would look into some of the concerns that were raised. I've
done that and have compiled the following issues list:

https://wiki.mozilla.org/CA:Visa_Issues

While I have attempted to make this list as complete, accurate, and factual
as possible, it may be updated as more information is received from Visa
and the community.

I would like to request that a representative from Visa engage in this
discussion and provide responses to these issues.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/ns8UUwp8BgAJ

[Ryan Sleevi]

Compared to the seriousness and scope of these issues, this is by far a
minor correction, and does not undermine any of the evaluation. However, as
a pedantic note, it's noted as "PITRA" while stating "Point in Time audit".
A point-in-time readiness assessment is for management's eyes only, while
the report provided is just a Point in time Audit. I think just deleting
the parenthetical PITRA is sufficient and just consistently used Point in
Time audit.

[Wayne Thayer]

Good point Ryan. I've changed PITRA to "point-in-time audit" on this wiki
page. There is also an open issue to fix the references to PITRAs in the
Root Store Policy: https://github.com/mozilla/pkipolicy/issues/151

[Nick Lamb]

On Thu, 13 Sep 2018 12:26:55 -0700

Wayne Thayer via dev-security-policy
<dev-secur...@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 ?

[Ryan Sleevi]

On Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Visa recently delivered new qualified audit reports for their eCommerce
> Root that is included in the Mozilla program. I opened a bug [1] and
> requested an incident report from Visa.
>
> Visa was also the subject of a thread [2] earlier this year in which I
> stated that I would look into some of the concerns that were raised. I've
> done that and have compiled the following issues list:
>
> https://wiki.mozilla.org/CA:Visa_Issues
>
> While I have attempted to make this list as complete, accurate, and factual
> as possible, it may be updated as more information is received from Visa
> and the community.
>

> I would like to request that a representative from Visa engage in this
> discussion and provide responses to these issues.
>

> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851
> [2]
>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/ns8UUwp8BgAJ

I've not seen Visa engage in this discussion. The silence is rather
deafening, and arguably unacceptably so.

With respect to the Qualified Audit, Visa's response as to the substance of
the issue is particularly unsettling.
https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c3 demonstrates that
they've not actually remediated the qualification, that they've further
failed to meet the BRs requirements on revocations by any reasonable
perspective, and they don't even have a plan yet to remedy this issue.

Examining the bug itself is fairly disturbing, and the responses likely
reveal further BR violations. For example, the inability to obtain evidence
of domain validation information reveals that there are further issues with
2-7.3 - namely, maintaining those logs for 7 years. The response to 2-7.3
suggests that there are likely more endemic issues around the issuance.

Given the past issues, the recently identified issues (that appear to have
been longstanding), and the new issues that Visa's PKI Policy team is
actively engaging in, I believe it would be appropriate and necessary to
consider removing trust in this CA.

[Wayne Thayer]

Visa has filed a bug [1] requesting removal of the eCommerce root from the
Mozilla root store. Visa has also responded to the information requested in
the qualified audits bug [2], but it's unclear if or when they will respond
to the issues list presented in this thread. Two weeks have passed since I
posted the issues list, and I see no reason to delay the complete distrust
of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via
removal of the root from NSS version 3.40 . Visa is still welcome to
respond to the issues list, but I think the removal of Visa's only included
root, and thus Visa, from the Mozilla CA Certificate Program implies that
this discussion has reached a conclusion.

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1493822
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c2
[3] https://wiki.mozilla.org/Release_Management/Calendar

[Eric Mill]

On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Visa has filed a bug [1] requesting removal of the eCommerce root from the
> Mozilla root store. Visa has also responded to the information requested in
> the qualified audits bug [2], but it's unclear if or when they will respond
> to the issues list presented in this thread. Two weeks have passed since I
> posted the issues list, and I see no reason to delay the complete distrust
> of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via
> removal of the root from NSS version 3.40 . Visa is still welcome to
> respond to the issues list, but I think the removal of Visa's only included
> root, and thus Visa, from the Mozilla CA Certificate Program implies that
> this discussion has reached a conclusion.
>

Visa also stated in their removal bug:

"Visa’s plan is to remove the SHA1 root and introduce a new SHA2 and ECC
root."

Were Visa to apply to the Mozilla program with one or more new roots, would
those be new discussions, or would that cause this discussion about Visa's
history of issues to be re-opened?

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


--
konklone.com | @konklone <https://twitter.com/konklone>

[Wayne Thayer]

On Fri, Sep 28, 2018 at 12:29 PM Eric Mill <er...@konklone.com> wrote:

>
>
> On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Visa has filed a bug [1] requesting removal of the eCommerce root from the
>> Mozilla root store. Visa has also responded to the information requested
>> in
>> the qualified audits bug [2], but it's unclear if or when they will
>> respond
>> to the issues list presented in this thread. Two weeks have passed since I
>> posted the issues list, and I see no reason to delay the complete distrust
>> of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via
>> removal of the root from NSS version 3.40 . Visa is still welcome to
>> respond to the issues list, but I think the removal of Visa's only
>> included
>> root, and thus Visa, from the Mozilla CA Certificate Program implies that
>> this discussion has reached a conclusion.
>>
>
> Visa also stated in their removal bug:
>
> "Visa’s plan is to remove the SHA1 root and introduce a new SHA2 and ECC
> root."
>
> Were Visa to apply to the Mozilla program with one or more new roots,
> would those be new discussions, or would that cause this discussion about
> Visa's history of issues to be re-opened?
>

> It would be a new discussion in which I think it is safe to assume that
Visa's prior issues would be considered, as well as their response (if any)
to this discussion.