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
