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

From: Michael Zolotarev <[email-masked]>
Date: Fri, 30 Jun 2000 16:57:31 +1000

God knows I was trying hard to stay away from it :)
> > 
> > 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?)
> 
> 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.

So you are saying that we must prohibit self-signed TSA certs for the lack
of practical and reliable OOB mechanism? That seems to be the root of the
problem to me.

Well, the same argument would have to apply to the most of self-signed PKI
then, as your experience with Verisign and Co rightly shows.
Following the same logic - should we temporary freeze everything, 'till
there is an OOB that we all agree to trust?
And consequently shut those authorities that do not seem to provide adequate
OOB (or so we reckon)? Who should we start with? any suggestions?

Out of the bitchy mood now.

If my clients community decides that my OOB is adequate - why should you
stop my clients from exercising their trust? On the other hand, if a client
decides that my OOB is NOT adequate - it is his/her right not to use my
services.

I just don't see why is it of any concern for us.

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

---

From: Aram Perez <[email-masked]>
Date: Fri, 30 Jun 2000 08:34:55 -0700

Hi Michael,

> God knows I was trying hard to stay away from it :)

You can't keep a good man away for long ;-)

> of practical and reliable OOB mechanism? That seems to be the root of the

That's partially true, but more to the point, this is PKIX, where, by
definition (whether we like it or not), CA issue certificates.

> OOB (or so we reckon)? Who should we start with? any suggestions?

As I stated to Tony B., the issue of trusting anchor certificates is largely
being ignored, by choice or ignorance. That does not mean that you must
freeze everything. Right now the obvious OOB mechanism seems to be the NULL
one: don't do an OOB validation. Most folks obviously trust Microsoft and
Netscape. If you are satisfied with not doing an OOB validation or trusting
in Microsoft and Netscape, then continue with the status quo.

> decides that my OOB is NOT adequate - it is his/her right not to use my

You are right that the clients (and/or relying parties) have the right to
trust or not to trust any particular service. But should be make it harder
for them to make that decision?

> I just don't see why is it of any concern for us.

I would hope that one of the purposes of defining standards is to make it
easier and safer to implement and use, and hence our concern.

> a tendency to trust anybody, and it is our sacred mission to protect them.

Yes, I do believe that we, as non-NBM and security experts, do have some
moral responsibility to the NBM to make their use of our systems as easy and
safe as possible.

> did not happen to be pre-loaded into IE5?

Yes it does, and look at the problems that were caused when all those
pre-loaded certs expired on December 31, 1999.

> Please, be consistent - once you

I am trying to be consistent with respect to PKIX. In PKIX, by definition
and whether we like it or not, only CAs issue certificates, not any new
service that comes along and wants to issue a self-signed cert for itself.

The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP
or whatever.

Regards,
Aram Perez

---

From: Tony Bartoletti <[email-masked]>
Date: Fri, 30 Jun 2000 11:26:08 -0700

>The OOB validation issue applies to any PKI, whether it is PKIX, SPKI, PGP

Aram,

I do appreciate the sentiment that standards should avoid making it
default for people to ignore safety (though there may be a limiting
tradeoff between "easy" and "safe".)

At the very real risk of appearing ignorant, I must ask "What does it
take to be a PKIX CA?"  Not a big CA, or for-profit CA, or even a
trusted CA, but simply a (minimally) PKIX-compliant CA.  Does the
PKIX standard mandate social compliance in addition to protocol?

If, as you describe, the current tack taken by most folks regarding
the validation of root-certs is the "Null Option", then it cannot be
worse to allow individuals to create their own self-signed anchor,
and "certify" these foreign root-certs as they please.  The software
should comply (that "easy" goal) and I cannot see where safety is
reduced in the process.  Functionally, it is not far from simply
encrypting your browser's root-certs, and having it prompt you for
a pass-key at each root-cert usage.  It provides both tamper-detection
AND control over the otherwise "automatic" trust assumption.  The
self-signed anchor approach has the advantage of not bothering you
when you choose not to be bothered.

I recognize that by allowing individuals to create self-certs, and
then to "personally certify" (say) Verisign's public key, there is
nothing to stop them from performing other mechanical CA functions.

They can certify other keys.  And other parties can rely upon that
certification at their benefit or at their peril.

The alternative is to make the very "existence" of a root-cert
become the evidence of its trustworthiness.  That is, "Only Real
CAs can issue certs, and this is a cert, thus it is trustworthy."
Building such associations into the (expected) protocol mechanics
of PKIX compliance does not serve the cause of safety.

IMNSHO, ALL trust calculation should occur over the *nature*
of the content, none over the mere existence of the content.

Only CAs can issue certificates? Fine. Let there be a billion CAs.

Let "trust imply useful-CA", not "CA imply useful-trust".

( shades of Ed Gerck there :)

Bitwise, OOB appears hopelessly problematic.  It demands prerequisite
trust in a channel that cannot be secured computationally.  (Even the
promise of an inviolably tamperproof quantum cryptographic channel
will not serve to establish the identity of the party at the far-end
without a previous agreement on a uniquely produceable signature.)

Perhaps OOB security can be approached only "statistically", akin to
those web sites where each visitor "ranks" the postings they read,
and the most popular posts rise to the top.  (In retrospect, we have
something "like" that already.  The "popularity" of IE and Netscape
largely dictate the population of extant root-certs.  Unfortunately,
it is a peculiar sort of trust association, subject to "revocation"
at the next software release, and not reflective of daily utility.)

___tony___

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