Re: Private Key Cloning

[Mcken.Mak@xxxxxxxxxxx]

I agree on what you said.  We had done it different for the load balance, the
design is to us sub-CAs for the load balance, this may be more complex.  The
result should be cleaner and for better management for long term, since the
serial number and the DN will need special care after service for a while.

And as the sub-CA method do no need to clone the CA key at all.

Mcken Mak





ghilborn@csc.com on 06/19/2000 03:24:05 PM

To:   ietf-pkix@imc.org
cc:    (bcc: Mcken Mak/Technology/Equifax)

Subject:  Re: Private Key Cloning





The issue is relevant only for for a very basic PKI.  The wish is to have a
single trust anchor of one public key, no sub-CAs, yet assure availability and
load balance the CA service by cloned copies of the CA server (and its key).
This scenario pre-empts by definition each server having its own key.  However,
it also conflicts with the no-copy rule.
-Gene Hilborn




dpkemp@roadblock.missi.ncsc.mil on 06/19/2000 02:21:34 PM

Please respond to dpkemp@roadblock.missi.ncsc.mil

To:   ietf-pkix@imc.org
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: Private Key Cloning




> From: Paul Koning <pkoning@xedia.com>
> Date: Mon, 19 Jun 2000 10:48:17 -0400 (EDT)
> To: FRousseau@chrysalis-its.com
> Cc: brauckmann@trustcenter.de, ietf-pkix@imc.org
> Subject: Re: Private Key Cloning
>
> >>>>> "FRousseau" == FRousseau  <FRousseau@chrysalis-its.com> writes:
>
>  FRousseau> Juergen, If a private key generated within a hardware
>  FRousseau> cryptographic module is securely wrapped within that same
>  FRousseau> module, is then exported to another similar hardware
>  FRousseau> cryptographic module through an authenticated key exchange
>  FRousseau> where it is unwrapped and both of these private keys are
>  FRousseau> then used to perform electronic signatures in a load
>  FRousseau> balancing situation (e.g. OCSP or TSA server), do you mean
>  FRousseau> this would not be legal in Germany?
>
> How would you guarantee that there's no man in the middle?  The only
> way would be to have a prior out of band secure setup of
> authenticating data, such as a shared secret or public keys used for
> this key exchange process.  While the user of such a device can ensure
> that this is done right, the manufacturer of the devices cannot.
>
> It doesn't surprise me at all to see devices that don't allow this.
> It makes good security sense to omit such a capability.
>
>    paul


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?