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

From: Michael Zolotarev <[email-masked]>
Date: Thu, 22 Jun 2000 09:45:26 +1000

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

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.
Please do not mistake this with signing a timestamp with a 'wrong' key. That
would be just too bad.

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

Considering what I said above, we won't have to prove it at all.

> 
> 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... ?
> 
Under those circumstances a new key would need to be generated, most likely.

Michael

---

From: "Simon McMahon" <[email-masked]>
Date: Thu, 22 Jun 2000 12:51:06 +1000

> not see anything criminal about that. Especially if the case is
well-defined
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.

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

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

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.

Regards,

Simon.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 22 Jun 2000 10:12:00 +0200

> not see anything criminal about that. Especially if the case is well-defined

Maybe I did not express myself clearly enough.

I'm not convinced it's bad to issue self-signed TSA certificate.
I'm just saying it might not be a great idea.

I sure did not analyse the implication of that in every detail, and especially
the inconvenience not being able to issue self-signed certificate.

From what you say, it looks like it should be allowed, and then up to every TSA
operator to design his own policy with regard to using this possibility or not.

---

From: "Peter Lipp" <[email-masked]>
Date: Thu, 22 Jun 2000 11:24:15 +0200

> I'm just saying it might not be a great idea.
Agree. I don't see the big advantage. For one, if I want to trust a CA I
need to go through whatever steps are appropriate. If the CA
offers/recommends/uses a TSA, it can give me a certificate for the TSA and -
having already decided to trust the CA - it is simple to verify the
certificate and decide to trust the TSA too. So what does the self-signed
TSA cert buy me besides the need to go through the trust decisions again?
Now consider revocation - do you really suggest to set up a separate
revocation-scheme for the TSA? I simply don't see any advantage here...

Peter

---

From: Rich Salz <[email-masked]>
Date: Thu, 22 Jun 2000 09:48:59 -0400

> So what does the self-signed

You actually have *less* to trust if you have a self-signed TSA. Trusting
the CA means you trust all it signs.  Trusting the TSA means just and only
that.

	/r$

---

From: Aram Perez <[email-masked]>
Date: Thu, 22 Jun 2000 07:20:44 -0700

> the CA means you trust all it signs.  Trusting the TSA means just and only

I'm not sure I understand your statement of having "*less* to trust". To
trust a self-signed certificate (no matter if it is from a CA or TSA), you
have to have an out-of-band mechanism to verify that the self-signed
certificate is valid. One of the nice features of a hierarchical PKI is that
I can limit the number of times I need the out-of-band mechanisms to verify
self-signed certificates.

If I don't want to trust the self-signed certificate of a CA that signs a
TSA, then I can use the out-of-band mechanism to verify the TSA's
certificate (that was signed by a CA) and treat it as an "anchor
certificate". My definition of an anchor certificate is a certificate I
implicitly trust because I have used an out-of-band mechanism to verify it.
When I'm validating the certificate chain, I stop whenever I reach an anchor
certificate (whether or not it is self-signed).

Regards,
Aram Perez

---

From: Stephen Kent <[email-masked]>
Date: Thu, 22 Jun 2000 10:39:16 -0400

Folks,

I support Denis's original restriction on the uses of a TSA private 
key.  It is desirable to constrain the use of a private key to avoid 
possible errors in its use.  It seems that we have gone down a thread 
that focuses on certificates for a TSA, more than on the original key 
usage restriction.

I've always asserted that self-signed certs are just a syntactic 
convenience, not a generally useful way of ensuring security for 
transmitted public keys.  If we agree on that point, then I don't see 
a lot of reason to push for self-signed TSA certs.  A TSA is not a 
CA.  Even if the same organization happens to operate both a CA 
function and a TSA function, it seems appropriate to separate these 
functions. That's part of why we have the proposed constraint for 
using the TSA private key only for signing TSA responses. It was 
suggested that this is not consistent with the use of POP.  True, but 
only in so far as the POP in question is the one defined in our 
automated registration protocols.  Thus is not the only game in town, 
and for a TSA it is reasonable to anticipate other mechanisms that 
provide POP, but not via those protocols.  So, I don't think that the 
POP argument is a good basis for rejecting the key usage restriction.

The "less to trust" argument that Michael makes does have some merit, 
but as Aram points out, a self-signed cert required some 
integrity/authenticity secure, OOB means for its delivery, which is 
why we try to minimize the use of such certs.  It seems hard enough 
to do this for CAs, without adding TSAs to the list. Let's assume 
that TSAs are certified like other entities, by CAs, and work from 
there.

Steve

---

From: Rich Salz <[email-masked]>
Date: Thu, 22 Jun 2000 11:45:52 -0400

> I'm not sure I understand your statement of having "*less* to trust".

Sorry, poorly worded.

If I trust the CA that certifies a TSA, then aren't I (by default, and
certainly by philosophy) trusting EVERY certificate that CA issues?
Why should I have to?
	/r$

---

From: Aram Perez <[email-masked]>
Date: Thu, 22 Jun 2000 10:05:12 -0700

> that TSAs are certified like other entities, by CAs, and work from

Well put Steve, I fully support this position.

Regards,
Aram Perez

---

From: Aram Perez <[email-masked]>
Date: Thu, 22 Jun 2000 10:09:12 -0700

> certainly by philosophy) trusting EVERY certificate that CA issues?

You shouldn't have to, although this is the model that most public CAs seem
to push and/or encourage. As I mentioned, a possible solution is the the use
of "anchor certificates".

Regards,
Aram Perez

---

From: Rich Salz <[email-masked]>
Date: Thu, 22 Jun 2000 21:24:04 -0400

> of "anchor certificates".

Seems a little complicated.

I don't see why I have to introduce an extra entity involved, or extra certs
involved.

Stephen Kent:
> a lot of reason to push for self-signed TSA certs.

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.

We don't need to "push" anything.  We need to not prohibit it.
	/r$

---

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Jun 2000 17:04:53 -0400

Rich,

><snip>

You don't agree with what, the assertion about syntactic convenience? 
I don't think it's much easier to manage one private key vs. two when 
you have to distribute one key visa OOB means in either case. It is a 
lot cleaner, and it provides a straightforward revocation mechanism 
for the TSA key, even allowing delegation to an OCSP server without 
further violating the notion of what a TSA should be used to sign.

Steve