Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]

From: Michael Zolotarev <[email-masked]>
Date: Fri, 23 Jun 2000 14:28:26 +1000

> 
> > From: Michael Zolotarev <[email-masked]>
> >
> > 1. Self-signed TSA cert. You have to evaluate your secure signing
> > environment. Which is the same for generating timestamps 
> and for generation
> > a self-signed cert.
> 
> What security-relevant information are you expecting clients to derive
> from validating the signature of a self-signed cert?
> 
A client would not validate a self-signed cert - it would have to be trusted
directly, as an anchor. Distributed and cjecked out-of-bands. Why the
question?

> Do you expect clients to have trusted storage which could 
> hold a bare TSA
> public key, but which could not hold the entire self-signed 
> TSA cert???
> 

No, I do not. The clients would store the entire self-signed cert.

Aha, I see it now: phrasing in (1) could be misleading. The signing of the
self-signed certificate is not critical, as the cert must be validated
out-of-band anyway. You only need to evaluate your secure key generation
environment, and the security of key storage and the crypto engine used for
signing timestamps.

But the argument still stays: using self-signed certificate does not
necessarily make the formal security evaluation process of a TSA any more
difficult, compared to having the TSA cert signed by a CA.

Regards
Michael

---

From: "Simon McMahon" <[email-masked]>
Date: Fri, 23 Jun 2000 15:36:22 +1000

> directly, as an anchor. Distributed and cjecked out-of-bands. Why the
Why should the TSA self-sign this cert if no client will ever check the
signature ? This cert could be signed by any private key and the client
would not know since it trusts it directly and does not verify the sig.
Would you really abuse the usage constraints on a timestamping key to make a
signature that nobody needs to verify ?

The TSA may as well use another key-pair that it generates to sign this
cert. It can then make a normal self-signed cert with this new key pair that
will not sign timestamps.

Then clients who will not check the TSA cert's signature can just install
and trust the TSA cert (not self-signed). Clients that insist on checking
signatures on trusted and/or self-signed certs can install both certs then
trust the self-signed cert (not the TSA cert) as if it was from a real CA.

The TSA is effectively has its own mini CA and will only certify its own
time-stamping key pair. Its hardly a full blown CA with all the costs that
go with them. You could leave out the possibility of revocation etc. and you
would be no worse off than the self-signed TSA cert scenario.

>
> I don't agree.  As the service provider, why do I *have* to deal with
> the management of two private keys.  It's way more than syntax.
>
Because you are trying to do two things with one key. Producing timestamps,
and trusting them. You are still *having* to deal with these two seperate
processes the difference is with one key or with two.

If your clients dont check the trusted TSA cert's signature then you fall
back to only needing one key.

Simon.