Skip to Content.
Sympa Menu

cacert-policy - Re: [CAcert-Policy] How to deal with "cooperation" ?

Subject: Policy-Discussion

List archive

Re: [CAcert-Policy] How to deal with "cooperation" ?


Chronological Thread 
  • From: <Lambert.Hofstra AT ins.com>
  • To: <cacert-policy AT lists.cacert.org>
  • Subject: Re: [CAcert-Policy] How to deal with "cooperation" ?
  • Date: Mon, 28 May 2007 00:35:44 +0100
  • List-archive: <http://lists.cacert.org/cgi-bin/mailman/private/cacert-policy>
  • List-id: Policy-Discussion <cacert-policy.lists.cacert.org>


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").
??

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. As a result "X" can generate a valid cert allowing "X" to
impersonate "client". "X" can then sign a contract as "client".
One good thing: "X" cannot decrypt data encrypted with existing
certificates, "X" can only create new certs and sign as "client"

Case 2) must be split into two cases: 2a) where the public/private
keypair is generated by the CA, and 2b) where the public/private keypair
is generated by "client" (in for instance browser, webserver, or
smartcard)

Case 2a) When the public/private keypair is generated by the CA, there
is no way of telling that the private key is not "saved" (escrow.....??)
by the CA. A CA might be willing to work with "X" to hand over the
private key or the full certificate, because the damage is limited to
just one individual, not the full customer base. The interesting thing
here is that "X" not only has a certificate that allows him to sign as
"client" but is also capable of decrypting data encrypted by "client".
CA's that generate a public/private keypair therefore should be avoided

Case 2b) When the public/private pair is generated by "client" and only
the public part is sent to the CA for signing. This way "cooperation"
between "X" and CA or eavesdropping by "X" will not help since the
private key never left "client"


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?

Case 2a) if your CA has access to your private key you should not rely
on them in the first place, so no improvement here.

Case 2b) neither the CA nor anyone else but "client" has the private
key, so it's not going to help "client" to have the public key signed by
another CA. The only thing it could do is prove to you that "client" has
gone through the vetting proces twice (or more), and as such "client"'s
identity has been verified by multiple independent parties

Lambert

> -----Original Message-----
> From: 
> cacert-policy-bounces AT lists.cacert.org
>  [mailto:cacert-policy-
> bounces AT lists.cacert.org]
>  On Behalf Of Ian G
> Sent: 27 May 2007 12:33
> To: Policy-Discussion
> Subject: [CAcert-Policy] How to deal with "cooperation" ?
> 
> 
> 
> -------- Original Message --------
> Subject: A crazy thought?
> Date: Sat, 26 May 2007 17:58:50 -0700
> From: Allen 
> <netsecurity AT sound-by-design.com>
> To: 
> cryptography AT metzdowd.com
> 
> Hi Gang,
> 
> In a class I was in today a statement was made that there is
> no way that anyone could present someone else's digital
> signature as their own because no one has has their private
> key to sign it with. This was in the context of a CA
> certificate which had it inside. I tried to suggest that
> there might be scenarios that could accomplish this but was
> told "impossible." Not being totally clear on all the
> methods that bind the digital signature to an identity I let
> it be; however, the "impossible" mantra got me to thinking
> about it and wondering what vectors might make this possible.
> 
> Validating a digital signature requires getting the public
> key from some source, like a CA, or a publicly accessible
> database and decrypting the signature to validate that the
> private key associated with the public key created the
> digital signature, or "open message."
> 
> 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? Would you,
> could you trust a CA based in a country with a low ethics
> standard or a low regard for human rights?
> 
> Which lead me to the thought that if it is possible, what
> could be done to reduce the risk of it happening?
> 
> It occurred to me that perhaps some variation of "separation
> of duties" like two CAs located in different political
> environments might be used to accomplish this by having each
> cross-signing the certificate so that the compromise of one
> CA would trigger an invalid certificate. This might work if
> the compromise of the CA happened *after* the original
> certificate was issued, but what if the compromise was long
> standing? Is there any way to accomplish this?
> 
> Thoughts?
> 
> Best to all,
> 
> Allen
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo AT metzdowd.com
> 
> _______________________________________________
> 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




Archive powered by MHonArc 2.6.16.

Top of Page