[CLUE-Tech] signing CA private key with another CA?

[David Anselmi]

Jim Ockers wrote:

> Dave,
> 
> 
>>I don't think private keys get signed.  When you sign a public key, the 
>>result is a certificate.  Seems that you already know how to do that.
>>
>>There isn't any point to signing a private key.  You have one, it is 
>>only ever used by you.  If anyone else gets it, it is no good.
> 
> 
> The point to signing a private key would be so that the signature would
> carry forward onto public keys signed with that private key.

No.  You misunderstand signatures and certificates.  A certificate is 
your public key, plus your identity, signed (that is, encrypted) with a 
certificate authority's private key.  I can verify the signature (that 
is, decrypt it) with the CA's public key.  If it verifies, I know that 
the CA claims that you are the person identified in the cert, and that 
you posess the corresponding private key.

How do I know the CA's public key that I have really belongs to the CA? 
  Because it came installed in my browser (or I installed it after 
receiving it from a trusted source).

> Take a look at this document from Verisign:
> 
> http://www.verisign.com/repository/hierarchy/hierarchy.pdf
> 
> As you can see the main primary certificate authority certificates
> (public keys) are self-signed, using the associated private key of
> course.  These public keys are generally found in commonly used web
> browsers and other SSL client software.

Yes.  Thes are called root certificates.  The root public key and the 
root identity are signed by the root private key to create the cert. 
They are trusted by everyone because they come installed in your browser 
(because they are installed the browser trusts them, and you trust the 
browser people to have provided the correct certs).

> As you can also see, there are many other certificate authority
> delegations (public/private key pairs) in the Verisign hierarchy.
> Since the web browsers probably don't have all of the other
> certificate authority certificates (public keys) in their certificate
> stores, the only way for Verisign to delegate the authority of
> their private key to other certificate authorities would be to
> sign the delegated-CA private key.  Right?

This is called a certificate chain.  There is only one example that 
shows more than 2 levels of hierarchy, the class 2 employee (or 
contractor) CA.  So let's look at that.

An employee presents his cert and I need to verify it (the employee is 
the equivalent of a web server in this case and I perform the functions 
of a browser).

The employee cert is signed by the class 2 employee CA private key.  I 
verify it by checking it using the class 2 employee CA public key.  It 
verifies, but I don't trust the class 2 employee CA cert (it isn't 
installed in my browser).

Where did I get this CA public key?  Either the employee gave it to me 
with his cert, or I got it off a public server (the former probably, in 
the case of web server certs).  How do I know who it belongs to?  It 
comes wrapped in a certificate of its own.

Since I don't trust the class 2 employee CA cert, I verify it using the 
class 2 personnel CA public key.  Again, I got that and its cert from 
the employee.  The employee cert verifies but I don't trust the 
personnel cert either.

So I verify the personnel cert with the class 2 public primary CA public 
key.  I didn't have to get the primary CA cert from the employee, it was 
in my browser and I trust it (it is a root cert).

[...]
>>All you should need to do is issue a certificate for the new CA signed 
>>by the old CA.  Then use the new CA to issue certificates for other 
>>things.  Browsers et. al. will follow the chain of signatures to the top 
>>(the old CA) and all will be well.
> 
> 
> If I did this, the new CA certificate (public key) would then have the
> signature of the old CA's private key.  However, when the new CA issues
> certificates (signs other public keys), the signature on its public key
> has nothing to do with it.
> 
> My objective was to try to figure out a way to issue certificates with
> the new CA private key without having to update all of the web browsers
> and client software with the new CA's public key.  Even if the new CA's
> public key has the "right" signature on it, how would any old web
> browser know about that since the new CA's "public key" is not loaded
> in the web browser?

You make a certificate chain like the Verisign one above.  Your old CA 
cert is the root cert (self-signed, I assume).  Your new CA cert isn't 
self signed, it is signed by the old CA.  Your new server certs are 
signed by the new CA.  Browsers will verify your server certs with the 
new CA cert, they will verify the new CA cert with the old CA cert. 
They trust the old CA cert because you installed it in them.  You load 
the whole chain into your web server and it provides all the pieces to 
the clients.

Private keys are only ever used by the "person" to whom they belong. 
Since you're the only one who ever uses your private key, attaching your 
identity to it by signing it accomplishes nothing useful.  It is the 
public keys that the public uses.  The public needs to know who the keys 
  belong to.  The public, in checking identities only ever uses public 
keys (which are readily available because they are public).

[...]
> The only way I could think of to delegate the authority of the CA was
> to sign the private key of the new CA using the private key of the old
> CA.  I'm pretty sure this is how Verisign does it.  Do you still
> disagree?

Yes, I disagree.  Do you understand why?  If not, I guess I have to 
start from the top.

Here are the steps you need to take:

Create a certificate request for your new CA keys.  Generate a 
certificate for that request using your old CA key.

Create new keys for your servers.  Create certificate requests for your 
new server keys.  Generate certificates for your servers from their 
requests and your new CA key.

On each server, install its private key, its certificate, and the old 
and new CA certificates.

Try it out from one of your browsers that trusts your old CA.  It will 
not complain about the secure page it gets.  You will be able to examine 
the certs used to secure the page and you will see all three certs in 
the chain.

HTH,
Dave