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