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

Lucky Green shamrock at cypherpunks.to
Sun Dec 4 01:37:36 EST 2011


On 2011-12-03 10:44, Kevin W. Wall wrote:
> On Fri, Dec 2, 2011 at 1:07 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> [snip]
>> OK, so it does appear that people seem genuinely unaware of both the fact that
>> this goes on, and the scale at which it happens.  Here's how it works:
>>
>> 1. Your company or organisation is concerned about the fact that when people
>> go to their site (even if it's an internal, company-only one), they get scary
>> warnings.

Partially correct. More commonly, the reason why enterprises buy sub-CAs
from public CAs is to be able to create certs that will be seen by
non-employees, such as for example S/MIME signing certs.

If your employees use S/MIME to sign outgoing emails, you don't want
those emails to trigger a security alert in your business partner's or
customers email client.

(In practice, it will rarely be your employee that signs an outgoing
email with S/MIME, but rather the signature will be performed by the
corporate encryption gateway. Note that end-to-end encryption, such as
S/MIME, breaks content inspection and fails to comply with cleartext
archival and retrieval regulatory requirements).

>> 2. Your IT people go to a commercial CA and say "we would like to buy the
>> ability to issue padlocks ourselves rather than having to buy them all off
>> you".
> 
> When it is *only* company-only, I think it's much more common for companies
> to set up their internal CAs and just do something like an SMS or WSUS push
> to get their internal root CA certs into all the trusted keystores of all the
> company computers. I've only seen the latter case used when it involves
> residential customers. We can't take that the approach to force them to
> add our internal CA cert chain to their trust stores, and even if we could it
> would likely result in so many calls to the help desk to make it infeasible.
> However, we have occasionally used that approach with business partners.

Agreed. If the concern is that employees receive security warnings when
accessing in-house websites, the standard solution is to push out a
corporate root via AD, which is transparent and works quite well.
Enterprise environments typically purchase a sub-CA only when the certs
will be seen by third parties.

>> 3. The CA goes through an extensive consulting exercise (billed to the
>> company), after which they sell the company a padlock-issuing license, also
>> billed to the company.  The company is expected to keep records for how many
>> padlocks they issue, and pay the CA a further fee based on this.

Sure, the sub-CA contract does include a maximum number of certs that
you are allowed to issue, but I have never seen such a contract
determining pricing based on an exact count. Instead, the pricing is
based on base + anticipated number of certs.

>> 4. Security is done via the honour system, the CA assumes the company won't do
>> anything bad with their padlock-issuing capability (or at least I've never
>> seen any evidence of a CA doing any checking apart from for the fact that
>> they're not getting short-changed).
>
> Through the honor system? Does that mean that we can use a pair
> of dice rolled two or three times for our "hardware key generation"? ;-)

Most public CAs that ship with MSIE/Mozilla/Chrome that sell sub-CAs
will contractually require that your in-house sub-CA stores its private
keys on a FIPS 140-2 certified HSM. No root CA that I have encountered
requires that you operate the HSM in FIPS mode or mandates that you
shall not back up the private key in the clear to a USB flash drive.

Every professional services team that I have worked with over the years
recommended to the customers of such sub-CAs to make a backup of the
private keys and store them in a safe somewhere. Sometimes encrypted,
sometimes in the clear, but always with the necessary decryption
information (smartcards and/or PINs) in the same safe.

With the major brands of root CAs you will need to show that you have a
CP/CPS in place. The root CA's professional services team will provide
you with a CP/CPS template. That CP/CPS will allow you to issue any kind
of cert that doesn't interfere with the root CA's core business or is
overtly criminal.

> Actually, more surprisingly, I've been told by those who manage
> something like this for our company, that even the reported
> number of padlocks that they issue and are expected to
> compensate the CA for is kept on the honor systemm--at least
> for the CA with whom we interact. (Or course, I'm assuming that
> the this CA retains the right to periodically do audits, etc.)

Concur. The standard sub-CA contracts contain a right to audit the
number of certs issued, like any enterprise-wide software license
agreement does include a right to audit used seats. Not once in over 30
years have I seen such an audit performed. There is no reason to audit:
when you buy a sub-CA, the public CA's rep will work out a contract that
gives you the right to use as many certs and more as you conceivably
could use given the application to which you plan to put the sub-CAs.
Keeping count of actual certs issued would only add cost to both the
sub-CA customer and the root CA provider. There is simply no business
case for auditing the number of certs issued.

Presumably, if you bought a sub-CA for in-house use and then started
selling SSL server certs on the Internet, the root CA would complain,
but I have never seen such a silly violation of a sub-CA contract. If
you wanted to issue certs to the world, just execute a reseller contract.

Lastly, a brief comment on cost: some posts in this thread mentioned an
annual rate of USD 50k for a sub-CA. That number is indeed the rack rate
for an in-house sub-CA with unlimited cert issuance. (Well, technically
the contract will have a limit of the sum total of your employees,
servers, plus a generous buffer).

The smart purchasing manager will pay less than USD 50k. My advice to
customers that operate in-house sub-CAs has long been to renew in
mid-December or otherwise towards the end of the root CA's fiscal year.
At that time the rep will give you an unlimited certs sub-CA renewal at
USD 35k per year. If he balks, threaten to switch to one of the
competing root CAs. Depending on how far behind quota the rep is,
similar discounts might be had in the last week of each quarter.

(This end of fiscal year/end of quarter negotiation technique works with
many vendors, not just with root CAs).

--Lucky Green



More information about the cryptography mailing list