Re: Private Key Cloning (TSA keys)

["Simon McMahon" <simon@xxxxxxxxxxxxxxx>]

Hi All,

I've been considering load balancing and Private Key cloning for another
project (not TSA) but a lot of the issues are the same. I think the problems
of messing with the client software to fix what looks to me like a server
problem is a bad idea. Anyway, here is my 2c worth.

Performance / availablilty is a problem that the TSA server has and load
balancing is one solution to address that problem. In my opinion any load
balancing scheme that impacts on the clients will not be very scalable or
interoperable and should be avoided. In other words cloning the private key
is necessary to do load balancing transparently to the client base.

The problem is legislation which boils down to "dont copy that private key".

However, if the cloned private keys were controlled in such a way that they
could not be seperated and used independantly outside a well defined
boundary, e.g. the TSA, couldn't they still be considered as one instance of
the private key since externally (to the TSA) there would be no way of
knowing that more than one copy exists within the TSA. The TSA would also
have to show that any loss or theft of any copy of the private key, for any
amount of time, is detectable and would result in revocation of that key.

As an extreme example - consider a hardware accelerator with two modular
exponentiation processors on board. The TSA application loads up one private
key but the accelerator splits it into two copies one loaded into each of
the processors. The TSA application then pumps signature requests at the
accelerator and has no control over which processor inside the device does
the operation. The accelerator offers no other services which would allow
either copy of the private key to be messed around with. If the accelerator
was evaluated to Fips 140, ITSEC, CC or whatever, then surely there would be
no problem with the legislation here.

Scaling that example up to physically seperate devices within a TSA might
require a security evaluation of the TSA, or at least that physical part tha
t includes the devices and management processes for them but wont TSAs need
to be evaluated anyway ?

Simon McMahon
ERACOM Pty. Ltd.

----- Original Message -----
From: Michael Zolotarev <mzolotarev@baltimore.com>
To: <thayes@netscape.com>; Paul Koning <pkoning@xedia.com>
Cc: Michael Zolotarev <mzolotarev@baltimore.com>; David P. Kemp
<dpkemp@roadblock.missi.ncsc.mil>; <ietf-pkix@imc.org>;
<Denis.Pinkas@bull.net>
Sent: Wednesday, 21 June 2000 13:21
Subject: RE: Private Key Cloning (TSA keys)


> Guys,
>
> Let's talk about one issue at a time.
>
> 1. Using self-signed TSA certs.
> The specifics of timestamping framework, in my opinion, make it perfectly
> normal and acceptable that a client would trust a TSA directly. A TSA can
be
> generally considered a TTP, with no pressing need to have a TSA cert
issued
> by other TTP (a CA). Consequently, there should be nothing  wrong in
having
> a self-signed TSA certificate. If the current draft precludes from doing
it,
> or makes the possibility of it confusing, I believe it should be fixed.
> (This is why I cc-ed Denis on this).
>
> 2. Assuming that using self-signed TSA certs is Ok, then we do have an
issue
> of handling an array of crypto boxes. The solutions for simplifying
client's
> side trust configuration proposed in the recent traffic were all about the
> same: making the TSA to allocate a dedicated "signing key", and to sign
the
> 'real operational' TSA certs with that key.
> I agree that this 'redirection' would simplify the client's side. The rule
> of trust for the client would be something like "Trust any TSA
certificate,
> signed by THAT key-signing cert".
>
> Note that this makes a TSA operating more like a mini-CA, signing the
certs
> for the keys it generates itself with yet another key it has [just]
> generated. This creates extra inconvenience for the TSA management - they
> would have to maintain a separate [and potentially secure]
> procedure/facility. Probably even having to allocate a different DN for
each
> of the 'operational' certificate as well? But this is not a huge issue -
who
> cares about poor system administrators :)?
>
> As a conclusion, I personally do not see any problems with that approach,
> and tend to agree that the problem of key cloning for TSA can be solved
with
> the 'redirection'.
>
> Regards
> Michael
>
>
>
>
> > -----Original Message-----
> > From: thayes@netscape.com [mailto:thayes@netscape.com]
> > Sent: Wednesday, June 21, 2000 3:07 AM
> > To: Paul Koning
> > Cc: mzolotarev@baltimore.com; David P. Kemp; ietf-pkix@imc.org
> > Subject: Re: Private Key Cloning
> >
> >
> > Paul Koning wrote:
> >
> > >
> > >  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?
> > >
> >
> > 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
> >
> >
>