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

From: [email-masked]
Date: Thu, 29 Jun 2000 13:11:27 -0400

If the CP under which the CA operates says that it certifies identity and
binding of that to a public key, then that is all it does.   The validity or
security or accuracy, etc. of whatever service a business operates under that
identity (e.g., time sever, ocsp responder, web information server, etc.)  is
NOT what a CA "certifies."  So isn't the only "due-diligence" required of the CA
that of certifing the valid business identity and private key possession of the
public key bound into the certificate of the TSA?  The accuracy, availability,
etc. of TSA service is expressed in their own policy/contract with their
customers, just as is the privacy policy for a web server to which a CA issues a
certificate.
-GH

[email-masked] on 06/29/2000 11:40:43 AM

To:   [email-masked]
cc:   [email-masked] (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: AW: self-signed TSA [Was Re: Private Key Cloning]

> Why do you want to force me to figure out the OOB mechanism for every new
> 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: Rich Salz <[email-masked]>
Date: Thu, 29 Jun 2000 14:37:34 -0400

> binding of that to a public key, then that is all it does.

And that's pretty much indistinguishable from self-signed, no?
Actually, it's "less secure."  Self-signed is proof-of-possesion,
while the CA you describe means "I trust that you saw
proof-of-possesion."
	/r$

---

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

GHilborn wrote:

> customers, just as is the privacy policy for a web server to which a CA issues
> a certificate.

Well stated! I'm sure there are a number of web-based stores that Verisign
issued certificates to that are no longer in business. The same will happen
with TSAs, not all of them will exist after a few years (whether or not they
issued self-signed certificates).

Aram Perez

---

From: Tony Bartoletti <[email-masked]>
Date: Thu, 29 Jun 2000 14:44:03 -0700

>while the CA you describe means "I trust that you saw

Even a (supposed) CA that attests to POP is of no value if you
do not first (1) trust that CA, and (2) trust that you actually
have a certificate issued by that CA.

Both sides of this argument make good points in their isolation.
I must apply a (naive, dumb) usage example to clarify the issues
in my own mind.

I imagine some poor soul who discovers they must rely critically
upon a particular timestamped piece of data, the timestamp itself
a critical value.  While simultaneously demonstrating my ignorance
of the protocols and procedures that might be in place, I think I
am not too far off in recognizing that the following "logical"
operations must occur, in one or another order:

1.  Obtain a public key value for which the TS signature verifies.
     (Call this key the TS-Public).

     (This establishes that the signer, whoever in the world they
     might be), possessed the corresponding private key, and (we
     must assume) effected the TS signature.

2.  Obtain a certificate (self-signed or otherwise) that hopes
     to represent a binding of the TS-Public with a set of name-
     like attributes.  In our case, the name is "TS-R-US".

     (My boss TOLD me that TS-R-US is the TSA to trust.)
     So far, so good...

Now, what are the possible avenues of attack, for which either
"self-signed" or "CA-signed" is intended to be a better remedy?

In order for a fraud to be perpetrated, we assume it is the
fraudster who must have possessed and signed the timestamp.

An attacker, knowing our penchant to trust "TS-R-US", would
need to

a.  Create a TS-signing key pair (easy)

b.  Formulate a certificate attesting to the binding of this
     keypair with the name "TS-R-US", EITHER in self-signed
     fashion, or else by another ersatz key-pair/cert appearing
     as the (well-known;) CA "AnyCerts.com".

     (Yes, my boss SAID to trust "AnyCerts.com")

c.  Then (How?) circulate/distribute this/these certificates in
     such a fashion that the poor soul verifying the timestamp
     in question is sure to run across them first.

Of course, in the case of "AnyCerts.com", that certificate
is itself either self-signed, or invokes a further chain of
verification.  But eventually the buck stops.

Beyond the mere mechanics of verification, there must be an
established place where the buck is to stop.  That place
SHOULD be anywhere the RP chooses it to be, I would think.
After all, they are the Relying Party.  Similarly, each RP
will need to apply the "discovery procedures" that they feel
serve to satisfy their own operational and security needs.

In light of this, I am not convinced that any one "solution"
has a hands-down advantage for all reasonable use-cases.

Comments?

___tony___

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