Policy-Discussion

[<Lambert.Hofstra AT ins.com>]

Ian wrote:
> 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.

I think the original question was not regarding an attacker, but some kind of 
"voluntary" sharing of key data:
The original email stated:
> Which lead me to the thought of trust in the repository for
> the public key. Here in the USA, there is a long history of
> behind the scenes "cooperation" by various large companies
> with the forces of the law, like the wiretap in the A&TT
> wire room, etc.
>
> What is to prevent this from happening at a CA and it not
> being known for a lengthy period of time? Jurors have been
> suborned for political reasons, why not CAs? 
 
So my answer is based on: what if a CA in general (not just CAcert) is 
somehow forced to hand over their private key or private keys of specific 
users to the authorities to help fight terrorism or money laundering or 
whatever ("behind the scenes "cooperation" by various large companies with 
the forces of the law")? Or one of the employees of a CA is sharing data with 
a friend in another company, in return receiving certain benefits?
 
Lambert

________________________________

Van: 
cacert-policy-bounces AT lists.cacert.org
 namens Ian G
Verzonden: ma 5/28/2007 15:45
Aan: Policy-Discussion
Onderwerp: Re: [CAcert-Policy] How to deal with "cooperation" ?



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
_______________________________________________
Have you subscribed to our RSS News Feed yet?

CAcert-Policy mailing list
CAcert-Policy AT lists.cacert.org
http://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy

<<winmail.dat>>