Robot CA at toehold.com

[Richard Laager]

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

David Shaw wrote:

...snipped...

> Quite right, but only on paper.  Unfortunately, people treat the
> web of trust as gospel.  Many Alices would treat David's key as
> trusted because there is A path, rather than because there is a
> GOOD path.  
> 
> This is nonsense of course, but pervasive nonsense.  I don't
> believe in catering to nonsense in general, but I do keep it in
> mind.

I can see your point.

> Let me turn the question around and ask "what benefit is derived by
> someone other than the robot operator signing the robot key?"

I see two benefits. First, I can't assign a trust level to an invalid
key. Perhaps I don't want to fully trust the robot operator's key
just to give validity to the robot's key. (Yes, a local signature
will suffice here.) As another person mentioned on this thread, it's
nice to see signatures on the robot's key. I guess it doesn't really
help anything. You've got a good point here.

...snipped...

> All that said, I still plan on doing this some time in 1.3.x, but
> it'll be something only the "power user" will ever see.  I'm
> halfway regretting having non-power users see the signature levels
> at all, but that's done with already.

I agree. The main problem with adding advanced features for advanced
users is that it confuses the newbie. I can't say I have a solution
for that one. My comments didn't take into account the newbie,
because I was talking about a feature *I* wanted and I've already
figured out the WoT. (Of course, it was very confusing to me at
first!)

> > I don't care about the impact of signature types on keyanalyze
> > reports.
> 
> Actually, neither do I.  While I think that people should show some
> restraint in issuing persona signatures, I think that once they are
> issued they should certainly show up in the keyanalyze reports.
> They're a genuine part of the web of trust even if I personally
> don't like it, so why hide them?
> 
> > 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.
> 
> Keyanalyze gets it output from GnuPG, if I recall.  GnuPG shows
> invalid signatures - does keyanalyze ignore this information?

Okay. My bad. I thought keyanalyze did it's own parsing. Perhaps I
shouldn't comment on things I don't know. My suggestion that bogus
signatures could be used was added to that paragraph as an
afterthought.

> In any event, I don't really follow your logic here - because the
> system is already vulnerable to subversion we don't have to care
> about putting poor data in?  Surely not.

Poor data? I don't really see the difference between having a human
verify my e-mail address and sign my key, and having a robot verify
my e-mail address and sign my key.

> > 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.
> 
> There are in fact several places where GnuPG design is influenced
> to be compatible with PGP, and places where the PGP design is
> influenced to be compatible with GnuPG (this wasn't always true,
> but the new PGP company has been quite good at fixing
> interoperability problems
> reported to them) This is true even in places where the OpenPGP
> standard doesn't dictate behavior either way.  We all have to work
> together, or what is the point of standards in the first place?

Yep. Working together is good. I just don't think GnuPG should be
held back because PGP isn't going to support something. In this case,
GnuPG and PGP are both in the dark as far as advanced trust
management. So, we have a level playing field that's broken. I'm not
sure what the best solution is.

Richard Laager

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

iQA/AwUBPfQUMW31OrleHxvOEQLjRgCfac/rUnY5osjO7Zp98Fza47FzLxAAoJma
QXu0ak6j6/7Q1gemno7zKl52
=uy6U
-----END PGP SIGNATURE-----