Re: Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-03 Thread Nick Lamb via dev-security-policy
On Monday, 1 May 2017 22:02:58 UTC+1, Lee  wrote:
> Maybe it's because I've worked with some incredibly bad auditors, but
> the way I read the proposal, doing anything other than one of those
> exact 10 methods is risking an audit failure.

> How would you word the policy to make it clear that while a CA is
> required to use one of those 10 methods, the CA is also allowed to do
> additional/stricter checks?

I don't think it's necessary to spell out that a CA can do additional checks. 
The CA can also own a pizzeria, or teach all its employees to dance, and the 
policy rightly says nothing about that.

On the other hand, whether other checks are "stricter" may be in the eye of the 
beholder. If they comply exactly with the relevant section of 3.2.2.4 then we 
know we're happy, otherwise who knows?

Consider 3.2.2.4.6, a 112-bit random token chosen by a CA employee rolling a 
bunch of fair hexadecimal dice and writing down what they got is fine for 
passing 3.2.2.4.6. If a CA wishes to instead use UUIDs (assuming they have a 
good quality random number generator spitting out version 4 random UUIDs) 
that's fine too.

Arguably implementing ACME http-01 validation is better, because that binds the 
validation to the applicant, closing a hole often found in validations today. 
But regardless of whether you think that's important, http-01 complies with 
3.2.2.4.6 as well, aspects of 3.2.2.4.6 were actually modelled on it.

On the other hand, maybe a CA comes up with something quite different, maybe 
they want to validate web sites by having a path famous-ca-name/validation.dll 
and they pass in an XML input which the remote server needs to process and 
respond to. What we do NOT want in this policy is to either make it Mozilla's 
job to examine every such new method and figure out if it's safe, or to just 
let the CA vouch for it as being "stricter" on their say so.

Although we have occasionally caught CAs just straight up lying, much more 
often the problem is _incompetence_. The people running a CA are not experts on 
this stuff, so when they invent a new method there's a good chance it's flawed 
not because they intentionally designed in a weakness but because they lack the 
skills internally to identify a risk, and because they have no public review 
process by which others might spot it for them. So Ballot 169 (and this Mozilla 
policy) eliminate the problem by telling them not to roll their own.

There will still probably be implementation flaws, that can't be entirely 
prevented, but I believe this (whether as Mozilla policy) or in the BRs 
represents a step firmly in the right direction.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Policy 2.5 Proposal: Indicate direction of travel with respect to permitted domain validation methods

2017-05-03 Thread Han Yuwei via dev-security-policy
A question:How would a domain holder express denial for certain certificate 
requests?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Symantec: Draft Proposal

2017-05-03 Thread Han Yuwei via dev-security-policy
So Mozilla think Symantec's issues are on t serious enough to lose trust 
entirely?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Changing CCADB domains

2017-05-03 Thread Nick Lamb via dev-security-policy
Thanks for your notice Kathleen.

One thought: Very often several CAs ask for more time to complete the Mozilla 
survey, either explicitly, or implicitly by just not filling it out in a timely 
fashion and saying they're very busy and will do it "soon" if they're asked.

If you believe there are, or are likely to be, CAs trying to fill out the 
survey a bit late, it may make sense to wait for that before triggering this 
change, so as to avoid the (it seems almost inevitable) response that they 
tried to do the survey but they were using the old link and it didn't work...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


RE: StartCom continues to sell untrusted certificates

2017-05-03 Thread Inigo Barreira via dev-security-policy
Yes, thank you for letting us know.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Lewis Resmond via dev-security-policy
Sent: miércoles, 3 de mayo de 2017 19:49
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom continues to sell untrusted certificates

Am Montag, 1. Mai 2017 16:49:32 UTC+2 schrieb Henri Sivonen:
> On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > On 01/05/17 07:52, Percy wrote:
> >> It seems that StartCom continues to sell untrusted certs. Neither 
> >> their
> home page https://www.startcomca.com/ nor their announcement page 
> https://www.startcomca.com/index/news mentions that those certs are 
> not trusted.
> >
> > Why is this something that Mozilla should be concerned with?
> >
> > "Selling untrusted certs" is not a crime, or a violation of any 
> > standard. Mozilla is not the global authority on what certificates 
> > may be issued. If StartCom are providing certificates which do not 
> > do what their customers expect, I'm sure those customers will let 
> > them know about it soon enough.
> 
> What StartCom claims about compatibility is potentially more 
> Mozilla-relevant than what they are silent about. At the bottom of 
> their front page, it says "StartCom™ / StartSSL™is supported by:" 
> followed by icons. The icons include an early icon for Camino and the 
> SeaMonkey icon.
> Since Camino was discontinued before Mozilla's change in trust in 
> StartCom certificates, I guess having Camino there isn't technically 
> incorrect, but is about as relevant as having the Flock icon there. 
> However, is it correct to have the SeaMonkey icon there? The latest 
> SeaMonkey release seems to post-date the Mozilla root program's trust change 
> in StartCom certificates.
> (But then, it seems that there have been a number of Firefox ESR 
> security patch releases that post-date the SeaMonkey release. Is 
> SeaMonkey still active, despite appearing not to ship Gecko security 
> updates, and does SeaMonkey implement the same trust special-casing as 
> Firefox? It seems to produce nightlies still.)
> 
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/

It seems like they have removed the icons.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Changing CCADB domains

2017-05-03 Thread Kathleen Wilson via dev-security-policy
All,

I think it is time for us to change the domains that we are using for the CCADB 
as follows.

Change the links for...

1)  CAs to login to the CCADB
from
https://mozillacacommunity.force.com/
to
https://ccadb.force.com/

2) all published reports
from
https://mozillacaprogram.secure.force.com/
to
https://ccadb.secure.force.com/


We asked Salesforce for a temporary redirect from the old to the new URLs, but 
that was declined because we're not paying for premium support for the CCADB. 
(Other than this change, I do not currently see the need for us to pay for 
premium support.)

So, when we make this change, it will be a breaking change for everyone using 
the current links.

To make this change happen, we will file a Salesforce bug and request that the 
change happen on a certain date, within a certain 24 hour window. So, we're 
planning to request that this change happen on a Friday.

I would send an email via the CCADB to all included CAs before and after the 
change.

I would also need to update all of Mozilla's wiki pages that have these links. 
i.e. all the wiki pages with instructions about CA login, public-facing 
reports, and the CA Communication responses.

I suspect this change will also impact crt.sh.

Is there anything that I have missed in regards to what will be impacted when 
we make this change?

Does anyone have concerns or feedback on this?

Cheers,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: StartCom continues to sell untrusted certificates

2017-05-03 Thread Lewis Resmond via dev-security-policy
Am Montag, 1. Mai 2017 16:49:32 UTC+2 schrieb Henri Sivonen:
> On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > On 01/05/17 07:52, Percy wrote:
> >> It seems that StartCom continues to sell untrusted certs. Neither their
> home page https://www.startcomca.com/ nor their announcement page
> https://www.startcomca.com/index/news mentions that those certs are not
> trusted.
> >
> > Why is this something that Mozilla should be concerned with?
> >
> > "Selling untrusted certs" is not a crime, or a violation of any
> > standard. Mozilla is not the global authority on what certificates may
> > be issued. If StartCom are providing certificates which do not do what
> > their customers expect, I'm sure those customers will let them know
> > about it soon enough.
> 
> What StartCom claims about compatibility is potentially more
> Mozilla-relevant than what they are silent about. At the bottom of their
> front page, it says "StartCom™ / StartSSL™is supported by:" followed by
> icons. The icons include an early icon for Camino and the SeaMonkey icon.
> Since Camino was discontinued before Mozilla's change in trust in StartCom
> certificates, I guess having Camino there isn't technically incorrect, but
> is about as relevant as having the Flock icon there. However, is it correct
> to have the SeaMonkey icon there? The latest SeaMonkey release seems to
> post-date the Mozilla root program's trust change in StartCom certificates.
> (But then, it seems that there have been a number of Firefox ESR security
> patch releases that post-date the SeaMonkey release. Is SeaMonkey still
> active, despite appearing not to ship Gecko security updates, and does
> SeaMonkey implement the same trust special-casing as Firefox? It seems to
> produce nightlies still.)
> 
> -- 
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/

It seems like they have removed the icons.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: StartCom continues to sell untrusted certificates

2017-05-03 Thread Percy via dev-security-policy
On Monday, May 1, 2017 at 7:49:32 AM UTC-7, Henri Sivonen wrote:
> On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > On 01/05/17 07:52, Percy wrote:
> >> It seems that StartCom continues to sell untrusted certs. Neither their
> home page https://www.startcomca.com/ nor their announcement page
> https://www.startcomca.com/index/news mentions that those certs are not
> trusted.
> >
> > Why is this something that Mozilla should be concerned with?
> >
> > "Selling untrusted certs" is not a crime, or a violation of any
> > standard. Mozilla is not the global authority on what certificates may
> > be issued. If StartCom are providing certificates which do not do what
> > their customers expect, I'm sure those customers will let them know
> > about it soon enough.
> 
> What StartCom claims about compatibility is potentially more
> Mozilla-relevant than what they are silent about. At the bottom of their
> front page, it says "StartCom™ / StartSSL™is supported by:" followed by
> icons. The icons include an early icon for Camino and the SeaMonkey icon.
> Since Camino was discontinued before Mozilla's change in trust in StartCom
> certificates, I guess having Camino there isn't technically incorrect, but
> is about as relevant as having the Flock icon there. However, is it correct
> to have the SeaMonkey icon there? The latest SeaMonkey release seems to
> post-date the Mozilla root program's trust change in StartCom certificates.
> (But then, it seems that there have been a number of Firefox ESR security
> patch releases that post-date the SeaMonkey release. Is SeaMonkey still
> active, despite appearing not to ship Gecko security updates, and does
> SeaMonkey implement the same trust special-casing as Firefox? It seems to
> produce nightlies still.)
> 
> -- 
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/

Ha, it seems that they removed those icons in response to your comments. Now 
they only list Edge, IE, Android and windows.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

2017-05-03 Thread Gervase Markham via dev-security-policy
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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

2017-05-03 Thread Peter Kurrasch via dev-security-policy
  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 fraudulentA 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?- 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.)- 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?- 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?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 ?"From: Gervase MarkhamSent: Tuesday, May 2, 2017 5:46 AMTo: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.orgSubject: 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 issuerClearly, we have rules for vetting (in particular, EV) which try andavoid such things happening. It's not like we are indifferent. Butstolen CC numbers, for example, are a factor for which each CA has toput in place whatever measures they feel appropriate, just as anybusiness 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Cert pinning mismatch investigation

2017-05-03 Thread Nick Lamb via dev-security-policy
On Tuesday, 2 May 2017 14:52:52 UTC+1, Gervase Markham  wrote:
> Group participants may be interested in David Keeler's analysis of why
> Firefox seemed to be seeing cert pinning mismatches for Mozilla properties:
> https://people-mozilla.org/~dkeeler/deployment-checker-analysis.html

Indeed, that was interesting. In respect of "stale DNS" I will suggest an 
alternate explanation that seems plausible for the relatively small volumes 
involved - /etc/hosts and its moral equivalents on other systems are often 
changed in order to troubleshoot something and then simply never put back how 
they were originally. So a correct (at the time) address might be copied into a 
hosts file while trying to fix some issue such as DNS or connectivity problems, 
and then simply never removed (after all it still works ... for now)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy