Re: Stop using SHA1 in certificates

[Florian Weimer]

* Kurt Roeckx:

 But it's unclear if this is really a policy or just what some
 people think should happen.

If we do this, it should not just apply to end-entity certificates,
but also to intermediate certificates (but not the self-signature of
root certificates).  Obviously, that's rather unlikely to happen
because of the number of long-term intermediate certificates which
cannot be re-issued under current policies.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Name Constraints

[Florian Weimer]

* Richard Barnes:

 I've been doing some research on the potential benefits of adding name
 constraints into the Mozilla root program.  I've drafted an initial
 proposal and put it on a wiki page:

 https://wiki.mozilla.org/CA:NameConstraints

 Questions and comments are very welcome.

A PKIX-compliant implementation of Name Constraints is not effective
in the browser PKI because these constraints are not applied to the
Common Name.

NSS used to be non-compliant (and deliberately so), so the constraints
do work there, but I don't know if that's still the case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

[Florian Weimer]

* Gervase Markham:

 On 24/03/15 09:38, Florian Weimer wrote:
 The intermediate certificate which prompted this discussion had C=EG,
 which does not align well with a limitation to the Chinese market.

 I'm not entirely sure what you are saying here. Are you saying you are
 suprised not to see .eg in that list?

Or a more diverse choice of (cc)TLDs, yes.

 CNNIC could issue a cert to an Egyptian Company called Cairo Corporation
 for cairocorp.com, and the issuer would be C=EG, O=Cairo Corporation,
 but the CN would be www.cairocorp.com. In this type of case, .eg would
 not show up in the list.

Technically, this is true.  I just find it odd that the offending
certificate suggests a relationship with a non-Chinese market, while
at the same time, Richard's data only shows the top gTLDs and various
China-related TLDs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

[Florian Weimer]

* Florian Weimer:

 * Kai Engert:

 The discovery of any unconstrained and unrevoked intermediate CA
 certificate that isn't controlled by the root CA organization results in
 the immediate removal of the root CA from the Mozilla CA list.

 In this case, wouldn't this require the removal of the Entrust root,
 not just the CNNIC root?  Or wasn't the CNNIC SSL sub-CA certificate
 extended beyond 2012?

According to the CNNIC CPS, the sub-CA certificate still exists:

“According to the agreement of CNNIC and Entrust, CNNIC intermediate
root CNNIC SSL is trusted by Entrust root certificate also. The domain
certificates issued by CNNIC Trusted Network Service Center may be
generated through different route either by CNNIC root or by Entrust
root.”

Certificate Practice Statement of the Trusted Network Service Center of
the China Internet Network Information Center (CNNIC)
Version No.: 3.03 
Validity from July 1st, 2013
http://www1.cnnic.cn/IS/fwqzs/CNNICfwqzsywgz/201208/W020130929345948738150.pdf

However, Entrust does not list the sub-CA certificate here:

  http://www.entrust.net/about/third-party-sub-ca.htm

As far as I can see, there are several explanations for that:

* It was omitted by accident.

* The CNNIC root was signed (although only signatures on the
  intermediate CNNIC SSL CA certificate have been documented so far, I
  think).

* Entrust assumes that once an organization has a root in the Mozilla
  program, any sub-CAs controlled by that organization is exempted
  from disclosure.

* The CNNIC CPS is incorrect, and they no longer run an
  Entrust-sponsored sub-CA.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

[Florian Weimer]

* Rob Stradling:

 On 24/03/15 19:58, Florian Weimer wrote:
 snip
 There's also an ongoing effort to defang CT and make the data much
 less useful, so CT could turn meaningless fairly soon.

 Huh?

The work on name redaction worries me.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

[Florian Weimer]

* Gervase Markham:

 On 25/03/15 10:27, Florian Weimer wrote:
 * The CNNIC CPS is incorrect, and they no longer run an
   Entrust-sponsored sub-CA.

 I believe this is the correct answer. Quoting Bruce Morton in this thread:

 Please note that the intermediate certificate which Entrust issued to
 CNNIC expired in 2012 and was not extended. Also note that the Basic
 Constraints had a path length of 0; as such the trust would not have
 extended to intermediates issued by CNNIC.

