On 03/05/2017 17:45, Peter Kurrasch wrote:
Perhaps a different way to pose the questions here is whether Mozilla
wants to place any expectations on the CA's regarding fraud and the
prevention thereof. Expectations beyond what the BR's address, that is.
Some examples:
- Minimal expectation, meaning just satisfy whatever the BR's say but
beyond that Mozilla won't care(?)
- Passive involvement, meaning a CA is expected to do some investigation
into fraudulent activity but only when prompted and even then, no action
is necessarily expected
- Active involvement, meaning the CA has implemented policies and
procedures that identify and act on situations that appear fraudulent
A question one might ask is "What is reasonable?" It is not reasonable
for CA's to identify and prevent all cases of fraud so I wouldn't ask
that. I wouldn't call CA's the anti-fraud police, either. What about the
following:
- When a CA is notified that a stolen credit card was used to purchase
certs, should the CA investigate the subscriber who used it and any
other certs that were purchased (perhaps using a different CC) and take
appropriate action?
Generally, that is entirely an economic matter between the CA, the
subscriber and the credit card clearing house used by the CA. Most CAs
would probably revoke certificates if they suffer a chargeback,
regardless if the CC was stolen or not.
There are common best security practices that frequently prevent CAs
from actually knowing the CC numbers used by subscribers to purchase
certificates.
- Is it reasonable for any subscriber to request more than 100 certs on
a given day? What about 500? 1000? (The point is not to prohibit large
requests but I would imagine there is a level which exceeds what anyone
might consider a legitimate use case.)
Mass orders from someone who hasn't placed such orders before should be
subject to extra scrutiny as to what is going on (e.g. did we just win
a major legitimate customer from the competition?, is this a new CDN /
hosting provider with overnight success?, is there some other good
reason?). But this may or may not be an area that Mozilla or the BRs
should set a policy for.
- Is is reasonable for a single CA to issue over 150 certs containing
"paypal" in the domain name? (I am referring to the analysis Vincent
Lynch did back in March.) There are undoubtedly cases where including
"paypal" in the name is or could be legitimate, but 150 a day, every day?
I believe this falls under the existing "High Risk Certificate
Requests" BR.
- Is it reasonable for a CA to issue a cert to the CIA for Yandex or to
the Chinese government for Facebook, even if the requester does
demonstrate "sufficient control" of the domain?
Ditto.
The point I wish to make is that situations will come up that go beyond
anything in the BR's and that reasonable people might agree go beyond a
reasonable level of reasonableness. The question becomes what will
Mozilla do as those situations arise? Can Mozilla envision possibly
asking a CA "don't you think you should have limited <whatever>?"
Here is something that might be added to Mozilla Policy in lieu of
being a BR:
The criteria used by a CA to identify "High Risk Certificate Requests"
as defined by BR 1.6.1 and referenced in BR 4.2.1 shall, at a minimum
include at least, but not only, the following:
- All of the items enumerated in the BR definition of "High Risk
Certificate Request" in BR 1.6.1, even though they may be optional in
the current BRs.
- The Alexa top 1000 unique base domain names, (e.g. if www.mozilla.com
and www.mozilla.org are both in the Alexa top list, they count as only
1 when counting towards the 1000).
- The Following core Internet operational base domain names: iana,
ietf, rfc-editor, internic, icann, example, invalid, root-servers,
gtld-servers, arpa.
- The primary base domain names of all CAB/F members (including mozilla
and google).
- The base domain names of all domains operated or "owned" by the CA
itself.
- The following names that tend to indicate high value subdomain
hierarchies: gov, com, org, co, ac.
- Anything containing the substring "bank".
- Any IDN domain names whose rendering using any of the well known
standard fonts: "Times Roman", "Courier", "Helvetica", "Arial" is
visually very close to any string of ASCII-only graphical characters.
(It is noted, that this criteria can generally be checked by
compiling a list of UNICODE code points and sequences thereof having
this property on their own, then flagging any IDN name containing only
ASCII plus such sequences).
- Any all-ASCII domain name containing the characters ("1", "L", "i"),
("0", or "o") when a different entity controls the existing domain
formed by interchanging those with others from the same of the two
subsets.
For example, an application for the domain exampie.com is high risk
from an entity other than the entity controlling exampLe.com. And
vice versa.
Note that "High Risk Certificate Requests" can still be fulfilled,
they just require extra checks of their legitimacy, as per BR 4.2.1.
*From: *Gervase Markham
*Sent: *Tuesday, May 2, 2017 5:46 AM
*To: *Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
*Subject: *Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"
On 02/05/17 01:55, Peter Kurrasch wrote:
I was thinking that fraud takes many forms generally speaking and that
the PKI space is no different. Given that Mozilla (and everyone else)
work very hard to preserve the integrity of the global PKI and that the
PKI itself is an important tool to fighting fraud on the Internet, it
seems to me like it would be a missed opportunity if the policy doc made
no mention of fraud.
Some fraud scenarios that come to mind:
- false representation as a requestor
- payment for cert services using a stolen credit card number
- malfeasance on the part of the cert issuer
Clearly, we have rules for vetting (in particular, EV) which try and
avoid such things happening. It's not like we are indifferent. But
stolen CC numbers, for example, are a factor for which each CA has to
put in place whatever measures they feel appropriate, just as any
business does. It's not really our concern.
- requesting and obtaining certs for the furtherance of fraudulent
activity
Regarding that last item, I understand there is much controversy over
the prevention and remediation of that behavior but I would hope there
is widespread agreement that it does at least exist.
It exists, in the same way that cars are used for bank robbery getaways,
but the Highway Code doesn't mention bank robberies.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
