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

From: Michael Zolotarev <[email-masked]>
Date: Thu, 22 Jun 2000 14:06:28 +1000

> 
> Michael wrote:
> >
> > If we forget for a moment about what the draft says 
> (please): what is
> wrong
> > with using a TSA key for signing 'something that is not a 
> time-stamp'? I
> do
> > not see anything criminal about that. Especially if the case is
> well-defined
> > and justified.
> >
> The draft obviously said it for a reason but to answer "what is wrong
> with using a TSA key for signing 'something that is not a 
> time-stamp'?"
> 
> 1.    Its good security policy to restrict usage of 
> particularly sensitive
> keys.
> 
Use a TSA key for signing timestamps and for signing a TSA's own certificate
is still within well-defined and restricted scope of use. The use of the key
IS STILL WELL RESTRICTED.

> The ultimate restriction is one exclusive use which is the 
> state of the
> draft now.
> You should show a very good reason to weaken that

Self-signed TSA cert is a very good reason to me.

> or show that the new usage has negligable impact. If you do this then an
attack on 
> certificate signing keys will be useful as an attack on time-stamp 
> signing keys since time-stamp signing keys can also sign certificates.

Do you mean that using a particular key to produce N signatures (timestamps)
as compared to producing N+1 signatures (timestamps and a self-signed TSA
cert) makes an attack any easier? I doubt it.

> 
> 2.    It couples the primary TSA service (making timestamps) with a CA
>         service (making certificates).
> 

Do not agree here. Issuing a self-signed cert by no means makes an entity a
CA. TSA does not become a CA, and it does not need to become one, simply for
the fact that it has a self-signed cert. No no no :).

> I'm not sure that the intention is for TSAs to always be CAs 
> or vice versa.
> If CAs and TSAs will be operated, managed and owned seperately then it
> is good that their services are not too coupled or intertwined.
> 
> Also, if TSAs will be subject to formal evaluation "torture" 
> then the less
> services and complications they include the less the torture 
> will be. Both
> uses of the private key, time-stamp signing and certificate 
> signing, will
> need to be evaluated.

Ok, lets go for it:
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.
2. Not self-signed TSA cert. You have to evaluate your secure timestamp
signing environment AND whatever mechanism you (or whoever else) employed to
issue TSA a certificate.

What is easier? (1) is sure looks simpler to me.

Regards
Michael

> Regards,
> Simon.

---

From: "Simon McMahon" <[email-masked]>
Date: Thu, 22 Jun 2000 18:28:08 +1000

> signing environment AND whatever mechanism you (or whoever else) employed
to

In both cases you will have to evaluate.
a.    Key generation - Output public key and private key pair.
b.    Secure private key storage.
c.    Public key distribution.
d.    Private key usage - input validation & signing.

a & b are the same for TSA types 1 & 2.

c1 - Public key goes into a cert encoding and is signed by the private key
(uses d1).
d1 - Sign timestamps, and sign encoded cert (from c1).

c2 - Public key goes to evaluated CA for cert encoding and distribution.
d2 - Sign timestamps.

I would suspect that type 1 TSAs will also have to support having their
public key certified by a CA which means that c2 applies to them also. A
type 2 TSA would not need c1.

just received :
> And yet another argument (as shyly suggested by Stephen Farrell) - in
order
> to get a TSA certificate from a CA, you may have to (as an obedient PKIX
> follower) sign the request (P-O-P stuff). Which means that the key, which
is
> otherwise 100% pure timestamping, will be still used for non-timestamping
> purpose. We are not going to prohibit the mechanism of POP, are we?

You are right. That means c2 includes generating a cert request and d2
includes self-signing the encoded cert request. The only difference now is
that type 2 TSAs includes self-signed certificate request encodings and type
1 includes them and self-signed certificate encodings also.

For an evaluated TSA I would push the self-signed cert-request (or cert)
into the Key generation operation. That way signing the cert-request could
not be classed as a form of run-time usage of the key and should not
conflict with the intended exclusive usage (signing timestamps) of the key.
If thats what you've been saying all along then I apolagise. You would not
be able to re-generate another self-signed cert later on though. Does that
matter ?

BTW The steps now become :

a.    Key generation - output self-signed cert-request (or cert) and private
key pair.
b.    Secure private key storage.
c.    Cert-request (or cert) distribution.
d.    Private key usage - input validation & signing.

Regards,

Simon.