Yes, I saw this message only after I had posted the above.

This leads to the question why Ernst  Young, CNNIC's auditors, have
not caught this discrepancy between the CPS and actual business
practice.  The most recent audit
https://cert.webtrust.org/SealFile?seal=1731file=pdf already covers
the time period when CNNIC ceased to be an Entrust sub-CA.

(I think to clean up this mess, we should focus on formal mistakes by
auditors, not things that can be downplayed as operational glitches.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

[Florian Weimer]

* Kai Engert:

 The discovery of any unconstrained and unrevoked intermediate CA
 certificate that isn't controlled by the root CA organization results in
 the immediate removal of the root CA from the Mozilla CA list.

In this case, wouldn't this require the removal of the Entrust root,
not just the CNNIC root?  Or wasn't the CNNIC SSL sub-CA certificate
extended beyond 2012?

Clearly, the removal of an actually relevant root CA from the trust
store is not going to happen because the user impact and subsequent
reduction in browser market share.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

[Florian Weimer]

* Kurt Roeckx:

 I understand that the name constraint applies to the
 SubjectAltName. Under the Baseline Requirements the SAN must be
 present.  If there is a CommonName it should match one of the SANs.

If the CAs abided by the baseline requirements, we wouldn't have to
consider name constraints. :-(

 We know that not everybody does add the SANs.  But I think that if
 there is a name constraint and there is no SAN we should just either
 reject the certificate for being invalid or for not matching.

This has to be integrated with certificate path processing somehow.
Maybe it is feasible to ignore the Subject DN if there is a name
constraint anywhere on the path?

That would be fairly straightforward to implement with other PKIX
validators (which generally lack the NSS hack for Common Name
verification).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

[Florian Weimer]

* Daniel Micay:

 These rules would be a lot more meaningful if any new additions to the
 trust store were required to have Certificate Transparency implemented
 for the sake of auditing, along with a deadline for other CAs to put it
 in place. CT would have meant this was trivially caught *much* earlier
 by security researchers.

That depends on how many legitimate gmail.com certificates are out
there.  Organizations struggle to keep track of their own
certificates.  It's difficult to see how relative outsiders (and most
“security researchers” are) can cope with that, except by raising an
alarm about everything they see (which is not generally helpful).

There's also an ongoing effort to defang CT and make the data much
less useful, so CT could turn meaningless fairly soon.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

[Florian Weimer]

* Daniel Micay:

 In other words, if you want the responsible choice to be made in these
 cases then you should be contacting news publications to shame Mozilla
 into doing the right thing - not a Mozilla mailing list.

Ugh, surely there has to be a better way.

I sometimes get carried away and post acerbic comments about things
like the dynamics of maintaining a market share (sorry about that),
but what you propose is totally over the top.

The present can of worms is not just about an unwillingness to do the
right thing (whatever that is), but there are one or two unsolved
engineering problems involved.  You simply can't make those go away by
media pressure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Nation State MITM CA's ?

[Florian Weimer]

* Jakob Bohm:

> Could they, hypothetically, simply claim to use the real certificate on
> the connection from their MiTM machines to the real server to do
> practical control validation?  They would have to claim, also, that
> they are holding the private key of the MiTM certificate "in trust" on
> behalf of the site owners "on whose behalf" the issued the certifiate?
> (Just playing devils advocate).

I think it's similar to what certain CDNs do: They hold the key
material (both long term and session) on behalf of the server
operator.  A TLS interception facility holds the session keys on
behalf of the client.

Both parties claim to increase Internet security.  Both are probably
right in some ways, and wrong in others.

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

Re: WoSign and StartCom: next steps

[Florian Weimer]

* Hanno Böck:

> Minor sidenote: there have been some concerns about TLS security
> vulnerabilities of the qihoo 360 browser [1] [2]. While this is not
> directly related to the operation of a CA, it surely would increase the
> community's trust of qihoo 360 if these issues get resolved quickly.
>
>
> [1] https://cabforum.org/pipermail/public/2015-April/005441.html
> [2] https://twitter.com/ryancdotorg/status/780470538686697472

It is certainly possible to implement access to servers using
untrusted X.509 certificates in such a way that security is
compromised only after further user action (e.g. supplying login
credentials, despite the browser warning).  A reasonable approximation
of such a secure implementation is to visit the site with a fresh
Firefox profile, and override the certificate warning.

More care is needed to check the origin of the cookie which, according
to Tom Ritter's post, the browser transmitted without further user
interaction.  It might be the case that the cookie is not marked as
secure (restricting it to HTTPS), or it may have been created as a
secure cookie over an untrusted HTTPS connection.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Florian Weimer]

