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

From: Michael Zolotarev <[email-masked]>
Date: Wed, 21 Jun 2000 15:23:49 +1000

Jean,

My interpretation of the current text is:
The text mandates that a timestamp token can be only signed with a specific
'timestamping' key, as indicated by the ExtKeyUsage. A timestamp token
signed by a key which does not contain that ExtKeyUsage field must be
considered invalid. However, it does NOT necessarily say that the same
'timestamping' key can not be used for signing whatever else, for example a
certificate. 

So, I can not see anything in the current text that would prohibit issuing a
self-signed TSA certificate.

However, I'd suggest that the draft makes it clearer, by adding a comment
(in a security section?) about possibility of generating and using
self-signed TSA certificates.

Regards
M

> -----Original Message-----
> From: Jean-Marc Desperrier [mailto:[email-masked]]
> Sent: Tuesday, June 20, 2000 8:37 PM
> To: [email-masked]
> Subject: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> Michael Zolotarev wrote:
> 
> > I can see a problem with it with self-signed TSA 
> certificates. Normally, a
> > client would be configured to directly trust THAT 
> [self-signed] TSA cert.
> > Having a set of self-signed TSA certificates would be a 
> configuration
> > nightmare for the clients. And then you add another crypto 
> box to your load
> > balancing array on TSS, and then another one...
> 
> It is my understanding of the current draft that a TSA 
> certificate can not be
> self-signed :
> 
> 2.3 :
> The TSA MUST sign all time stamp messages with one or more keys
> reserved specifically for that purpose.  The corresponding certificate
> MUST contain only one instance of the extended key usage field
> extension as defined in [RFC2459] Section 4.2.1.13 with KeyPurposeID
> having value id-kp-timeStamping. This extension MUST be critical.
> 
> If the TSA is self-signed then the private key has been used 
> for something else
> than signing time stamp, and something it does not have the 
> correct key usage
> field for.
> 
> So if self-signed TSA certificate should be enabled, I think 
> the wording of the
> draft should be changed to specify this.
>

---

From: "Peter Lipp" <[email-masked]>
Date: Wed, 21 Jun 2000 14:24:06 +0200

> However, it does NOT necessarily say that the same
> 'timestamping' key can not be used for signing whatever else, for
> example a certificate.

Looking at the current draft it sais:

A TSA is REQUIRED ...
10. to sign each time stamp token using a key generated
         exclusively for this purpose and have this property of the
         key indicated on the corresponding certificate.

I read "exclusively for this purpose" as "not allowed for signing
certificates".

Peter

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Wed, 21 Jun 2000 15:49:03 +0200

Peter Lipp wrote:

> Looking at the current draft it says:
>
> A TSA is REQUIRED ...

I wrote another answer before, but it seems I have sent it to Michael
Zolotarev instead of to the list.

It seems that the beginning of 2.3 and point 10 of 2.2 are a rewording
of each other.

After rereading, paragraph 2.3 does not explicitely forbid keyCertSign
to be asserted, as this is a key usage bit, and not an extended
keyusage.
This said, if we take into account point 10, it sounds like this key
usage bit should not be asserted.

It would more explicit to have a list in the draft of the key usage bits
that must/musn't be asserted.

The message about the use of "certificates as trust anchor" suggests
that it should not be necessary that the key usage bitfield of a
self-signed certificate has the keyCertSign set for it to be accepted as
a trust anchor.
This seems to me to make sense.

But from a practical point of view what does self-signed TSA cert means
?
That there has been at least one point of time where your TSA hardware
crypto module has been able to sign something that is not a time-stamp.
I think that if a TSA is under a formal evaluation process, it will have
to prove it's "impossible" to get it to sign something that is not a
valid time stamp.

Of course, the signing of this certificate would be done in an initial
step, before the hardware crypto module is inserted inside the actual
TSA operation process, but it does not sound that great.
Also couldn't there be circonstances, where we would have to generate a
new certificate, if the policy changes, etc... ?