Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

I would like to open a discussion about the criteria by which Mozilla
decides which CAs we should allow to apply for inclusion in our root store.

Section 2.1 of Mozilla’s current Root Store Policy states:

CAs whose certificates are included in Mozilla's root program MUST:
> 1.provide some service relevant to typical users of our software
> products;
>

Further non-normative guidance for which organizations may apply to the CA
program is documented in the ‘Who May Apply’ section of the application
process at https://wiki.mozilla.org/CA/Application_Process . The original
intent of this provision in the policy and the guidance was to discourage a
large number of organizations from applying to the program solely for the
purpose of avoiding the difficulties of distributing private roots for
their own internal use.

Recently, we’ve encountered a number of examples that cause us to question
the usefulness of the currently-vague statement(s) we have that define
which CAs to accept, along a number of different axes:

* Visa is a current program member that has an open request to add another
root. They only issue a relatively small number of certificates per year to
partners and for internal use. They do not offer certificates to the
general public or to anyone with whom they do not have an existing business
relationship.

* Google is also a current program member, admitted via the acquisition of
an existing root, but does not currently, to the best of our knowledge,
meet the existing inclusion criteria, even though it is conceivable that
they would issue certificates to the public in the future.

* There are potential applicants for CA status who deploy a large number of
certificates, but only on their own infrastructure and for their own
domains, albeit that this infrastructure is public-facing rather than
company-internal.

* We have numerous government CAs in the program or in the inclusion
process that only intend to issue certificates to their own institutions.

* We have at least one CA applying for the program that (at least, it has
been reported in the press) is controlled by an entity which may wish to
use it for MITM.

There are many potential options for resolving this issue. Ideally, we
would like to establish some objective criteria that can be measured and
applied fairly. It’s possible that this could require us to define
different categories of CAs, each with different inclusion criteria. Or it
could be that we should remove the existing ‘relevance’ requirement and
inclusion guidelines and accept any applicant who can meet all of our other
requirements.

With this background, I would like to encourage everyone to provide
constructive input on this topic.

Thanks,

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

RE: CCADB disclosure of id-kp-emailProtection intermediates

[Ben Wilson via dev-security-policy]

What about the Mozilla CA communication that said that CAs had until 15
April 2018?

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
Behalf Of Rob Stradling via dev-security-policy
Sent: Tuesday, January 16, 2018 2:29 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: CCADB disclosure of id-kp-emailProtection intermediates

[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents
Mozilla's policy and/or current expectations.  Thanks!]

Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the
non-disclosure (and, IINM, non-audit) of certain non-technically-constrained
id-kp-emailProtection intermediate certificates...until yesterday:
"Instead of complying with the above paragraph, intermediate certificates
issued before 22nd June 2017 may, until 15th January 2018..."

According to [2], there are currently 223 non-technically-constrained
intermediate certificates known to crt.sh that chain to an NSS built-in root
(that has the Email trust bit set) and are capable of issuing
id-kp-emailProtection certificates but not id-kp-serverAuthentication
certificates.

IIUC, the Mozilla policy now requires these intermediate certificates to
have already been disclosed to the CCADB and to be audited.


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

Add Wayne Thayer as Peer of Mozilla's CA Certificates and CA Certificate Policy modules

[Kathleen Wilson via dev-security-policy]

All,

I propose adding Wayne Thayer as a peer[1] of Mozilla's CA Certificates 
Module[2] and CA Certificate Policy Module[3]. As you know, Wayne and I 
are distributing the job of running Mozilla's CA Program between us, so 
he will be actively working on both of these Modules.


Thanks,
Kathleen

[1] https://wiki.mozilla.org/Modules
[2] https://wiki.mozilla.org/Modules/All#CA_Certificates
[3] https://wiki.mozilla.org/Modules/All#Mozilla_CA_Certificate_Policy

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

CCADB disclosure of id-kp-emailProtection intermediates

[Rob Stradling via dev-security-policy]

[Kathleen, Gerv, Wayne: Please correct me if this post misrepresents 
Mozilla's policy and/or current expectations.  Thanks!]


Mozilla Root Store Policy v2.5 section 5.3.1 [1] permitted the 
non-disclosure (and, IINM, non-audit) of certain 
non-technically-constrained id-kp-emailProtection intermediate 
certificates...until yesterday:
"Instead of complying with the above paragraph, intermediate 
certificates issued before 22nd June 2017 may, until 15th January 2018..."


According to [2], there are currently 223 non-technically-constrained 
intermediate certificates known to crt.sh that chain to an NSS built-in 
root (that has the Email trust bit set) and are capable of issuing 
id-kp-emailProtection certificates but not id-kp-serverAuthentication 
certificates.


IIUC, the Mozilla policy now requires these intermediate certificates to 
have already been disclosed to the CCADB and to be audited.



[1] 
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#technically-constrained


[2] https://crt.sh/mozilla-disclosures#undisclosed

[3] https://crt.sh/mozilla-disclosures#undisclosedsummary

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ComSign Root Renewal Request

[Wayne Thayer via dev-security-policy]

To recap, we've established that this root was first BR audited on 26-April 
2015 and has received clean period-of-time audits over the next two years. 
ComSign has disclosed 36 certificates issued by this root prior to the BR 
point-in-time audit, of which one remains unexpired. This does not meet the 
requirements of BR section 8.1 both because the point-in-time readiness 
assessment was not completed prior to issuing a publicly-trusted certificate, 
and because the first period-of-time audit was not completed within 90 days of 
issuing a publicly-trusted certificate. Mozilla policy, however, does not 
require a root to have maintained BR compliance over its entire lifetime to be 
included in the program. ComSign's current annual WebTrust for CAs and BR 
audits are enough to meet Mozilla's requirements.

The questions I raised have been addressed to my satisfaction. If anyone has 
further concerns, please raise them this week so that we can complete the 
public discussion period for this inclusion request. 

- Wayne

On Sunday, December 24, 2017 at 2:46:03 AM UTC-7, YairE wrote:
> Hi Wayne,
> 
> as requested i added the file with the certificates issued since 26/10/2014 
> until 31/03/2015 to the bug,
> 
> Back then it seems we didn’t have a WebTrust audit (I believe we started in 
> 2015) but only external CPA and governmental audits as are attached already.
> The reason we didn’t have a WebTrust audit is that we were already being 
> audited by other auditors and the external WebTrust auditor was qualified 
> only around that time.

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

RE: Possible Issue with Domain Validation Method 9 in a shared hosting environment

[Doug Beattie via dev-security-policy]

Ryan,

Here is some more information to continue the discussion.

-  We will continue to post all certificates to CT logs so issuance can 
be monitored.

-  We will reduce validity period of OneClick certificates to 6 months.

-  We will work with the hosting providers (on a case by case basis) to 
implement processes and procedures which prevent the uploading and use of test 
certificates on user controlled shared IP addresses (similar to how LE worked 
with their larger customers to blocking acme.invalid from being used)

More below.

From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Monday, January 15, 2018 4:56 PM
To: Doug Beattie 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Gervase 
Markham ; Wayne Thayer 
Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting 
environment
As suggested, we encourage you to work on devising technical mitigations or 
alternative methods of validating such certificates that can meet the use case. 
We don't think that, as described, the OneClick method meets the necessary 
level of assurance, nor do the necessary level of mitigating factors exist, to 
consider such certificates trustworthy.

Ryan – I’m at a loss.  The security threat is that a user can request a 
certificate for a domain they don’t own from hosting companies that permit SNI 
mappings to domains the user doesn’t own or control.  This permits them to pass 
validation for a domain they don’t control that is on the same IP address as 
their legitimate site (or at least to which they have this level of SNI 
control).  We will verify that our OneClick customers will request certificates 
for domains the hosting company is actively managing for their users and not 
permit malicious actions (much like LE verifying that their hosting companies 
do not permit “acme.invalid” domains to be used).  This eliminates the problems 
of SNI being used as an avenue for domain validation for malicious actors.  Is 
this not sufficient for some reason?

Surely you agree that within non-shared hosting environments OneClick is not 
vulnerable and can be used.

No, it's not sufficient.

The failure mode unfortunately necessarily includes a failure by GlobalSign 
process and/or personnel, and in that failure mode, there are further no 
mitigating factors.

- If GlobalSign adds a vulnerable entity to their whitelist
  - The certificates issued will be valid for 1-3 years, leaving only the 
(broken) revocation system as recourse
We can and will reduce max validity to 6 months as a standard configuration 
option within our system.

  - There is no step organizations can take to pre-emptively mitigate the risk 
of GlobalSign adding to the whitelist (compared to, say, blocking .invalid)
Actually, there is and I apologize for not making this more clear before.  We 
have site operators that manage the issuance of certificates for their users.  
End users have no access to the issuance process, in uploading test 
certificates to their sites, or any involvement in the issuance process as this 
is automated by the site operators.  Given this approach is verified with the 
provider, we would propose whitelisting the account.

  - There is no ability for site operators to detect such situations. A 
consideration, not listed within the full set when discussing Let's Encrypt and 
the ACME TLS-SNI method, is that we have at least public commitment by Let's 
Encrypt and demonstrated evidence of sustained/long-term compliance with 
publicly disclosing all issued certificates ( as noted in 
https://letsencrypt.org/certificates/ ). While I realize you've offered to do 
so, I can find no evidence of GlobalSign doing so by default, and so this 
further adds to the risk calculus of a commitment to do something not yet 
practice and thus not yet consistently, reliably delivered on.
We currently include SCTs in all certificates we issue with the possible 
exception of some Enterprise customers that prefer to keep their OV 
certificates private (at least for now).  This has been configured since 
mid-November for all GlobalSign SSL products.

There is not, in our view, reason to accept this significantly greater 
(holistically considered) risk.

We're open to understanding whether GlobalSign has additional proposals how to 
mitigate this risk, given the set of concerns expressed - technical measures 
and policy measures. These may provide a path to allowing such issuance in the 
future, but we don't think that, given the holistic risk assessment, it's 
appropriate to allow it to immediately resume. We are keen to find solutions 
that work, as we understand that these can enable powerful new use cases, but 
we want to balance that with the risk posed.

I would encourage GlobalSign to consult Sections 3.2.2.4 and 3.2.2.5 to see if 
there are any other alternative methods to validating that might represent an 

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

[Alex Gaynor via dev-security-policy]

It would come at the expense of a more streamlined and secure approach
(e.g. the ALPN proposal on the acme-wg list), which once standardized I
assume Let's Encrypt (and other ACME CAs) would want to fully migrate to.

Alex

On Mon, Jan 15, 2018 at 9:27 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 14/01/18 21:32, jacob.hoffmanandr...@gmail.com wrote:
> > We discussed a similar approach (using CAA) on our community forum,
> > and concluded we don't want to pursue it at this time:
> > https://community.letsencrypt.org/t/tls-sni-via-caa/50172. The TXT
> > record would probably work more widely than CAA, but it would still
> > be encouraging further integration with TLS-SNI-01, when we really
> > want to encourage migration away from it. Right now it's our feeling
> > that the account and renewal whitelisting should mitigate most of the
> > pain of migrating away, but experience and feedback from subscribers
> > will help inform that over time.
>
> Why would you want to continue migrating away if it were based on a
> self-serve whitelist? Would that not re-secure the method?
>
> Gerv
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy