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

["Simon McMahon" <simon@xxxxxxxxxxxxxxx>]

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

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.