Subject: RE: Certificate / CPS issues

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 6 Jun 2003 07:41:11 -0700

Yes, the CPS disclaims all WARANTIES.

You do not want a CA that provides a recourse that depends on finding of
fault. WARANTIES are a specific legal instrument that provides recourse
through the courts under theories of merchantability and negligence. So you
have to PROVE the CA did something wrong... you don't want that.

What you want is insurance, read the relying party agreement. That
specifically provides insurance for certain specific failures. In other
words a NO-FAULT dispute procedure.

Do you think that folk signing PGP keys are undertaking unlimited liability
should the certification turn out to be incorrect?

Folk use our $15 a year certificates for some hair raising stuff. There is a
certain organization that moves very large sums of money every day whose PKI
consists of buying a few hundred certs from our consumer site via credit
card. So don't expect anyone to accept unlimited liability for a fixed $15
fee.

If you want to have insurance on a per transaction model you have to go to
an online technology. That is one of the many reasons we designed OCSP and
then XKMS.

I think the real problem here is that folk are demanding something that is
impossible. They want a PKI that is entirely costless, failure free and
provides unlimited liability. If you set that as the standard for existence
of a global PKI then you are never going to see one.

Security is risk control, not risk elimination.

		Phill

---

From: Pete Resnick <[email-masked]>
Date: Fri, 6 Jun 2003 11:10:25 -0500

On 6/6/03 at 7:41 AM -0700, Phillip Hallam-Baker wrote:

>Do you think that folk signing PGP keys are undertaking unlimited 
>liability should the certification turn out to be incorrect?

No, but if Mary turns out to be someone who signs PGP keys for people 
I don't like, I can simply say "Don't trust Mary" in my PGP 
application and the things she signs won't show up as valid unless 
someone I do trust signs them. If RSA screws up and signs keys for 
people I don't like, I can't (practically) say "Don't trust RSA" 
without invalidating a bunch of keys that I probably do want to trust.

I'm not by any means saying that PGP is a perfect solution. It's just 
that the liability scenario is very different because amount of 
damage any given signer can do is much different.

pr
-- 
Pete Resnick <mailto:[email-masked]>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: David Morris <[email-masked]>
Date: Fri, 6 Jun 2003 10:01:31 -0700 (PDT)

> Security is risk control, not risk elimination.

Absolutely!

Extending that thought, managing risk is about the cost of loss vs. the
cost of protection.

Humans make mistakes. Systems fail. Sammy Sousa used the wrong bat. The
suttles failed. To reject a service because you have one presumed example
of failure is not realistic. A pattern of failures would be an issue, just
like you might avoid purchase of an automobile if Consumer Reports failure
statistics are abnormally high.

For the objectives we are discussing, I think the failure rate at Verisign
is not an issue. Most (perhaps all) folks in this discussion seem to agree
that the issue with spam is in the volume and not the mere existance of
spam. Social scientists could probably study the parallel growth of spam
and the corresponding growth in frustration and even end up with a volume
of spam which most people would be comfortable with. I strongly suspect
that reducing and keeping spam at 10% of current levels would probably be
success. Certainly, 1% would be.

On that premis, I'm certain it doesn't matter if 1 of the current 200
heavy duty spammers gets a fraudulant certificate. That might make final
identification more difficult, but most of the other mechanisms will still
function.

1. Proof of common source of the quantity of emails needed to be
   ruled as illegal
2. Source based filtering can still block mail identified with the
   cert
3. Once the fraud is discovered, the CA is likely to have process
   in place to avoid issuing new certs to the same entity

The last time I investigated, Verisign had certificates of different types
with different prices and levels of identification verification. Even the
cheapest have some cost and since I doubt that Verisign accepts cash
payment, there is identity associated with the payment. Worst case is a
stolen credit card is used to make payment. Since that is an immediate
felony, it may actually be the best case from anti-spam perspective.
Because of this cost (and the difficulty of obtaining and risk of using a
large number of stolen credit cards), it seems less likely that spammers
will follow the scenario of obtaining a large number of throw away
certificates.

Conclusion, I don't see the less than 100% trustworthiness of any CA to be
an impediment to the use of certificates as part of an email origin
identification scheme. Only a fool would accept a self-signed certificate
as having any significance so I think the suggestion that the ability of a
spammer to generate their own storm of certificates has little merit.

Dave Morris

---

From: "Haren Visavadia" <[email-masked]>
Date: Fri, 6 Jun 2003 18:19:45 +0100

> of a global PKI then you are never going to see one.

Folks will pay a certain amount providing the certificate validity
period is not short time, for example issuing certificate that are valid
for 2 years instead 1 year or provide many different validity periods
for customers to choose from.

The issue is of implementation of the system.

---

From: "Haren Visavadia" <[email-masked]>
Date: Fri, 6 Jun 2003 18:37:20 +0100

Pete wrote:
> I don't like.

The job of the CA is NOT based on liking; it is one of authenticating
the subscriber and issuing a certificate.

The authentication of subscriber is defined by the CA's CPS.

---

From: "Haren Visavadia" <[email-masked]>
Date: Fri, 6 Jun 2003 18:07:03 +0100

>Do you think that folk signing PGP keys are undertaking unlimited
liability
>should the certification turn out to be incorrect?

The biggest difference between PGP and X.509, is that in PGP I can
choose the level of trust.

X.509 is based on doctorial model, where my browser is forced into
trusting the certificate from a server.

---

From: "Al Arsenault" <[email-masked]>
Date: Fri, 6 Jun 2003 14:12:16 -0400

While I'm in general a fan of PKI, and agree with some of what Phill has to
say, a number of things should be kept in mind:

1 - a number of popular applications have been designed to work a large
variety of "trusted root" certificates, by default.  For example, I just
popped up the list of "trusted root certificates" marked trusted by default
in IEv6.  I probably miscounted, but I got 106.  (YMMV, depending on
version, or if you use a different browser, or...) From a whole bunch of
different sources.

2 - a number of the entities behind those trusted roots go out of business,
or become somebody else, or...  A quick quiz, based on the root certs from
IEv6 (yes, I know the answer to these questions, but I've been working in
the PKI area for over 15 years - how about most people):

    - who owns the private keys associated with those 3 "GTE Cyber Trust"
root certificates?
    - what is that company doing that will conclude by June 30?
    - what about the private keys associated with those four "Equifax
Secure" root certificates?
    -  there are at least 10 trusted root certificates marked signed by
"DST".  What happened to DST?
    - there are six certificates marked as being from "Thawte".  Who's
"Thawte"?
    - what about Xcert?

3 - most users will never know enough to delete roots as no longer being
trusted (or do what some of us do, and delete them all at system install
time; then reinstall just the ones needed, on a need-to-exist basis).  Since
any cert that chains to any one of those roots will succeed silently in the
default configurations of many popular applications, who will know?

The point of this is that if you're going to use a PKI-based approach to
combatting SPAM, you have to look at the whole problem, as it exists today.
All it takes in the "real world" is a spammer (or friend of such) acquiring
the private key associated with any trusted root cert in popular
applications, and there you go - SPAM passes your tests/filters until you
figure out how to remove the cert from the list of trusted ones.  Not
something that my mother will easily know how to do.

        Al Arsenault

---

From: "Haren Visavadia" <[email-masked]>
Date: Fri, 6 Jun 2003 19:12:24 +0100

Dave wrote:
> Only a fool would accept a self-signed certificate

CA certificate is self-signed.

Are you suggesting CA should cross sign each others certificates?

---

From: David Morris <[email-masked]>
Date: Fri, 6 Jun 2003 12:28:22 -0700 (PDT)

> Are you suggesting CA should cross sign each others certificates?

If a root certificate is installed by a process you choose to trust, it is
not self signed. Self signed in my experience refers to the ability
frequently used internally for QA labs where there is no accepted root
server. Even if the root cert, installed by my explicit or implicit
approval, is used to sign another cert from the same organization, that
second cert isn't self-signed.

FWIW, for UBM suppression, I'm not concerned about my grand parents
understanding trust models. Meaningful trust boundaries must begin with
the MTA. The MTA owns the trust issue between itself and individual MUAs.

As Phill implied, the cost of security must be less than the value of the
protected entity. If major operators of MTAs discover that a particular CA
root private key is compromised. Addressing the problem quicky should be
easy, if the possiblity was anticipated. Will that protect every user, no,
but costs here are based on the scale of the activity, not individual
occurances (as is any value received from sending the UBE) so getting
rapid response from 20-100 MTA operators is likely to be effective.

Dave Morris

---

From: "Haren Visavadia" <[email-masked]>
Date: Fri, 6 Jun 2003 20:49:20 +0100

The trust chain will include the root cert, which is self-signed.

This means you would have to somehow trust the root cert. And that might

---

From: "Haren Visavadia" <[email-masked]>
Date: Fri, 6 Jun 2003 19:34:33 +0100

Al Arsenault:
> SPAM passes your tests/filters until you
> figure out how to remove the cert from the list of trusted ones. 

A filter could be set to filter out all e-mail containing a certain
certificate, regardless of the trust chain.

---

From: Franck Martin <[email-masked]>
Date: 09 Jun 2003 09:39:49 +1200

I suggested a few month ago that the PKI to become gPKI should be
supported by the DNS system by using special DNS records and an ldap
naming scheme.

In short (go in the archive and look for GLOBAL PKI on DNS), I want to
send you an e-mail so I query the DNS with the domain bbn.com and it
reply to me that the PKI for this domain is located at
ldap://computer.bbn.com/ I then query this ldap server to extract your
public key/ certificate. The certificate of the PKI of bbn.com would
have been signed by the PKI of com which would have been signed by the
PKI of the root servers.

The DNS does not carry at any time a certificate (too big)

The DNS here is only offering a location service (small DNS
records/transfers)

Cheers
Franck

-- 
Franck Martin <[email-masked]>
SOPAC