Policy-Discussion

[Ian G <iang AT systemics.com>]

Hi Lambert,


Lambert.Hofstra AT ins.com
 wrote:
> I'm not sure I understand the question but I'll try to answer. Are we
> talking about someone (large company, government, an individual, let's
> call this someone "X" for now) getting access (through whatever means,
> technical or other) to
> 1) the CA private key, or
> 2) someone's private key ("client").
> ??


I think it is more likely the former.  That also can be cast 
into two parts:

1a) getting the root private key
1b) getting a way to use the root (without seeing it)

A thought experiment for CAcert is how we deal with those 
two cases.

1a is easy to talk about at least, that's the basic security 
model of the signing setup.  1b is harder.  How do we stop a 
covert signing path into the CA?


> Case 1) should (!!!) be impossible (and is unlikely): from the moment on
> the private key is compromised the CA is out of business: all
> certificates from that moment on are void, since someone else ("X") can
> create digital signatures thereby capable of impersonating anyone and
> anything.


That all assumes that once the key is compromised, we know 
it has been compromised :)  An attacker is more likely to 
try and keep the compromise secret, as it is then more 
valuable.  A known compromise triggers the compromise 
response as you outlined, and that limits its usefulness.

So one defence is to make secret compromise convert into 
open compromise.


> As a result "X" can generate a valid cert allowing "X" to
> impersonate "client". "X" can then sign a contract as "client".


Signing for contracts is something that should be covered in 
the CPS.  Right now, the CAcert draft CPS doesn't support that.

If contract signing were covered in the CPS, then, we would 
need to resort to the meaning and import of the signature. 
As an extreme case, let's look at the German view of 
Qualified Certificates.  In this case, if signed, the 
signature is equivalent under law to the human's signature. 
 So "client" is bound to the contract, and it enters into 
court.  "Client" suffers the entire loss.

That has the benefit of certainty, at least :)


> One good thing: "X" cannot decrypt data encrypted with existing
> certificates, "X" can only create new certs and sign as "client"


Possibly ... Existing data might not be decryptable, but 
MITMs would be possible.  So the attacker still has to 
conduct an (expensive) active attack, this is not a 
cost-free situation to the attacker.

(I'll leave aside your case 2, but only for brevity.)


> Now back to your question: would it make sense to have your cert signed
> by 2 or more CA's?
>
> Case 1) In the case that a new cert is generated by "X" for "client",
> "X" would have a cert that is not cross signed by the other CA, so yes,
> this seems to work. A third party can validate that this new cert is
> only signed by the first CA. However, it does not prove that the private
> key of CA has been compromised: "client" could also generate two certs,
> have the first one signed by two CA's, and the second by one, and have
> someone use that one. How can a CA prove that this is the case instead
> of a compromise of their own private key?


Hmmm, so that is a technical difficulty, in that if we did 
this to prove that a CA root is not compromised, we would 
need to have some dual-signing protocol that ensured that 
only dual-signed certs were allowed.

I think a more practical issue might be that it is hard to 
get two CAs to cooperate to the extent that they can take on 
each other's risks.

Thanks for your answer!  Actually your answer suggested to 
me that what Allen was talking about was Web of Trust. 
Before that, I couldn't quite figure out where he was going!

iang