* Richard Wang:

>> Thus, do you believe it was faithful and accurate for Management to
>> warrant that the CA was operated in compliance with the BRs, given
>> that Management was aware of incidents of non-compliance?
>
> This is my fault that I think it is not serious enough to state in
> the assertion letter, now I know and every related employee know how
> to do this in the future.

Richard,

do you think more precise communication from auditors could have
helped to avoid the incorrect representation?

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

Re: WoSign Issue L and port 8080

[Florian Weimer]

* Nick Lamb:

> On Sunday, 11 September 2016 21:05:12 UTC+1, Lee  wrote:
>> does dns hijacking or dns cache poisoning count as mitm?
>
> A careful CA validator does DNS only by making authoritative queries,
> so they're not subject to cache poisoning since they don't look at
> cached answers.

I'm not sure if you can resolve all domains without some sort of DNS
cache, in the sense that you never use data from one answer to satisfy
more than one query (which can be internally generated).

More reasonable would be to require that the resolver starts with a
cold cache (possibly preloaded with a copy of the root zone) and
performs DNSSEC validation starting with the IANA keys.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Florian Weimer]

* Peter Bowen:

> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei  wrote:
>> So when I delegated the DNS service to Cloudflare, Cloudflare have
>> the privilege to issue the certificate by default? Can I understand
>> like that?
>
> I would guess that they have a clause in their terms of service or
> customer agreement that says they can update records in the DNS zone
> and/or calls out that the subscriber consents to them getting a
> certificate for any domain name hosted on CloudFlare DNS.

I find it difficult to believe that the policies permit Cloudflare's
behavior, but are expected to prevent the issue of interception
certificates.  Aren't they rather similar, structurally?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Florian Weimer]

* Ben Laurie:

> On 10 September 2016 at 15:43, Erwann Abalea  wrote:
>> Ironically, since you're not the Subscriber, you cannot request for
>> the revocation of this certificate, at least not directly to the
>> CA. If you want this certificate to be revoked, you need to ask
>> Cloudflare.
>
> Surely not? The BRs say (4.9.2):
>
> "The Subscriber, RA, or Issuing CA can initiate revocation.
> Additionally, Subscribers, Relying Parties, Application Software
> Suppliers, and other third parties may submit Certificate Problem
> Reports informing the issuing CA of reasonable cause to revoke the
> certificate."

This is fairly new.  Third-party revocation requests are very tricky
to process promptly.  For many (most?) interesting certificates, the
guaranteed damage from an immediate revocation outweighs the risk from
a potential man-in-the-middle attack enabled by the compromised
certificate.

Back in 2008, most CAs flat out refused to revoke certificates even
though there was proof that the private key has been compromised.  A
very small-scale repeat exercise showed that this is no longer the
case.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Cerificate Concern about Cloudflare's DNS

[Florian Weimer]

* Patrick Figel:

