[528] in cryptography@c2.net mail archive
John Kelsey's post re Protocols Workshop
daemon@ATHENA.MIT.EDU (Hal Finney)
Mon Apr 14 12:00:36 1997
Date: Sun, 13 Apr 1997 22:27:45 -0700
From: Hal Finney <hal@rain.org>
To: cryptography@c2.net
John Kelsey's description of the protocols workshop was very interesting.
I had heard of one of the problems he mentioned with a different twist:
> Someone (I think some of the Cambridge people) raised this
> issue: Suppose the CA revokes your current certificate, issues
> you a new certificate, and signs a bunch of contracts with some
> friendly agency or company under your new key. This lets the CA
> have most of the benefits (for it, not for you) of escrowing
> your signing key. Their short answer to this problem was that
> revokations ought to require a different entity that
> certification, to divide up the powers necessary to do this
> among different groups of people.
The example I had seen was not a case of revocation, but rather a case
where a certificate with your name on a key has popped up from a CA you
never heard of. The CA claims that you did in fact authorize the cert,
but the paperwork was regrettably destroyed in a fire.... How do you
distinguish this from the case where you really did hire the CA, then
when the records were destroyed accidentally you realized you could
steal things using the key and hope to avoid responsibility?
I believe this was used as an example of the problems of multi rooted
CA hierarchies. In a strict Big Brother cog-in-a-machine hierarchy you
always know which CA is your parent in the tree, so you can watch it
and see what keys it is signing in your name, or have a policy that
you are only supposed to have one key at a time.
But with multiple CA's there is more to it than just controlling revocation.
> The invented-certificate attack is essentially the cryptographic
> equivalent of a bank opening an account in your name but without
> your consent, issuing checks, writing the checks to several
> people, bouncing the checks, and then having you hauled into
> court to make good on those bad checks.
I'm not sure this is exactly the same, because the bank can't forge
your signature. To be like the attack above, the bank would have to
open the new account using a signature completely different from yours
(like the CA which creates a new key). Then the checks are signed
using that same signature, and the bank justifies accepting the checks
because the signatures match that used to open the account. However this
now breaks down when you come in and show that none of these signatures
are yours.
In the CA example the CA is actually changing what "your signature" means,
by creating a new key which supposedly belongs to you. You can claim that
you've never heard of that key, but how can you prove it?
Hal
