On 8/14/2020 2:38 PM, Matthias van de Meent via dev-security-policy wrote:
On Fri, 14 Aug 2020, 21:52 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:
It could raise legal issues for a CA to refuse to revoke an obvious
phishing domain after notice that it is fraudulent, or at least after
notice that it's actually being used to defraud.
For example, Calif. Penal Code s.530.5 says:
(d)(2) Every person who, with _actual knowledge_ that the personal
identifying information, as defined in subdivision (b) of Section
530.55, of a specific person will be used to commit a violation of
subsection (a), sells, transfers, _or conveys_ that same personal
identifying information is guilty of a public offense....
(emphasis added). Does a CA "convey[]" "personal identifying
information" if it leaves unrevoked, after notice, a certificate for a
domain that is being used to phish bank credentials?
Subdivision (a), in turn, makes it an public offense to "willfully
obtain[] personal identifying information, as defined in subdivision
(b) of Section 530.55, of another person, and use[] that information for
any unlawful purpose...". (This would seem to cover actual phishing of
bank credentials).
IANAL, but please note that you quote "personal identifying information [...]
of another person".
AIUI, to trigger clause (d)(2) for the CA, the phishing party would _at the
very least_ need to have obtained a valid certificate (and keypair, to use
this certificate) for a domain that they do not own / are authorized to
control (= PII of another person). ...
That is certainly a valid point, though I am arguing that the "personal
identifying information...of another person" here is the substance of
the domain name (usually the SLD). In my hypo, the phisher chooses the
SLD precisely because it's identical to the SLD that "the other person"
uses to conduct business, for the purpose of defrauding that person's
customers. As in the SLD of "bankofamerica.com" vs
"bankofamerica.someridiculousTLD".
It strikes me that there is also a cybersquatting issue here, but it's
been ages since I've looked at that.
-R
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy