Subject: Re: Trust Packets

From: [email-masked] (Peter Gutmann)
Date: Fri, 30 Jan 2004 23:09:59 +1300

Ian Grigg <[email-masked]> writes:

>An example of this is the x.509 PKI in use in HTTPS - they define trust as
>being a CA-signed cert that includes, for example, some notion of what
>country you are in (? from?).

Since we're getting a bit philosphical here, I don't know if what X.509
enforces is really "trust".  PGP's web of trust is a reasonably accurate use
of the term "trust", but with X.509 you need to read "trust" as "dependency"
(in the sense of "is forced to depend upon").  For example if I make a CC
purchase from foo.com, I don't trust them because of their Verisign cert, but
I have no choice but to depend upon them because if I don't I can't make my
purchase.  So PGP's mechanisms propagate trust, X.509's propagate dependency.

Peter.

---

From: Greg Troxel <[email-masked]>
Date: 30 Jan 2004 11:02:26 -0500

> purchase.  So PGP's mechanisms propagate trust, X.509's propagate dependency.

You of course do have a choice - whether or not to make the purchase.
I have declined to buy things because I don't trust people, and I'd
hope everyone else is in the same boat.

With pgp, you choose whether to believe a message or use a key for
encryption.  If you "have to" send the message, you "don't have a
choice".

The ultimate trust model is really no different; it's the kinds of
decisions that you can make easily that get encoded into software that
differ (and this is important).

With foo.com, you choose

1) whether foo.com is actually reputable and you are willing to deal
   with them (same in PGP and x509 case)

and

2) whether you believe that the key you have for foo.com really
   belongs to foo.com (by choosing to believe that verisign is
   adequately careful in issuing certs and protecting the CA key), or
   via some essentially equivalent operation wtih a PGP signature.

The real difference is that x509 has a bunch of rules about which
signatures won't be believed (due to name subordination) and the
cultural (not spec) notion that 'root CAs' are inherently trustworthy,
together with the notion and practice that a specific list is included
by default.  I agree that in practice this cultural difference is
large.

I think it would be a mistake for the openpgp spec to move in the
direction of suggesting that some keys be preconfigured as trusted
(where trusted specifically means that name/key bindings signed by
those keys are believed).  But I don't think anyone is suggesting
that.

-- 
        Greg Troxel <[email-masked]>

---

From: "Richard Laager" <[email-masked]>
Date: Fri, 30 Jan 2004 20:36:50 -0600

Peter Gutmann wrote:
...
>                                                For example if 
> I make a CC

No, X.509 propagates trust. The root certificates in your browser's
certificate store are there because you trust them. I realize that
the browser vendor pre-loads a bunch of certificates. This is to make
things easier for the end user. If you don't trust VeriSign to issue
signatures, remove them from the root certificate store. Now, once
that's done, does the certificate for foo.com appear valid? No.
You've revoked your trust of VeriSign, so it shouldn't. Using the
site is NOT dependent on VeriSign. You can make the SSL connection
without trusting the certificate. Then, it becomes the same
(security-wise) as HTTP; you can't be sure you're avoiding a MITM
attack.

This would be exactly the same if a Linux vendor preloaded
/etc/skel/.gnupg/ with default keys marked as trusted. There is no
dependency introduced, just pre-loaded trust. If you didn't trust the
pre-loaded keys, you could just remove them.

X.509 has its flaws, but it's trust model is in fact based on trust.
It's just different from PGP's Web-of-Trust. If you disagree with it
because it forces you into rigid hierarchies (typically promoted by
commercial interests), fine. But, the underlying technology isn't
creating any sort of trust-like dependency.

A good definition of "trust" in a computer security context is, "An
entity which can break your security policy." (I don't know if this
is attributable to the DoD or whom.) In other words, if you have
VeriSign in your root certificates, they can break your security
policy by issuing a bad certificate. This is not dependence.

Richard Laager

---

From: Ian Grigg <[email-masked]>
Date: Fri, 30 Jan 2004 23:46:21 -0500

I hope the original poster can now see why it is that
trust is not defined in the standard at least - because
we can't as yet agree what it is.  For whatever reason.

iang