Subject: Re: Common misconceptions, was Re: KISS for PKIX, was ...

From: "David P. Kemp" <[email-masked]>
Date: Fri, 16 Jul 1999 14:35:45 -0400 (EDT)

> From: Ed Gerck <[email-masked]>
>
> The "harder and harder to do" is what makes a certificate not bind to a user 
-- and even
> if you have all proper papers in notarized copies you still do not know.  And, 
BTW, just
> read any CA warranty and you will see they also do not know and they say so -- 
"NO
> WARRANTY, NO SUITABILITY OF PURPOSE".

Novell recently briefed the Federal PKI Technical Working Group
(http://csrc.nist.gov/pki/twg/welcome.html) on the results of their
requirements discussions with business users.  One notable conclusion
is that PKIs will have "made it" when they become insurable (i.e. when
it becomes possible to quantify risk reliably enough to make meaningful
warranties).  Since business relying parties require a guarantor to have
deep enough pockets to make any judgements for breach of warranty
collectable, it follows that the only warranties that will be made by
any organization with substantial assets are against quantifiable,
controllable, insurable risks.  A proposed approach to allocating
liability included a root CA operated by an organization with huge
assets (such as a commercial bank) but with only two warranted
responsibilities: 1) ensuring name uniqueness across the certs issued
by that CA, and 2) protecting the CA's private key.  (A third,
unstated, requirement would be to use sufficiently conservative
cryptography for signatures on the issued certs).

> Surely, you can rely on a certificate but only to the extent that it is 
warranted by the issuer.
> But, you will not find a CA that does that without caveats that any fraudster 
case will fall
> into and thus invalidate the assurances.  And, the CAs are right -- it cannot 
be warranted
> that  a certificate binds to a user. This alone already shows in the practice 
what I tried to
> explain.

You (as a relying party) can rely on a certificate to any extent you
wish.  A CA may warrant that it follows certain practices; it may also
warrant results, as with the hypothetical root CA above, if the amount
of loss and the risk of loss can be quantified.  You, the relying party,
assume all risk not assumed by the CA.  You are the sole judge of whether
the PKI provides a benefit - whether profit from transactions enabled
by the PKI minus expected losses from risks not assumed by the PKI is
positive.

A CA cannot warrant that a certificate binds to a user any more than a
fire insurer can warrant that you won't have a fire.  No casualty
insurer will protect you from, or compensate you for, losses resulting
from thermonuclear war.  But insurance exists because it provides a
service that people and businesses are willing (or mandated) to pay
for.  PKIs are useful if their benefits exceed their costs, regardless
of whether it is possible for a CA to provide an unlimited guarantee
that a transaction signed with a particular public key was initiated by
a particular natural person.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 17 Jul 1999 08:12:43 (NZST)

"David P. Kemp" <[email-masked]> writes:

>A proposed approach to allocating liability included a root CA operated by an
>organization with huge assets (such as a commercial bank) but with only two 
>warranted responsibilities: 1) ensuring name uniqueness across the certs 
>issued by that CA, and 2) protecting the CA's private key.  (A third, 
>unstated, requirement would be to use sufficiently conservative cryptography 
>for signatures on the issued certs).
>
>[...]
>
>You (as a relying party) can rely on a certificate to any extent you wish.  A
>CA may warrant that it follows certain practices; it may also warrant 
>results, as with the hypothetical root CA above, if the amount of loss and 
>the risk of loss can be quantified.  You, the relying party, assume all risk 
>not assumed by the CA.  You are the sole judge of whether the PKI provides a 
>benefit - whether profit from transactions enabled by the PKI minus expected 
>losses from risks not assumed by the PKI is positive.

You know, this would actually work (and it's effectively what organisations 
like Verisign are doing anyway through their CPS).  Apart from the obvious 
objection (<whine>but a PKI isn't supposed to work like that</whine>), is 
there any major reason why this is a bad thing?

Peter.

---

From: Russ Savage <[email-masked]>
Date: Fri, 16 Jul 1999 14:10:22 -0700

-----Original Message-----
From:	Peter Gutmann [SMTP:[email-masked]]
Sent:	Saturday, July 17, 1999 1:13 AM
To:	[email-masked]
Subject:	Re: Common misconceptions, was Re: KISS for PKIX, was ...

Peter.

=======
Any signature use ("wet" or digital) is governed by various forms of contract law.

This is edging into the reason for my earlier message -
the risk an organization is willing to take is, as stated, related to reward.
But also to predictibility/stability of the context - do I really know what I'm liable for
when I sign or accept someone else's signature?
So, if the underlying rules of conduct are inconsistent/unpredictable then
that is risk as well. If there aren't consistent methods for assuring the validity, 
authenticity and _reasonable_ non-repudiation - then what is my risk?
Why should I take it? And if the methods vary over time - how do I know
I'll have recourse down the line when there is a dispute?

Wrapping all that into one package isn't realistic.
There will be change.
There will be many, many special cases and parsing through them
can be recipe for a disaster. I wonder is having a core PKI blob of a bit stream
that can then have adjacent blobs for whatever special case _some_ need
(e.g. additional timestamps or particular types of timestamps)
wouldn't work better than a constant debate about what can, should or
shouldn't be incorporated into the core bit stream and what the rules 
of parsing will be.

And I would put issues about policy (CA & others) outside it as well
what policy is needed will vary. And, I suspect, will morph dramatically
as we move toward cross-certifying an individual by their different
roles in different organizations with layers of trust depending on the
context and the role that's at the other end of the PKI exchange.
PK is simply public/private key exchange in a reliable way.
The infrastructure is going to morph until we get something
that matches the kinds of interactions we have in the brick&mortar world.
That won't fit in one standard. Is PKI simply public/private key exchange
or is it this entire infrastructure that edges into LDAP, privacy/identity, 
what have you?

I'd really like to know what this group sees its task to be.
I'm hearing a wide range of ambitions for the WG.

newbieRuss

btw - a good review from the legal/business practice perspective is
"Moving With Change: Electronic Signature Legislation As A Vehicle For Advancing E-Commerce" 
By Thomas J. Smedinghoff And Ruth Hill Bro of McBride Baker & Coles (www.mbc.com)