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

From: Michael Zolotarev <[email-masked]>
Date: Fri, 23 Jun 2000 13:39:15 +1000

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

I fully agree with that. 

Guys,

<< I feel that I've said all I had to say on the subject. In this mail I'll
try to put together a little summary of my position, which I know is
supported by a number of the list members. It was taking too much and too
long - this message will be the last from me on self-signed TSA certs (do I
see happy smiles :)? Denis, it is really up to you now - put it on vote, or
forget. >>

I (quite frankly) fail to understand the rational for the draft to introduce
limitations which necessitate extra entities and potentially more complex
environment for all involved parties. All for a sake of extra purity of a
concept, which is already pure enough. Probably my position is too much
'engineering', but this is what I am, sorry.

An example first:
Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy
a TSA service for its members. Would it be Ok that the members express their
trust directly to the TSA? I guess so.

With the client's trust expressed directly to the TSA cert, it is irrelevant
if the TSA cert was self-signed or CA-signed. Referring to the arguments in
favor of signing by CA - yes, I agree that there are benefits, thank you. It
is all perfect with the assumption that there IS a CA around, or at least a
business has a need for a CA. 

Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is
indeed :) why the organisation has to buy/setup/employ a CA, if everything
that they will ever need is just a TSA?

<< I know that the previous sentence may get me sacked from Baltimore, which
main business is selling CAs. :) So the standard disclaimer is right here.

Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the
one for distributing a CA's cert, should it exist. 

As a conclusion:
Using self-signed TSA certs should be an internal matter for each domain,
each TSA, subject to specific policy and national regulations. And a hell
lot more. Therefore, the draft should not encourage self-signed TSA certs,
neither it should prohibit them. It should be neutral and stay away from
that slippery subject.

And it is not far from what the current draft is about, as it seems. 

A minor fix- a sentence for the security considerations section would be
something like:
"The TSA private key must be generated and used ONLY for signing timestamps,
and possibly for internal key/certificate management operations such as
P-O-P or self-signing."

Best regards
Michael

---

From: Aram Perez <[email-masked]>
Date: Fri, 23 Jun 2000 21:12:36 -0700

Hi Michael,

If I take your statements/conclusions below to their extreme, then anytime
PKIX comes up with a new service that uses digital signatures, that service
would have to issue its own self-signed certificates. I don't see the OCSP
folks requesting their own self-signed certificates.

Regards,
Aram Perez

---

From: Rich Salz <[email-masked]>
Date: Sat, 24 Jun 2000 06:41:01 -0400

> folks requesting their own self-signed certificates.

Not HAVE TO issue, but COULD issue.  Most definitely.

---

From: "Peter Lipp" <[email-masked]>
Date: Sat, 24 Jun 2000 13:41:11 +0200

> Not HAVE TO issue, but COULD issue.  Most definitely.

Yes. And I could also issue my self-signed certificate, and you would have
less problems trusting me because you would not need to bother with the
obscure cert I might have from some CA service. Welcome to the PGP-model!

Peter

---

From: Aram Perez <[email-masked]>
Date: Sat, 24 Jun 2000 22:34:32 -0700

> Not HAVE TO issue, but COULD issue.  Most definitely.

So you want any user of a PKIX service to have to figure out a OOB mechanism
for each provider of the service to verify the self-signed certificate?

Regards,
Aram Perez

---

From: Rich Salz <[email-masked]>
Date: Sun, 25 Jun 2000 14:57:10 -0400

> for each provider of the service to verify the self-signed certificate?

Not at all.

I want it to be *possible* to start an independant PKIX service.

Let me turn the question around:  why do you feel it necessary to force me
to run a CA?
	/r$

---

From: Aram Perez <[email-masked]>
Date: Mon, 26 Jun 2000 06:43:50 -0700

Hi Rich,

> Let me turn the question around:  why do you feel it necessary to force me

I've never stated that I want you to run a CA for each PKIX service. I think
the issuance of certificates should be handled by a CA, not every PKIX
service that pops up.

Why do you want to force me to figure out the OOB mechanism for every new
PKIX service? You, most of the folks on this list and I may know how to do
that, but I doubt my mother or grandmother would know how to.

Regards,
Aram Perez

---

From: Rich Salz <[email-masked]>
Date: Thu, 29 Jun 2000 11:40:43 -0400

> PKIX service?

I don't.  I want it to be possible.  Surely you see the difference.

Without a self-signed cert, my service has to either
 1	Run a CA, doubling the amount of private key material I maintain; or
 2	Go to someone else's CA, who might be a competitor, and convince
	them to perform the due diligence necessary to certify me as a TSA; or
 3	Repeat step 2 with "every" CA a potential customer might know.

I don't believe it's reasonable claim that just because it's a CA, it is
qualified to certify TSA usage.  "Trusted to sign end-entitities without
these eKU values" is not a feasible trust model.
	/r$

---

From: Aram Perez <[email-masked]>
Date: Thu, 29 Jun 2000 12:40:31 -0700

Hi Rich,

> I don't.  I want it to be possible.  Surely you see the difference.

Yes I see the difference. But the more possibilities you have, the more
potential for security breakdown there is, i.e. someone doesn't do their due
diligence with the OOB mechanism.

> 1    Run a CA, doubling the amount of private key material I maintain; or

In my opinion, this should NOT be an option.

> them to perform the due diligence necessary to certify me as a TSA; or

This is the correct option. That is why they are in business: to certify
public keys. And any CA, whether or not it signs your TSA key and whether or
not a TSA can issue self-signed roots, is a potential competitor. Look at
all the non-CA things Verisign is doing now days. Besides, a CA should not
certify you as a TSA, it should certify your TSA public key. If I want to
use your service, I will not go to the CA that signed your key to determine
whether or not your TSA service is valid.

> 3    Repeat step 2 with "every" CA a potential customer might know.

I doubt your potential customers will want many CAs. Again, for every CA
they want, they have to have an OOB mechanism to validate the root
certificate.

> these eKU values" is not a feasible trust model.

See my comment under option 2.

Regards,
Aram Perez

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 29 Jun 2000 15:07:36 -0700

>they want, they have to have an OOB mechanism to validate the root

I don't think Rich meant that "a" potential customer may want to
employ many different CAs, but rather that he must deal with the
union of the set of CAs trusted by his set of customers, right?

Inescapably, there must be a good OOB procedure somewhere, but
each customer would need only the one of their choosing, and it
must be of their own choosing, of course, unless someone else
is willing to accept the liability of making that decision for
them (show of hands?)

___tony___

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 29 Jun 2000 15:31:06 -0700

>diligence with the OOB mechanism.

On Aram's side, I envision a large enterprise dealing routinely
with signature verifications of all manner.  In such a case, it
would certainly make sense to have the TSA key be similarly
certified, rather than invoking an additional OOB mechanism.

On Rich's side, I envision a dedicated operation that had purely
a need for a secured timestamp.  In any case, some TSA must be
independently trusted for this operation.  If the TS-client has
to form a secure OOB conveyance, and could do so directly with
the TSA, it does seem "unnatural" to require that they instead
seek a CA to trust, and require this TSA to have their key
certified by this particular choice of CA.

(Otherwise, their choice of TSA becomes restricted to those
whose keys have been certified by the "trusted" CAs, if any.)

Granted, for future RPs who need to make verifications, it is
a question of whether the TSA went out of business first, and
the CA second, or the TSA outlived the CA.  Are we betting on
relative longevity here?

___tony___

---

From: Aram Perez <[email-masked]>
Date: Thu, 29 Jun 2000 15:03:36 -0700

Hi Tony,

> union of the set of CAs trusted by his set of customers, right?

Yes that is correct. But that is the PKIX model.

> is willing to accept the liability of making that decision for

If you find that one OOB procedure, let me know. I far as I can tell, you
need a separate OOB procedure for every self-signed certificate. I raised
this issue quite a while back: try to find out the root certificate
fingerprints for Verisign, Thawte or any public CA and try to validate your
browser root certificates.

Regards,
Aram Perez

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 29 Jun 2000 17:32:53 -0700

>browser root certificates.

You are right there.  In general, our browser (or its distributor)
is the effective root of our trust.  What a thought.

Classic regress problem.  You want a secure channel in order to convey
the items that establish the security of another channel.  The only
channel that you can trust a priori is the channel that you have with
yourself, (hence the SPKI approach.)

Hypothetically, (assuming I just give up and assume that my browser's
root certs are "currently" valid,) I could create a self-signed root
cert, use it to certify all of the root-keys in the browser, and thus
establish myself as my (personal) root-over-them-all (solely to prevent
their tampering or replacement).  Beyond this, when I felt (for whatever
reason) that CA XYZ was no longer to be trusted, I would simply revoke
MY certification of their public key.  But what would be required to
make such processing occur (for what little comfort it might bring?)

How might I force all chains to reach for my root-cert as endpoint?

___tony___

---

From: Aram Perez <[email-masked]>
Date: Fri, 30 Jun 2000 07:59:09 -0700

Hi Tony,

> How might I force all chains to reach for my root-cert as endpoint?

The issue of how to trust anchor certificates (using my previously stated
definition of anchor certificates) is largely being ignored, either by
choice or by ignorance. There is no one OOB mechanism to solve this issue,
whether you are using PKIX, SPKI, PGP or any other PKI.

Regards,
Aram Perez