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

Ben Laurie ben at links.org
Thu Dec 1 12:59:23 EST 2011


http://www.trustico.com/material/DS_GeoRoot_0205.pdf

Well, we'll only break the dishonest ones :-)

On Thu, Dec 1, 2011 at 5:48 PM, Marsh Ray <marsh at extendedsubset.com> wrote:
> 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