[cryptography] really sub-CAs for MitM deep packet inspectors? (Re: Auditable CAs)

Marsh Ray marsh at extendedsubset.com
Thu Dec 1 12:48:40 EST 2011


On 12/01/2011 11:09 AM, Ben Laurie wrote:
> On Thu, Dec 1, 2011 at 4:56 PM, Marsh Ray<marsh at extendedsubset.com>
> wrote:
>>> http://www.prnewswire.com/news-releases/geotrust-launches-georoot-allows-organizations-with-their-own-certificate-authority-ca-to-chain-to-geotrusts-ubiquitous-public-root-54048807.html
>
> They appear to actually be selling sub-RA functionality, but very
> hard to tell from the press release.
>
> Bottom line: I'm going to believe this one someone displays a cert
> chain.


Translated:

> GeoRoot is only available for internal use, and organizations must
> meet certain eligibility requirements, [...]  compliance guidelines,
> and hardware security specifications.
       ^^^^^^^^

> Organizations must maintain a list Certificate Revocation List (CRL)
   ^^^^^^^^^^

> for all certificates issued by the company.
                        ^^^^^^^^^^^^^^^^^^^^


But don't worry,  Mozilla has a "checklist" for sub-CAs!

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

> Home » CA:SubordinateCA_checklist

> Terminology
>
> The following terminology will be used in this wiki page regarding
> subordinate CAs.
>
> Third-Party: The subordinate CA is operated by a third party external
> to the root CA organization; and/or an external third party may
> directly cause the issuance of a certificate within the CA
> hierarchy.

> Third-party private (or enterprise) subordinate CAs: This is the case
> where a commercial CA has enterprise customers who want to operate
> their own CAs for internal purposes, e.g., to issue SSL server
> certificates to systems running intranet applications, to issue
> individual SSL client certificates for employees or contractors for
> use in authenticating to such applications, and so on.
>
> * These sub-CAs are not functioning as public CAs, so typical Mozilla
> users would not encounter certificates issued by these sub-CAs in

s/would/should/

> their normal activities.
> * For these sub-CAs we need assurance that
> they are not going to start functioning as public CAs.

As Dan would say, security comes from this "absence of the potential" 
for this type of surprise.

This is not security, this reliance.

> Currently the
> only assurances available for this case it to ensure that these third
> parties are required to follow practices that satisfy the Mozilla CA
> Certificate Policy, and that these third parties are under an
> acceptable audit regime.

Promises, promises.

> o In Bug #394919 NSS is being updated to
> apply dNSName constraints to the CN, in addition to the SANs.
> o We
> plan to update our policy to require CAs to constrain third-party
> private (or enterprise) subordinate CAs so they can only issue
> certificates within a specified domain. See section 4.2.1.10 of RFC
> 5280.

Someday.

To be fair to Mozilla, at least they're the ones with an open policy 
about it. I didn't find such a policy for the other popular web clients 
(I may not have looked hard enough).

- Marsh



More information about the cryptography mailing list