RE: Private Key Cloning (TSA keys)

[Michael Zolotarev <mzolotarev@xxxxxxxxxxxxx>]

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
> 
>