Robot CA at toehold.com

Richard Laager rlaager@wiktel.com
Mon Dec 9 02:14:02 2002


 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Shaw wrote:

> Any person who wants to use the robot's signatures must download
> the robot's key and assign it (local) trust.  Signatures on the
> robot's key are meaningless in this configuration.

So far, I agree with you.

> However, having random people sign the robot's key - which allows
> people to gain trust *through* the robot does nothing but harm the
> web of trust for no real benefit.  Since the robot works perfectly
> well without collecting signatures on its own key, those signatures
> should be discouraged.

How does signing the robot's key allow people to gain trust through
the robot? If we were talking about people, instead of robots, here's
how I'm interpreting what you're saying:

1. Alice signs Bob's key and sets his ownertrust to full.
2. Bob signs Charlie's key. Alice can now be sure she's dealing with
Charlie's authentic key because she trusts Bob. (This is the basic
ownertrust principle.)
3. Charlie signs David's key.

Does this mean Alice can be sure she's dealing with the authentic key
of David? No. Bob can, IF he trusts Charlie. For Alice to be sure
she's working with David's authentic key, she needs to trust Bob to
make "trusted introducer" signatures.

With all this discussion taking place, I looked at the Robot CA. I
saw only three signatures on the Robot CA key. The first is the
self-signature. The second is from Kyle Hasselbacher. The third is
from Jason Harris. I don't know Kyle Hasselbacher, so his signature
is meaningless. I do know Jason Harris (at least to the extent of the
criteria he uses to make a 0x11 signature -- see my key for an
example). If I set Jason's ownertrust to full, the Robot CA key is
going to appear fully trusted.

Is this a problem? I would say so. I don't want to trust all of his
(or anybody else's) signature levels the same. But, is this Jason's
fault for making the signature. No. He's acting within his set policy
for giving 0x11 signatures. I think this is an issue with the OpenPGP
user agent, in this case GPG.

I've always wanted to see a feature in GPG that would let me decide
on a per-key AND per-signature type level the amount of trust to
give. I want to be able to encode something like this: "I want keys
signed by the Robot CA, the Thawte Freemail keys, and the TC
TrustCenter Class 1 keys to be marginally trusted as valid keys
(unless another rule applies more trust) with no ownertrust." I
realize this is not simple to codify by any means. I wish I was
familiar with the GPG internals, so that I could start coding this.
But, alas, I'm not.

I don't care about the impact of signature types on keyanalyze
reports. I found plenty of people willing to give me 0x11 signatures
by confirming that I could decrypt encrypted mail to my e-mail
address. All it would take to get a ton of keys into the strong set
would be to get a 0x11 signature from someone already in the strong
set, and then sign every key on a keyserver. One can't place too much
faith in the "strong set" because all signature types, and more
importantly, all signers are given the same weight. Furthermore,
Jason Harris mentioned that keyanalyze doesn't do cryptographic
verification of signatures. One could easily make a ton of bogus
signatures and ruin the keyanalyze statistics. The same applies to
the pathfinder.

I do have some concern over the effects 0x11 signatures have on PGP
users. However, they are in the OpenPGP standard. In fact, they were
initially created for PGP, IIRC. If GPG gains the ability to do
fine-grained trust management, it will find its way into PGP, if PGP
customers want it. Besides, GPG has been, in my opinion, a leading
implementation of the OpenPGP standard. I don't see why GPG needs to
limit it's (user agent) functionality to match PGP. One can't argue
that it needs to be done for compatibility, because PGP will continue
to handle trust issues as it does now.

Richard Laager

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPfPuYm31OrleHxvOEQIOdQCgrubTs/B8d/uAp7PQHfQCFa3oZQsAn1ha
OXIxG0+LvjdkLdTgWqifN2vr
=6hiK
-----END PGP SIGNATURE-----