RE: Private Key Cloning (TSA keys)

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

Simon,
(I'm taking luxury of being in the same time zone with you, so I can answer
the first :)

What you are saying is absolutely right, and technically I believe we all
know that it is more practical to clone the keys, than to come up with the
solution around it. But the argument has started as a result of the fact
that some legislations, namely German Digital Signature Law, prohibit key
cloning. So we've been discussing just one of the possible solutions to get
around the restrictions of the law.

I'm still not convinced, though, that the interpretation of the law is
correct. Taking your example with accelerator - would it be regarded as a
breach of the law? If not, and the accelerator is all right, what makes it
dramatically different from cloning the key in the environment which can be
formally certified as a security-equivalent to the accelerator's?

The law is written for general use, and each particular scenario requires
specific peruse. I'm wondering if we are trying to scare ourselves away even
before the law has a chance to "speak out". Would really like to hear from
anybody who has legal expertise and can provide an interpretation of the
German Law for that specific case.


Regards
Michael

> -----Original Message-----
> From: Simon McMahon [mailto:simon@onthenet.com.au]
> Sent: Wednesday, June 21, 2000 2:39 PM
> To: Michael Zolotarev; thayes@netscape.com; Paul Koning
> Cc: David P. Kemp; ietf-pkix@imc.org; Denis.Pinkas@bull.net
> Subject: Re: Private Key Cloning (TSA keys)
> 
> 
> 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
> > >
> > >
> >
>