Subject: RE: Private Key Cloning

From: Michael Zolotarev <[email-masked]>
Date: Tue, 20 Jun 2000 10:38:35 +1000

> 
> And it doesn't seem to present insurmountable obstacles to load
> balancing ... why shouldn't each server have its own signature key?
> Is there a reason not to use N certificates with identical
> distinguished names and different public keys?
> 

I can see a problem with it with self-signed TSA certificates. Normally, a
client would be configured to directly trust THAT [self-signed] TSA cert.
Having a set of self-signed TSA certificates would be a configuration
nightmare for the clients. And then you add another crypto box to your load
balancing array on TSS, and then another one...

M

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 20 Jun 2000 12:36:42 +0200

> balancing array on TSS, and then another one...

It is my understanding of the current draft that a TSA certificate can not be
self-signed :

2.3 :
The TSA MUST sign all time stamp messages with one or more keys
reserved specifically for that purpose.  The corresponding certificate
MUST contain only one instance of the extended key usage field
extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID
having value id-kp-timeStamping. This extension MUST be critical.

If the TSA is self-signed then the private key has been used for something else
than signing time stamp, and something it does not have the correct key usage
field for.

So if self-signed TSA certificate should be enabled, I think the wording of the
draft should be changed to specify this.

---

From: Paul Koning <[email-masked]>
Date: Tue, 20 Jun 2000 10:51:01 -0400 (EDT)

>>>>> "Michael" == Michael Zolotarev <[email-masked]> writes:

 >> balancing ... why shouldn't each server have its own signature
 >> key?  Is there a reason not to use N certificates with identical

 Michael> I can see a problem with it with self-signed TSA
 Michael> certificates. Normally, a client would be configured to
 Michael> directly trust THAT [self-signed] TSA cert.  Having a set of
 Michael> self-signed TSA certificates would be a configuration
 Michael> nightmare for the clients. And then you add another crypto
 Michael> box to your load balancing array on TSS, and then another
 Michael> one...

So have one of the copies self-sign its own key and in addition sign
each of the other keys.  Is there a problem with that?

     paul

---

From: [email-masked] (Terry Hayes)
Date: Tue, 20 Jun 2000 10:06:51 -0700

> each of the other keys.  Is there a problem with that?

I suspect that this would not be acceptable.  The draft indicates that TSA
keys should only be used for signing timestamps.  Your proposal allows
signing other keys (creating certificates) as well.

The best solution is to create a separate key that is trusted to create TSA
certificates and is used only for that purpose, or to get another (trusted)
CA to sign each of the TSA keys.

Terry