[SSL Observatory] one-key-per-server tradeoffs [Re: SSL CA compromise in the wild]

[Daniel Kahn Gillmor]

On 03/23/2011 01:54 PM, Chris Palmer wrote:
> By standard security theory, identities are expensive. If you have 500
> identities, you don't have an identity. (This is The Citibank Problem,
> as discussed in my slides. Not all banks have this problem.)

I think you've mixed up "identity" with "certificate".  If i have two
passports, both with my name on them, each with different unique
identifiers (e.g. SSN, etc), i still have one identity -- myself.

Another view of identity is, for example, "senior marketing manager for
Example Corp".  There could be multiple people who hold this identity
legitimately.

Similarly, Citibank can reasonably have a dozen machines, each with
their own secret key material, each of which is properly identified as
"web server providing citibank.com".

There are tradeoffs involved with either the
one-key-shared-on-all-servers scheme or the one-key-per-server scheme.
One security advantage of the one-key-per-server approach is that it
becomes possible to use un-extractable keys, generated in hardware
designed to never produce the secret key material.

Such a key could not be stolen other than by compromise of the server on
which it resides.  As long as physical control over a machine is
maintained, you can put a stop to abuse of a compromised key simply by
turning it off, and not have to deal with the rest of the broken
revocation infrastructure.

There is no master copy of such a key that could get compromised and
cause a system-wide revocation event.

Anyway, i'm not arguing that this is the best solution to all problems,
or that it is not without its own set of tradeoffs.  But i don't think
you can completely dismiss this use case.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://lists.eff.org/pipermail/observatory/attachments/20110323/ddb8580f/attachment.sig>