Restricting which CAs can issue certs for which hostnames
Boris Zbarsky
"specialist" CAs that would only issue certs for a limited range of
hostnames. Could we formalize this, and have CAs indicate any such
restrictions as part of their application, then enforce it on our end?
That would limit the extent to which a compromise of one of these
"specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA is
being used to sign the Mossad's website and cry foul, without
pre-pinning the CA for the presumably rarely visited Mossad site). If
one of the big CAs that issue certs all over were compromised there
would still be a problem of course, but we could conceivably demand more
diligence in terms of being added to our cert store from CAs that want
to issue certs to everyone .... and even if we don't we might trust some
them more than the specialist CAs to start with.
Has this been considered before? Is my assumption that a lot of the CAs
in our trust list would only issue to a small subset of possible
hostnames accurate? If so, is doing what I propose above feasible and
worthwhile?
Other than the above and CA pinning for particular sites, any other
ideas on how we can mitigate the scope of problems like this in the future?
-Boris
Amir Herzberg
but in the browser itself (and maybe you can even use the `name restriction`
mechanism to implement this easily and cleanly).
Other thing you can do is to that browser will remember which CA(s) signed
with cert and note any new CA; once detecting new CA you can have browser
contact a special Mozilla-run server which know all legitimate mappings (at
least, for domains wishing such protection).
BTW, in my `TrustBar` FF extension (part of research on usable secure login
mechnisms for browsers), we tried to address (also) this threat by including
CA name in the display to users, this aspect of TrustBar, as others, was
adopted (with minor changes) by most browsers, i.e. displaying the
`identified by` information. But this isn't really that useful, i.e., our
research found users do not notice this signal. I'm also quite sure most
users will also ignore an active warning (i.e., one requiring them to
approve using cert from new ca).
Amir Herzberg
> ______________________________**_________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-security<https://lists.mozilla.org/listinfo/dev-security>
>
>
--
Amir Herzberg
Associate Professor, Dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Amir Herzberg
Jean-Marc Desperrier
> [...] Could we formalize this, and have CAs indicate any such
> restrictions as part of their application, then enforce it on our end?
Yes for government CA, in order to limit them to issue certificate only
for their own ccTLD. And then it would be possible to not require them
anymore to be certified by a private auditor.
I'd need to check where this is standing, at one point NSS could not
enforce such a name constraint because of the legacy of including the
server name inside the CN of the certificate. But AFAIR this is solved
now, at least at NSS's level.
Gervase Markham
> I was looking at our CA root list, and a lot of them seem like
> "specialist" CAs that would only issue certs for a limited range of
> hostnames. Could we formalize this, and have CAs indicate any such
> restrictions as part of their application, then enforce it on our end?
There is a way to encode this in certificates, called basicConstraints,
although I suspect very few CAs do that. (Why limit your market?) I
guess NSS could have a feature to impose them on a CA from outside.
> That would limit the extent to which a compromise of one of these
> "specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA is
> being used to sign the Mossad's website and cry foul, without
> pre-pinning the CA for the presumably rarely visited Mossad site).
Just because they are a Dutch CA doesn't mean they are necessarily only
working with Dutch sites. Verisign/Symantec is an American CA.
We don't want to put ourselves in a position of entrenching incumbents.
In addition, even a CA focussed only on Dutch _companies_ would want to
issue certs for .com, because I'm sure a lot of Dutch companies have
..com sites. Given that the aim would be to prevent them issuing bogus
certs for mozilla.org, paypal.com, twitter.com etc., I'm not sure many
of them
We did consider imposing such a restriction for government CAs, on the
basis that the audit rules relating to them are necessarily different.
> Has this been considered before? Is my assumption that a lot of the CAs
> in our trust list would only issue to a small subset of possible
> hostnames accurate?
It is, but perhaps not in a useful way which allows us to contain risk. :-|
Gerv
Boris Zbarsky
> There is a way to encode this in certificates, called basicConstraints,
> although I suspect very few CAs do that. (Why limit your market?)
One possible answer to this last question could probably be "because it
will make it simpler to end up in our trusted CA list".
Hard to enforce on CAs that are already in it, of course, unless we're
willing to announce a policy change and have CAs either add such
constraints or go through whatever hoops we want CAs that can issue to
any hostname to go through.
Another possible answer is "reduces the chance of your CA being executed
like DigiNotar was". Maybe.
> I guess NSS could have a feature to impose them on a CA from outside.
Or that, yes.
>> That would limit the extent to which a compromise of one of these
>> "specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA is
>> being used to sign the Mossad's website and cry foul, without
>> pre-pinning the CA for the presumably rarely visited Mossad site).
>
> Just because they are a Dutch CA doesn't mean they are necessarily only
> working with Dutch sites. Verisign/Symantec is an American CA.
I didn't say this applies to all CAs. I said that there are CAs in our
cert store it applies to. The phrase "Dutch CA" above means "A CA that
told us it only issues certificates to .nl sites".
> We don't want to put ourselves in a position of entrenching incumbents.
Yes, I agree. CAs should be free to not thus restrict themselves, but I
think that should imply a higher trust bar on our part....
> In addition, even a CA focussed only on Dutch _companies_ would want to
> issue certs for .com, because I'm sure a lot of Dutch companies have
> ..com sites.
This is focusing on the wrong thing. I said up front that not all CAs
are "specialist" CAs. The question is how many of the ones in our cert
store _are_. If it's too few, this is not really a proposal that flies.
But we need that data.
> Given that the aim would be to prevent them issuing bogus
> certs for mozilla.org, paypal.com, twitter.com etc., I'm not sure many
> of them
Please continue? ;)
> We did consider imposing such a restriction for government CAs, on the
> basis that the audit rules relating to them are necessarily different.
OK. Considered and rejected? Or considered and limboed?
>> Has this been considered before? Is my assumption that a lot of the CAs
>> in our trust list would only issue to a small subset of possible
>> hostnames accurate?
>
> It is, but perhaps not in a useful way which allows us to contain risk. :-|
OK, can we get data on this somehow? Asking the CAs themselves, say?
-Boris
Hill, Brad
Brad Hill
> -----Original Message-----
> From: dev-security-bounces+bhill=paypal-...@lists.mozilla.org
> [mailto:dev-security-bounces+bhill=paypal-...@lists.mozilla.org] On
> Behalf Of Gervase Markham
> Sent: Wednesday, August 31, 2011 3:35 AM
> To: mozilla-de...@lists.mozilla.org
> Subject: Re: Restricting which CAs can issue certs for which hostnames
>
> On 30/08/11 17:46, Boris Zbarsky wrote:
> > I was looking at our CA root list, and a lot of them seem like
> > "specialist" CAs that would only issue certs for a limited range of
> > hostnames. Could we formalize this, and have CAs indicate any such
> > restrictions as part of their application, then enforce it on our end?
>
> There is a way to encode this in certificates, called basicConstraints, although I
> suspect very few CAs do that. (Why limit your market?) I guess NSS could have
> a feature to impose them on a CA from outside.
>
> > That would limit the extent to which a compromise of one of these
> > "specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA
> > is being used to sign the Mossad's website and cry foul, without
> > pre-pinning the CA for the presumably rarely visited Mossad site).
>
> Just because they are a Dutch CA doesn't mean they are necessarily only
> working with Dutch sites. Verisign/Symantec is an American CA.
>
> We don't want to put ourselves in a position of entrenching incumbents.
>
> In addition, even a CA focussed only on Dutch _companies_ would want to issue
> certs for .com, because I'm sure a lot of Dutch companies have ..com sites.
> Given that the aim would be to prevent them issuing bogus certs for
> mozilla.org, paypal.com, twitter.com etc., I'm not sure many of them
>
> We did consider imposing such a restriction for government CAs, on the basis
> that the audit rules relating to them are necessarily different.
>
> > Has this been considered before? Is my assumption that a lot of the
> > CAs in our trust list would only issue to a small subset of possible
> > hostnames accurate?
>
> It is, but perhaps not in a useful way which allows us to contain risk. :-|
>
> Gerv
>
> _______________________________________________
> dev-security mailing list
> dev-se...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security
Sean Leonard
respond from more of an NSS point of view.
On 8/30/2011 9:46 AM, Boris Zbarsky wrote:
> I was looking at our CA root list, and a lot of them seem like
> "specialist" CAs that would only issue certs for a limited range of
> hostnames. Could we formalize this, and have CAs indicate any such
> restrictions as part of their application, then enforce it on our end?
The proper way to enforce this is through the Name Constraints
extension, which is a part of the PKIX profile for certificates. See RFC
5280, section 4.2.1.10,
<http://www.apps.ietf.org/rfc/rfc5280.html#sec-4.2.1.10>, and section
6.1.1, <http://tools.ietf.org/html/rfc5280#section-6.1.1>. Note that
while it is part of the standard, it is not required to be implemented.
It seems that the time has finally come to implement it.
The standard extension looks like this:
id-ce-nameConstraints OBJECT IDENTIFIER ::= { id-ce 30 }
NameConstraints ::= SEQUENCE {
permittedSubtrees [0] GeneralSubtrees OPTIONAL,
excludedSubtrees [1] GeneralSubtrees OPTIONAL }
GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree
GeneralSubtree ::= SEQUENCE {
base GeneralName,
minimum [0] BaseDistance DEFAULT 0,
maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
The principle is that a CA (or the trust anchor) can limit downstream
certificates to certain subtrees, such as "anything within *.co.il" or
"anything EXCEPT google.com or *.google.com". The latter would be
especially useful for those well-known Alexa Top 50 sites +
mozilla.com/.org that are at acute risk, since the gains to getting a
fraudulent certificate for one of those domains is particularly high. It
would make a lot of sense simply to ask these top 50 + mozilla.com/.org
sites: "so, which CA providers do you intend to use?" and exclude the rest.
This extension has been a part of the PKIX standards since RFC 2459
(1999). For all that people complain about certificates, you can't say
the designers didn't think about this.
> That would limit the extent to which a compromise of one of these
> "specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA is
> being used to sign the Mossad's website and cry foul, without
> pre-pinning the CA for the presumably rarely visited Mossad site). If
> one of the big CAs that issue certs all over were compromised there
> would still be a problem of course, but we could conceivably demand more
> diligence in terms of being added to our cert store from CAs that want
> to issue certs to everyone .... and even if we don't we might trust some
> them more than the specialist CAs to start with.
>
> Has this been considered before? Is my assumption that a lot of the CAs
> in our trust list would only issue to a small subset of possible
> hostnames accurate? If so, is doing what I propose above feasible and
> worthwhile?
It is feasible and worthwhile. It has also been considered before, but
nobody stepped up to do it (AFAIK).
My own estimate is that it would take a developer with a high degree of
familiarity with NSS approximately one and a half man-months, plus an
additional man-month for testing.
Name Constraints is a supported extension for all CA certificates.
References:
http://mxr.mozilla.org/mozilla-beta/source/security/nss/lib/libpkix/pkix_pl_nss/pki/pkix_pl_nameconstraints.c
http://mxr.mozilla.org/mozilla-beta/source/security/nss/lib/certdb/genname.c#1087
So, if a CA imposes name constraints, it should apply to downstream
certificates.
Unfortunately, Name Constraints is not a property of the NSS certificate
DB trust model. The cert DB trust model is particularly coarse-grained.
It only supports "yes/no/CA" for SSL, S/MIME, and Object Signing:
http://mxr.mozilla.org/mozilla-beta/source/security/nss/lib/certdb/certt.h#171
The trust model ought to be extended to include RFC 5280 sec. 6.1.1
(h) initial-permitted-subtrees,
(i) initial-excluded-subtress
in some useful way.
In addition, it would be very helpful to include
initial-permitted-subtrees and initial-excluded-subtrees as inputs to
CERT_PKIXVerifyCert:
http://mxr.mozilla.org/mozilla-beta/source/security/nss/lib/certdb/certt.h#821
.. This should be set as either unconstrained input parameters, or as
input parameters that are targeted to particular CAs (hence, combine the
name constraints with one or more certs in a certList).
While the underlying "libpkix" technology supports these (apparently) as
inputs, the implementation of CERT_PKIXVerifyCert does not allow these
inputs to be set.
A lot of people like to complain that there are "hundreds" of roots in
their browser stores. But this is not really true. There is only one
trust anchor that matters for 99.9% of the population: the browser
vendor itself (Mozilla). A more appropriate way to think about it is
that Mozilla/the cert repository maintainers operate the main trust
anchor, but have traditionally lacked the tools or the will to enforce
fine-grained constraints on the CA certificates in the stable. I would
not be surprised if CERTCertTrustStr has remained unchanged for the last
decade and a half.
> Other than the above and CA pinning for particular sites, any other
> ideas on how we can mitigate the scope of problems like this in the future?
>
Best to implement one standard right, than many standards poorly or
incompletely. ;-)
-Sean
Daniel Veditz
> Mozilla could add a certificate it controls to the trusted root
> store with which it cross-signs other CA certs, adding a
> nameConstraints in the process, yes?
In theory. In practice Firefox uses the historical certificate
verification code and not the NSS pkix code, and the old code does
not support constraints. We are working through a list of pkix bugs
with the goal of switching over.
-Dan Veditz
Adam Barth
attenuated as it is delegated.
Adam
On Tue, Aug 30, 2011 at 9:46 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
> I was looking at our CA root list, and a lot of them seem like "specialist"
> CAs that would only issue certs for a limited range of hostnames. Could we
> formalize this, and have CAs indicate any such restrictions as part of their
> application, then enforce it on our end? That would limit the extent to
> which a compromise of one of these "specialist" CAs could be exploited (e.g.
> we'd notice that a Dutch CA is being used to sign the Mossad's website and
> cry foul, without pre-pinning the CA for the presumably rarely visited
> Mossad site). If one of the big CAs that issue certs all over were
> compromised there would still be a problem of course, but we could
> conceivably demand more diligence in terms of being added to our cert store
> from CAs that want to issue certs to everyone .... and even if we don't we
> might trust some them more than the specialist CAs to start with.
>
> Has this been considered before? Is my assumption that a lot of the CAs in
> our trust list would only issue to a small subset of possible hostnames
> accurate? If so, is doing what I propose above feasible and worthwhile?
>
> Other than the above and CA pinning for particular sites, any other ideas on
> how we can mitigate the scope of problems like this in the future?
>
> -Boris
Adam Barth
Devdatta Akhawe
Devdatta Akhawe
DavidIllsley
> On 30/08/11 17:46, Boris Zbarsky wrote:
>
> > I was looking at our CA root list, and a lot of them seem like
> > "specialist" CAs that would only issue certs for a limited range of
> > hostnames. Could we formalize this, and have CAs indicate any such
> > restrictions as part of their application, then enforce it on our end?
>
> There is a way to encode this in certificates, called basicConstraints,
> although I suspect very few CAs do that. (Why limit your market?) I
> guess NSS could have a feature to impose them on a CA from outside.
>
> > That would limit the extent to which a compromise of one of these
> > "specialist" CAs could be exploited (e.g. we'd notice that a Dutch CA is
> > being used to sign the Mossad's website and cry foul, without
> > pre-pinning the CA for the presumably rarely visited Mossad site).
>
> Just because they are a Dutch CA doesn't mean they are necessarily only
> working with Dutch sites. Verisign/Symantec is an American CA.
>
> We don't want to put ourselves in a position of entrenching incumbents.
Absolutely agreed
>
> In addition, even a CA focussed only on Dutch _companies_ would want to
> issue certs for .com, because I'm sure a lot of Dutch companies have
> ..com sites. Given that the aim would be to prevent them issuing bogus
> certs for mozilla.org, paypal.com, twitter.com etc., I'm not sure many
> of them
Well I'm keen that the aim includes myonlinebankingaddress.co.uk as
well. And there are plenty of roots in Firefox which I expect don't
ordinarily issue .co.uk certs. In trying to think of non-entrenching
approaches to improve the current system, 2 things come to mind.
1. Require CAs to publish every month the list of publicsuffix.org
entries which they have currently valid end entity certificates issued
against. That would allow browsers to add a not-before constraint on
not-in-use suffixes for each CA. For specialist CAs, they'd likely
notice an unusual suffix as part of the publication process or, if
they'd not been aware of the issuance, the cert would become useless
after just a few weeks. However, I suspect CAs would balk at this as
someone (even if it's just a browser extension) is likely to turn it
around and block certs with given suffixes until they've been
published. There's also an increased cost to browser vendors, though
with automation, I'd hope it wouldn't be too high.
2. Require end entity certs to be issued by an intermediary cert with
basic constraints matching exactly the suffixes of the domain(s) used
in the end-entity certs. This would impose a cost on CAs to maintain
these intermediaries, which would hopefully minimise their creation.
This would (particularly for smaller CAs) make it less likely that an
intruder can issue a cert for an arbitrary suffix, and might
subsequently allow for more targeted blacklisting.
David
Nelson B
> Looks like there is some discussion on mozilla.dev.security; I wanted to
> respond from more of an NSS point of view.
>
> On 8/30/2011 9:46 AM, Boris Zbarsky wrote:
>> I was looking at our CA root list, and a lot of them seem like
>> "specialist" CAs that would only issue certs for a limited range of
>> hostnames. Could we formalize this, and have CAs indicate any such
>> restrictions as part of their application, then enforce it on our end?
>
> The proper way to enforce this is through the Name Constraints
> extension, which is a part of the PKIX profile for certificates. See RFC
> 5280, section 4.2.1.10,
> <http://www.apps.ietf.org/rfc/rfc5280.html#sec-4.2.1.10>, and section
> 6.1.1, <http://tools.ietf.org/html/rfc5280#section-6.1.1>. Note that
> while it is part of the standard, it is not required to be implemented.
> It seems that the time has finally come to implement it.
using name constraints.
If Mozilla operated an uber-root CA, cross certifying the CAs that now
appear in Mozilla's trusted CA list, rather than including those CAs'
self-signed roots, Mozilla could impose name constraints on each and every
one of those CAs.
[snip]
> familiarity with NSS approximately one and a half man-months, plus an
> additional man-month for testing.
Name constraints extensions in CA certs are rare things indeed.
[snip]
> their browser stores. But this is not really true. There is only one
> trust anchor that matters for 99.9% of the population: the browser
> vendor itself (Mozilla). A more appropriate way to think about it is
> that Mozilla/the cert repository maintainers operate the main trust
> anchor, but have traditionally lacked the tools or the will to enforce
> fine-grained constraints on the CA certificates in the stable.
operate its own Uber-CA. But as you noted, operating its own root CA
list is quite equivalent.
[snip]
I suggest continuing this discussion in m.d.security.policy.
Nelson B
> On 8/31/11 3:52 PM, Hill, Brad wrote:
>> Mozilla could add a certificate it controls to the trusted root
>> store with which it cross-signs other CA certs, adding a
>> nameConstraints in the process, yes?
> In theory. In practice Firefox uses the historical certificate
> verification code and not the NSS pkix code, and the old code does
> not support constraints.
libPKIX. Consider that applying DNS name constraints to certificate common
names is NOT standard practice, not required or suggested by the RFCs.
NSS's old cert lib does it now. Not sure about libPKIX.
John Nagle
Restrictions at the root level are appropriate. 90% of the certs in
the wild come from the big CAs that are members of the CA Browser Forum.
They're tightening up their rules on auditing. They don't want to
have a breach like DigiNotar and go bankrupt within weeks.
The other CAs should be severely restricted in what they can do.
The US Government and DOD have a number of CAs, and those certs
should only be valid for ".gov" and ".mil" domains, for example.
Comparable restrictions should be applied to governmental CAs for
CCtlds.
More restrictions on sub-CAs would be appropriate. A sub-CA for a
second-level domain should be restricted to that domain, and that
needs to be enforced.
There's a discussion on sub-CA policy going on now over on
mozilla.dev.security.policy. Check that out.
John Nagle
SiteTruth
Rob Stradling
> On 9/2/2011 11:42 PM, Daniel Veditz wrote:
"If only someone contributed developer manpower to NSS, in order to get
the bugs fixed that currently block us from switching to libPKIX by
default..."
So if your organization has any suitably skilled developers with time on
their hands, then I think contributing developer manpower would be the
most effective thing you could do to push this work along.
<snip>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online