> On 17/09/16 16:38, Florian Weimer wrote:
>> * Peter Bowen:
>> 
>>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei <hanyuwe...@gmail.com>
>>> wrote:
>>>> So when I delegated the DNS service to Cloudflare, Cloudflare 
>>>> have the privilege to issue the certificate by default? Can I 
>>>> understand like that?
>>> 
>>> I would guess that they have a clause in their terms of service or 
>>> customer agreement that says they can update records in the DNS 
>>> zone and/or calls out that the subscriber consents to them getting
>>> a certificate for any domain name hosted on CloudFlare DNS.
>> 
>> I find it difficult to believe that the policies permit Cloudflare's 
>> behavior, but are expected to prevent the issue of interception 
>> certificates.  Aren't they rather similar, structurally?
>
> I don't see how they're similar. Interception certificates are issued
> without the knowledge and permission of the domain owner. Someone
> signing up for CloudFlare willingly chooses to trust a CDN provider with
> all their web traffic and DNS (in order to enable CloudFlare for a
> domain, the NS record for that domain needs to point to CloudFlare.)
>
> I could understand this argument if they'd somehow pretend to be a
> DNS-only provider and then abuse that to issue certificates. However,
> nothing about their site (or their marketing approach in general) gives
> me that impression - it's made quite clear that they're primarily a CDN
> with SSL support.

Well, there is <https://www.cloudflare.com/dns/>.

My concern goes like this: If I move my infrastructure to Cloudflare,
I give them implied permission, based on their terms of service, to
obtain a X.509 certificate for my domain names hosted there, so that
they can intercept traffic.

On the other hand, if I move my infrastructure to Germany, I give the
German authorities implied permission, based on applicable German law,
to ask my service provide to obtain an X.509 certificate for my domain
names hosted there, so that they can intercept traffic in the clear
(in accordance with German law).

In both cases, we have implied consent, but the alleged certificate
subscriber never has control over the private key, and how it is used.
I don't think neither setup is intended to exist per the Mozilla CA
guidelines.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Draft Email - Non-Disclosed SubCAs

[Florian Weimer]

* Kathleen Wilson:

> The following was stated in Mozilla’s March 2016 CA Communication
> (https://wiki.mozilla.org/CA:Communications#March_2016):
> Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any
> certificate which directly or transitively chains to the root
> certificates you currently have included in Mozilla's CA Certificate
> Program, which are capable of being used to issue new certificates,
> and which are not technically constrained as described in Section 9 of
> Mozilla's CA Certificate Inclusion Policy, you are required to provide
> public-facing documentation about the certificate verification
> requirements and annual public attestation of conformance to said
> requirements. This includes certificates owned by, operated by, or
> issued by third parties, whether or not those issuing certificates are
> already part of Mozilla's CA Certificate Program, if they have been
> cross-signed by a certificate that directly or transitively chains to
> your root certificate.

Does this requirement apply transitively sub-CAs of sub-CAs?

It may make sense to stress explicitly that the “technically
constrained” refers to properties visible in the certificates
themselves, not technical measures in the certificate issuance process
(which I would consider organizational constraints, but opinions
probably differ).

What about sub-CAs with outdated published policies which do not meet
Mozilla's requirements, but where the CA actually issues certificates
according to an unpublished policy which is likely conforming to
Mozilla's requirements?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

[Florian Weimer via dev-security-policy]

* Nick Lamb via dev-security-policy:

> In order for Symantec to reveal anybody's private keys they'd first
> need to have those keys, which is already, IIRC forbidden in the
> BRs.

I think this requirement was dropped because it makes it unnecessarily
difficult to report key compromises.  There used to be a time when CAs
demanded zero-knowledge proofs of key compromise (which can be
surprisingly hard to do with existing tools).  Fortunately, these
times are over, and CAs no longer categorically reject the submission
of compromised subscriber keys (although my sample is really small due
to my limited factorization capabilities).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Florian Weimer via dev-security-policy]

* Peter Kurrasch via dev-security-policy:

> By "not new", are you referring to Google being the second(?) instance
> where a company has purchased an individual root cert from another
> company? It's fair enough to say that Google isn't the first but I'm
> not aware of any commentary or airing of opposing viewpoints as to the
> suitability of this practice going forward.

I think most of the DNs in the Mozilla root store still do not reflect
reality.  The restrictions on certificate naming do not apply to the
CAs themselves.  This is due to the way PKIX validation works.
Correcting the DNs would break the certificate chains.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy