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

From: [email-masked]
Date: Wed, 21 Jun 2000 10:37:13 -0400

Jean-Marc Desperrier wrote:

[snip]
>
> Also couldn't there be circonstances, where we would have to
> generate a new certificate, if the policy changes, etc... ?

In addition, a TSA private key would eventually expire.

When a TSA using a self-signed certificate has to update its key pair, would
it also have to generate three (3) certificates (i.e. the OldWithNew,
NewWithOld and NewWithNew TSA certificates) as per Section 2.4 of RFC 2510?

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
[email-masked]      Tel. (613) 723-5076 ext. 419
http://www.chrysalis-its.com     Fax. (613) 723-5078

---

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

I see. But do you think that the requirement should be loosen up a bit, in
order to accommodate self-signed certificates?

> -----Original Message-----
> From: Peter Lipp [mailto:[email-masked]]
> Sent: Wednesday, June 21, 2000 10:24 PM
> To: Michael Zolotarev; Jean-Marc Desperrier; [email-masked]
> Subject: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> > 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: Michael Zolotarev <[email-masked]>
Date: Thu, 22 Jun 2000 17:03:46 +1000

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?

M

> From: Simon McMahon [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 12:51 PM
> Subject: Re: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> 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.
> 
> 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: Michael Zolotarev <[email-masked]>
Date: Thu, 22 Jun 2000 18:52:47 +1000

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

Well, that would probably matter when a current certificate expires and you
need to issue another certificate.
Do you mean that logical(!) definition of Key Generation operation can not
embrace re-issuing a certificate with the same value of the key? Why not? I
think we'd be able to defend it for the evaluation. It is not part of the
run-time usage (a tick box here), the key was not compromised (a tick box
here), a new certificate is issued following the same (already evaluated)
procedure as the very first one (a tick box here).
Do not think it would be a problem, in general.

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

---

From: "Meggison, Tim" <[email-masked]>
Date: Thu, 22 Jun 2000 08:24:54 -0400

I believe the key word in Simon's email is policy.  
What is good policy for one situation is overkill for another.
I suggest the spec should be limited to technical and interop requirements,
and leave policy decisions to actual implementations.

> Sent: Wednesday, June 21, 2000 10:51 PM

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 22 Jun 2000 16:34:01 -0400 (EDT)

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

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

---

From: Frank Balluffi <[email-masked]>
Date: Fri, 23 Jun 2000 06:20:05 -0700

According to RFC 2459 and draft-ietf-pkix-time-stamp-08.txt, the decision of
how to terminate the most-significant end of a certificate path and obtain
the most-trusted public key is up to you (i.e., is a matter of policy).

I recommend that section 2.4.1 of draft-ietf-pkix-time-stamp-08.txt point to
section 6.1 of RFC 2459 with something like:

For more information about validating the certificates in the certificates
field of the SignedData structure and obtaining the most-trusted public key,
see RFC 2459, section 6.1.

The relevant text follows.

Frank

<relevant-text>
RFC 2459, section 6:

This text assumes that all valid paths begin with certificates issued by a
single "most-trusted CA". ... The "most-trusted CA" is a matter of policy:
it could be a root CA in a hierarchical PKI; the CA that issued the
verifier's own certificate(s); or any other CA in a network PKI.

RFC 2459, section 6.1:

The text assumes that the trusted public key (and related information) is
contained in a "self-signed" certificate. This simplifies the description of
the path processing procedure.  Note that the signature on the self-signed
certificate does not provide any security services.  The trusted public key
(and related information) may be obtained in other formats; the information
is trusted because of other procedures used to obtain and protect it.

draft-ietf-pkix-time-stamp-08.txt, section 2.4.1

If the certReq field is present and set to true, the TSA's public key
certificate that is referenced by the ESSCertID attribute in the response
must be provided by the TSA in the certificates field from the SignedData
structure in that response. That field may also contain other certificates.
</relevant-text>

> From: Michael Zolotarev [mailto:[email-masked]]
> Sent: Thursday, June 22, 2000 10:02 PM
> To: Peter Lipp; [email-masked]
> Subject: RE: AW: self-signed TSA [Was Re: Private Key Cloning]
> 
> 
> I guess the problem is a common misconception that a TSA is always a
> subsidiary/sub-service of a CA. Not necessary. TSA is/can_be 
> a service on
> its own, with no inherited relationship to any CA at all.
> 
> So when NIST starts offering TSA services, it would have to get a
> certificate from some CA? Why? Why wouldn't you trust their 
> TSA certificate
> directly?
> 
> 
> > Sent: Thursday, June 22, 2000 7:24 PM
> > To: [email-masked]
> > > I'm not convinced it's bad to issue self-signed TSA certificate.
> > > 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: Peter Sylvester <[email-masked]>
Date: Fri, 30 Jun 2000 09:51:15 +0200 (MET DST)

Currently a CA can have several key usages indicated in its
cert (or in some cert given to it) EXCEPT you can newer use
a CA key for time stamping. 
 
Why is it that a TSA needs a more restrictive handling than a CA?

> 
> I envisage you saying that an average client is a no-brain moron (NBM) with
> a tendency to trust anybody, and it is our sacred mission to protect them.
> Well - doesn't the same argument apply to a NBM using "any public CA", which
> did not happen to be pre-loaded into IE5? Please, be consistent - once you
> start talking about NBMs, there is no difference between self-signed CA cert
> and self-signed TSA cert. As for non-NBM, we should have some kind of
> reliance into OOB and general intellegence of the clients (not a very
> technical argument though, I admit :)
> 
> Michael