Well I was aware of RA things where you do your own RA and on the CA side
they limit you to issuing certs belonging to you, if I recall thawte was
selling those. (They pre-vet your ownership of some domains foocorp.com,
foocorpinc.com etc, and then you can issue www.foocorp.com, *.foocorp.com ..
however you dont get a CA private key, you get web integration with the RA
so you dont have to do the email verification dance for each cert you
create).
Handing over a signed sub-CA is a much higher level of risk, unless perhaps
it has a constraint on the domain names of certs it can sign baked into it,
which is possible.
To hand over a blank cheque sub-CA cert that could sign gmail.com is
somewhat dangerous. But you notice that geotrust require it to be in a
hardware token, and some audits blah blah, AND more importantly that you
agree not to create certs for domains you dont own.
Start of the thread was that Greg and maybe others claim they've seen a cert
in the wild doing MitM on domains the definitionally do NOT own.
(The windows 2k box sounds scary for sure, and you better hope that's not a
general unrestricted sub-CA cert, but even then you could admit its similar
to the security practices of diginotar.)
Secure as the weakest link, and the weakest link just keeps getting lower.
It would be interesting to know if there really are CAs lax enough to issue
a sub-CA cert to a windows box with no hardware container for the private
key. (Not that it makes that much difference... hack the RA and the private
key doesnt matter so much).
The real question again is can we catch a boingo or corp lan or government
using a MitM sub-CA cert, and then we'll know which CA is complicit in
issuing it, and delist them.
Adam
On Fri, Dec 02, 2011 at 07:07:19PM +1300, Peter Gutmann wrote:
Ben Laurie <b...@links.org> writes:
They appear to actually be selling sub-RA functionality, but very hard to
tell from the press release.
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.
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".
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.
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).
This is why in the past I've repeatedly referred to "unknown numbers of
unknown private-label CAs", we have absolutely no idea how many of these
private-label CAs are out there or who they are or who controls them, but
they're probably in the tens, if not hundreds, of thousands, and many are
little more than a Windows server on a corporate LAN somewhere (and I mean
that literally, it was odd to sit in front of a Windows 2000 box built from
spare parts located in what used to be some sort of supplies closet and think
"I can issue certs that chain to $famous_ca_name from this thing" :-).
Going through the process is like getting a BS 7799 FIPS 140 certification,
you pay the company doing the work to get you through the process, and you
keep paying them until eventually you pass. The only difference is that while
I've heard of rare cases of companies failing BS 7799, I've never heard of
anyone failing to get a padlock-issuing license.
Are people really not aware of this? I thought it was common knowledge. If
it isn't, I'll have to adapt a writeup I've done on it, which assumes that
this is common knowledge.
Peter.
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
