Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

Section 7.1 of the policy says that we reserve the right not to include
certificates from a CA which has:

"knowingly issue certificates that appear to be intended for fraudulent
use."

There are a few problems with this.

* It's only in the inclusion section.
* It's really subjective - how could you prove a CA "knowingly" did this?

How can a CA tell a certificate "appears to be intended for fraudulent
use"? As bad actors don't set the "evil bit", the only way I can think
of that a CA might do this check is by looking at the domain name and
checking to see if it's anything like a "famous" brand. But Mozilla has
taken the position that we don't believe it's the responsibility of CAs
to police the domain name space.

We already have the power to chuck out misbehaving CAs, or not include
ones which are dodgy; we don't need this clause for that either.

So I propose removing it, and reformatting the section accordingly.

This is: https://github.com/mozilla/pkipolicy/issues/2

-------

This is a proposed update to Mozilla's root store policy for version
2.5. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.4.1 (current version):
https://github.com/mozilla/pkipolicy/blob/2.4.1/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
0
Gervase
4/20/2017 1:39:12 PM
mozilla.dev.security.policy 1157 articles. 1 followers. Post Follow

10 Replies
91 Views

Similar Articles

[PageSpeed] 59

On 20/04/17 14:39, Gervase Markham wrote:
> So I propose removing it, and reformatting the section accordingly.

Edit made as proposed.

Gerv

0
Gervase
5/1/2017 8:36:03 AM
Gerv, does this leave the Mozilla policy with no position statement regardi=
ng fraud in the global PKI?


=A0 Original Message =A0
From: Gervase Markham via dev-security-policy
Sent: Monday, May 1, 2017 3:36 AM
To: mozilla-dev-security-policy@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use"

On 20/04/17 14:39, Gervase Markham wrote:
> So I propose removing it, and reformatting the section accordingly.

Edit made as proposed.

Gerv

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
0
Peter
5/1/2017 3:28:00 PM
On 01/05/17 16:28, Peter Kurrasch wrote:
> Gerv, does this leave the Mozilla policy with no position statement regarding fraud in the global PKI?

What do you mean by "in"?

Gerv
0
Gervase
5/1/2017 3:49:41 PM
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">I was thinking that fraud takes many forms generally speaking a=
nd that the PKI space is no different. Given that Mozilla (and everyone els=
e) 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 ment=
ion of fraud.</div><div style=3D"width: 100%; font-size: initial; font-fami=
ly: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); =
text-align: initial; background-color: rgb(255, 255, 255);"><br></div><div =
style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro'=
, sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; bac=
kground-color: rgb(255, 255, 255);">Some fraud scenarios that come to mind:=
</div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, =
'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: i=
nitial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"widt=
h: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif,=
 sans-serif; color: rgb(31, 73, 125); text-align: initial; background-color=
: rgb(255, 255, 255);">- false representation as a requestor</div><div styl=
e=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);">- payment for cert services using a stolen =
credit card number</div><div style=3D"width: 100%; font-size: initial; font=
-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 1=
25); text-align: initial; background-color: rgb(255, 255, 255);">- malfeasa=
nce on the part of the cert issuer</div><div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);">- requesting and obtaining certs for the furtherance of fraudulent ac=
tivity</div><div style=3D"width: 100%; font-size: initial; font-family: Cal=
ibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-al=
ign: initial; background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);">Regarding that last item, I understand there=
 is much controversy over the prevention and remediation of that behavior b=
ut I would hope there is widespread agreement that it does at least exist.<=
/div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, '=
Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: in=
itial; background-color: rgb(255, 255, 255);"><span style=3D"font-size: ini=
tial; line-height: initial; text-align: initial;"><br></span></div><div sty=
le=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', s=
ans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgr=
ound-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; line-he=
ight: initial; text-align: initial;"><br></span></div>                     =
                                                                           =
                                     <div style=3D"width: 100%; font-size: =
initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: =
rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255)=
;"><br style=3D"display:initial"></div>                                    =
                                                                           =
                                                                           =
         <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro=
', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; ba=
ckground-color: rgb(255, 255, 255);"></div>                                =
                                                                           =
                                                                       <tab=
le width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tb=
ody><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial;=
 background-color: rgb(255, 255, 255);">                           <div sty=
le=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223); =
border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha=
 Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Gervase Markham<=
/div><div><b>Sent: </b>Monday, May 1, 2017 10:49 AM</div><div><b>To: </b>Pe=
ter Kurrasch; mozilla-dev-security-policy@lists.mozilla.org</div><div><b>Su=
bject: </b>Re: Policy 2.5 Proposal: Remove the bullet about "fraudulent use=
"</div></div></td></tr></tbody></table><div style=3D"border-style: solid no=
ne none; border-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-=
size: initial; text-align: initial; background-color: rgb(255, 255, 255);">=
</div><br><div id=3D"_originalContent" style=3D"">On 01/05/17 16:28, Peter =
Kurrasch wrote:<br>&gt; Gerv, does this leave the Mozilla policy with no po=
sition statement regarding fraud in the global PKI?<br><br>What do you mean=
 by "in"?<br><br>Gerv<br></div></body></html>
0
Peter
5/2/2017 12:55:35 AM
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.

Gerv
0
Gervase
5/2/2017 10:46:40 AM
On 02/05/2017 12:46, Gervase Markham wrote:
> 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.
>
> Gerv
>

However a highway code may mention the authority of the highway police
to establish roadblocks and stop vehicles in relation to general
criminal issues.  (But it is obviously not against any law for the
police to not establish roadblocks and vehicle searches for every bank
robbery ever committed, just as there is no requirements for CAs to
revoke certificates for every allegedly fraudulent use possible).


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
0
Jakob
5/3/2017 2:17:17 AM
dGhhbmtzDQoNCg0K5Y+R6Ieq572R5piT6YKu566x5aSn5biIDQoNCg0K5ZyoMjAxN+W5tDA15pyI
MDPml6UgMTA6MTXvvIxKYWtvYiBCb2htIHZpYSBkZXYtc2VjdXJpdHktcG9saWN5IOWGmemBk++8
mg0KT24gMDIvMDUvMjAxNyAxMjo0NiwgR2VydmFzZSBNYXJraGFtIHdyb3RlOg0KPiBPbiAwMi8w
NS8xNyAwMTo1NSwgUGV0ZXIgS3VycmFzY2ggd3JvdGU6DQo+PiBJIHdhcyB0aGlua2luZyB0aGF0
IGZyYXVkIHRha2VzIG1hbnkgZm9ybXMgZ2VuZXJhbGx5IHNwZWFraW5nIGFuZCB0aGF0DQo+PiB0
aGUgUEtJIHNwYWNlIGlzIG5vIGRpZmZlcmVudC4gR2l2ZW4gdGhhdCBNb3ppbGxhIChhbmQgZXZl
cnlvbmUgZWxzZSkNCj4+IHdvcmsgdmVyeSBoYXJkIHRvIHByZXNlcnZlIHRoZSBpbnRlZ3JpdHkg
b2YgdGhlIGdsb2JhbCBQS0kgYW5kIHRoYXQgdGhlDQo+PiBQS0kgaXRzZWxmIGlzIGFuIGltcG9y
dGFudCB0b29sIHRvIGZpZ2h0aW5nIGZyYXVkIG9uIHRoZSBJbnRlcm5ldCwgaXQNCj4+IHNlZW1z
IHRvIG1lIGxpa2UgaXQgd291bGQgYmUgYSBtaXNzZWQgb3Bwb3J0dW5pdHkgaWYgdGhlIHBvbGlj
eSBkb2MgbWFkZQ0KPj4gbm8gbWVudGlvbiBvZiBmcmF1ZC4NCj4+DQo+PiBTb21lIGZyYXVkIHNj
ZW5hcmlvcyB0aGF0IGNvbWUgdG8gbWluZDoNCj4+DQo+PiAtIGZhbHNlIHJlcHJlc2VudGF0aW9u
IGFzIGEgcmVxdWVzdG9yDQo+PiAtIHBheW1lbnQgZm9yIGNlcnQgc2VydmljZXMgdXNpbmcgYSBz
dG9sZW4gY3JlZGl0IGNhcmQgbnVtYmVyDQo+PiAtIG1hbGZlYXNhbmNlIG9uIHRoZSBwYXJ0IG9m
IHRoZSBjZXJ0IGlzc3Vlcg0KPg0KPiBDbGVhcmx5LCB3ZSBoYXZlIHJ1bGVzIGZvciB2ZXR0aW5n
IChpbiBwYXJ0aWN1bGFyLCBFVikgd2hpY2ggdHJ5IGFuZA0KPiBhdm9pZCBzdWNoIHRoaW5ncyBo
YXBwZW5pbmcuIEl0J3Mgbm90IGxpa2Ugd2UgYXJlIGluZGlmZmVyZW50LiBCdXQNCj4gc3RvbGVu
IENDIG51bWJlcnMsIGZvciBleGFtcGxlLCBhcmUgYSBmYWN0b3IgZm9yIHdoaWNoIGVhY2ggQ0Eg
aGFzIHRvDQo+IHB1dCBpbiBwbGFjZSB3aGF0ZXZlciBtZWFzdXJlcyB0aGV5IGZlZWwgYXBwcm9w
cmlhdGUsIGp1c3QgYXMgYW55DQo+IGJ1c2luZXNzIGRvZXMuIEl0J3Mgbm90IHJlYWxseSBvdXIg
Y29uY2Vybi4NCj4NCj4+IC0gcmVxdWVzdGluZyBhbmQgb2J0YWluaW5nIGNlcnRzIGZvciB0aGUg
ZnVydGhlcmFuY2Ugb2YgZnJhdWR1bGVudCBhY3Rpdml0eQ0KPj4NCj4+IFJlZ2FyZGluZyB0aGF0
IGxhc3QgaXRlbSwgSSB1bmRlcnN0YW5kIHRoZXJlIGlzIG11Y2ggY29udHJvdmVyc3kgb3Zlcg0K
Pj4gdGhlIHByZXZlbnRpb24gYW5kIHJlbWVkaWF0aW9uIG9mIHRoYXQgYmVoYXZpb3IgYnV0IEkg
d291bGQgaG9wZSB0aGVyZQ0KPj4gaXMgd2lkZXNwcmVhZCBhZ3JlZW1lbnQgdGhhdCBpdCBkb2Vz
IGF0IGxlYXN0IGV4aXN0Lg0KPg0KPiBJdCBleGlzdHMsIGluIHRoZSBzYW1lIHdheSB0aGF0IGNh
cnMgYXJlIHVzZWQgZm9yIGJhbmsgcm9iYmVyeSBnZXRhd2F5cywNCj4gYnV0IHRoZSBIaWdod2F5
IENvZGUgZG9lc24ndCBtZW50aW9uIGJhbmsgcm9iYmVyaWVzLg0KPg0KPiBHZXJ2DQo+DQoNCkhv
d2V2ZXIgYSBoaWdod2F5IGNvZGUgbWF5IG1lbnRpb24gdGhlIGF1dGhvcml0eSBvZiB0aGUgaGln
aHdheSBwb2xpY2UNCnRvIGVzdGFibGlzaCByb2FkYmxvY2tzIGFuZCBzdG9wIHZlaGljbGVzIGlu
IHJlbGF0aW9uIHRvIGdlbmVyYWwNCmNyaW1pbmFsIGlzc3Vlcy4gIChCdXQgaXQgaXMgb2J2aW91
c2x5IG5vdCBhZ2FpbnN0IGFueSBsYXcgZm9yIHRoZQ0KcG9saWNlIHRvIG5vdCBlc3RhYmxpc2gg
cm9hZGJsb2NrcyBhbmQgdmVoaWNsZSBzZWFyY2hlcyBmb3IgZXZlcnkgYmFuaw0Kcm9iYmVyeSBl
dmVyIGNvbW1pdHRlZCwganVzdCBhcyB0aGVyZSBpcyBubyByZXF1aXJlbWVudHMgZm9yIENBcyB0
bw0KcmV2b2tlIGNlcnRpZmljYXRlcyBmb3IgZXZlcnkgYWxsZWdlZGx5IGZyYXVkdWxlbnQgdXNl
IHBvc3NpYmxlKS4NCg0KDQpFbmpveQ0KDQpKYWtvYg0KLS0NCkpha29iIEJvaG0sIENJTywgUGFy
dG5lciwgV2lzZU1vIEEvUy4gIGh0dHBzOi8vd3d3Lndpc2Vtby5jb20NClRyYW5zZm9ybWVydmVq
IDI5LCAyODYwIFPDuGJvcmcsIERlbm1hcmsuICBEaXJlY3QgKzQ1IDMxIDEzIDE2IDEwDQpUaGlz
IHB1YmxpYyBkaXNjdXNzaW9uIG1lc3NhZ2UgaXMgbm9uLWJpbmRpbmcgYW5kIG1heSBjb250YWlu
IGVycm9ycy4NCldpc2VNbyAtIFJlbW90ZSBTZXJ2aWNlIE1hbmFnZW1lbnQgZm9yIFBDcywgUGhv
bmVzIGFuZCBFbWJlZGRlZA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCmRldi1zZWN1cml0eS1wb2xpY3kgbWFpbGluZyBsaXN0DQpkZXYtc2VjdXJpdHkt
cG9saWN5QGxpc3RzLm1vemlsbGEub3JnDQpodHRwczovL2xpc3RzLm1vemlsbGEub3JnL2xpc3Rp
bmZvL2Rldi1zZWN1cml0eS1wb2xpY3kNCg==
0
utf
5/3/2017 3:38:37 AM
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Perhaps a different way to pose the questions here is whether M=
ozilla wants to place any expectations on the CA's regarding fraud and the =
prevention thereof. Expectations beyond what the BR's address, that is. Som=
e examples:</div><div style=3D"width: 100%; font-size: initial; font-family=
: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); te=
xt-align: initial; background-color: rgb(255, 255, 255);"><br></div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);">=E2=80=8E- Minimal expectation, meaning j=
ust satisfy whatever the BR's say but beyond that Mozilla won't care(?)</di=
v><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sla=
te Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initi=
al; background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 1=
00%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, san=
s-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rg=
b(255, 255, 255);">- Passive involvement, meaning a CA is expected to do so=
me investigation into fraudulent activity but only when prompted and even t=
hen, no action is necessarily expected</div><div style=3D"width: 100%; font=
-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; =
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 25=
5, 255);"><br></div><div style=3D"width: 100%; font-size: initial; font-fam=
ily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125);=
 text-align: initial; background-color: rgb(255, 255, 255);">- Active invol=
vement, meaning the CA has implemented policies and procedures that identif=
y and act on situations that appear fraudulent</div><div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial; =
font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 7=
3, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></=
div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'S=
late Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: ini=
tial; background-color: rgb(255, 255, 255);">A question one might ask is "W=
hat is reasonable?" It is not reasonable for CA's to identify and prevent a=
ll cases of fraud so I wouldn't ask that. I wouldn't call CA's the anti-fra=
ud police, either. What about the following:</div><div style=3D"width: 100%=
; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-s=
erif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(2=
55, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial; fo=
nt-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73,=
 125); text-align: initial; background-color: rgb(255, 255, 255);">- When a=
 CA is notified that a stolen credit card was used to purchase certs, shoul=
d the CA investigate the subscriber who used it and any other certs that we=
re purchased (perhaps using a different CC) and take appropriate action?</d=
iv><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sl=
ate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);">- Is it reasonable for any subscriber to request more t=
han 100 certs on a given day? What about 500? 1000? (The point is not to pr=
ohibit large requests but I would imagine there is a level which exceeds wh=
at anyone might consider a legitimate use case.)</div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial=
; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31,=
 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">- 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?</div><div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
>- Is it reasonable for a CA to issue a cert to the CIA for Yandex or to th=
e Chinese government for Facebook, even if the requester does demonstrate "=
sufficient control" of the domain?</div><div style=3D"width: 100%; font-siz=
e: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; colo=
r: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 2=
55);"><br></div><div style=3D"width: 100%; font-size: initial; font-family:=
 Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); tex=
t-align: initial; background-color: rgb(255, 255, 255);"><br></div><div sty=
le=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', s=
ans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgr=
ound-color: rgb(255, 255, 255);">The point I wish to make is that situation=
s will come up that go beyond anything in the BR's and that reasonable peop=
le might agree go =E2=80=8Ebeyond a reasonable level of reasonableness. The=
 question becomes what will Mozilla do as those situations arise? Can Mozil=
la envision possibly asking a CA "don't you think you should have limited &=
lt;whatever&gt;?"</div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);"><span style=
=3D"font-size: initial; line-height: initial; text-align: initial;"><br></s=
pan></div>                                                                 =
                                                                    <div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);"><br style=3D"display:initial"></div>     =
                                                                           =
                                                                           =
                                        <div style=3D"font-size: initial; f=
ont-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial; background-color: rgb(255, 255, 255);"></div> =
                                                                           =
                                                                           =
                           <table width=3D"100%" style=3D"background-color:=
white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size=
: initial; text-align: initial; background-color: rgb(255, 255, 255);">    =
                       <div style=3D"border-style: solid none none; border-=
top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in;=
 font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <di=
v><b>From: </b>Gervase Markham</div><div><b>Sent: </b>Tuesday, May 2, 2017 =
5:46 AM</div><div><b>To: </b>Peter Kurrasch; mozilla-dev-security-policy@li=
sts.mozilla.org</div><div><b>Subject: </b>Re: Policy 2.5 Proposal: Remove t=
he bullet about "fraudulent use"</div></div></td></tr></tbody></table><div =
style=3D"border-style: solid none none; border-top-color: rgb(186, 188, 209=
); border-top-width: 1pt; font-size: initial; text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalContent" style=
=3D"">On 02/05/17 01:55, Peter Kurrasch wrote:<br>&gt; I was thinking that =
fraud takes many forms generally speaking and that<br>&gt; the PKI space is=
 no different. Given that Mozilla (and everyone else)<br>&gt; work very har=
d to preserve the integrity of the global PKI and that the<br>&gt; PKI itse=
lf is an important tool to fighting fraud on the Internet, it<br>&gt; seems=
 to me like it would be a missed opportunity if the policy doc made<br>&gt;=
 no mention of fraud.<br>&gt; <br>&gt; Some fraud scenarios that come to mi=
nd:<br>&gt; <br>&gt; - false representation as a requestor<br>&gt; - paymen=
t for cert services using a stolen credit card number<br>&gt; - malfeasance=
 on the part of the cert issuer<br><br>Clearly, we have rules for vetting (=
in particular, EV) which try and<br>avoid such things happening. It's not l=
ike we are indifferent. But<br>stolen CC numbers, for example, are a factor=
 for which each CA has to<br>put in place whatever measures they feel appro=
priate, just as any<br>business does. It's not really our concern.<br><br>&=
gt; - requesting and obtaining certs for the furtherance of fraudulent acti=
vity<br>&gt; <br>&gt; Regarding that last item, I understand there is much =
controversy over<br>&gt; the prevention and remediation of that behavior bu=
t I would hope there<br>&gt; is widespread agreement that it does at least =
exist.<br><br>It exists, in the same way that cars are used for bank robber=
y getaways,<br>but the Highway Code doesn't mention bank robberies.<br><br>=
Gerv<br></div><br><br></body></html>
0
Peter
5/3/2017 3:45:38 PM
On 03/05/17 16: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.

You need to be more specific, because there are lots of different ways a
system can have "fraud" and our attitude to different ones might be
different. We are not the police.

> - 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?

I'd say this is none of our business, unless the certs are mis-issued.

> - 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.)

I suspect some CAs will tell you that they have customers such as cloud
providers who require a very large number of certs per day. And this
also seems to be entirely outside our interest.

> - 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?

If we have decided that CAs are not "name cops", then I don't want to
reintroduce an expectation that they are by the back door.

> - 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?

I suspect that if the Chinese government were attempting to get a cert
for Facebook mis-issued to themselves, they would not identify
themselves as the Chinese government. We care about the above as a
mis-issuance, just like any other.

Gerv

0
Gervase
5/3/2017 4:27:49 PM
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-policy@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
0
Jakob
5/4/2017 5:11:46 PM
Reply: