On 2011-12-03 10:44, Kevin W. Wall wrote: > On Fri, Dec 2, 2011 at 1:07 AM, Peter Gutmann <[email protected]> > 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 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
