looking up pgp keys

[Phil Pennock]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2013-09-09 at 22:57 -0400, Tim Prepscius wrote:
> This is also very interesting.
> 
> Why is this the model which has been chosen?

Trust has to reside somewhere.  You appear to be asking for "trust
someone else, the server operator", in which case a compromise of them
is a compromise of your local trust integrity.

PGP *fundamentally* works on a Web-of-Trust model.  I suggest further
reading on this topic, but this is how PGP works.  If you don't want a
web-of-trust, with clients responsible for evaluating trust and
identity, then you don't want to be using PGP (OpenPGP or its
implementations such as GnuPG).

> For instance, if I wanted to send a message to you, having never met
> you before, I could not verify I am sending to you and not a third
> party masquerading as you.  I could probably look you up on the net,
> read a bunch of web pages, perhaps you've posted your pub key on some
> blog or something.  But that takes a human.

If you have a validating DNS resolver, and you trust your root zone
trust anchor to not have been subverted, then you can use DNS to find my
PGP key, verifying the results with DNSSEC.  'phil.pennock' as a
left-hand-side in the domain used for this email has CERT records in
DNS.  GnuPG can query and retrieve these.  (For mailing-lists, I use
other left-hand-sides in the domain, but given a direct email from me,
not as a reply to a list-post, your systems could do this
automatically).

(Actually, I only use CERT type 6 (IPGP), to publish the key
 fingerprint and a URL for retrieval.)

So *if* you trust your ability to verify DNSSEC, and *if* you're happy
validating only the email address, not any purported human identity,
then you could look for those CERT records and then locally sign them
upon import so that your local keyring can use the key without
prompting.

If you want to be able to _automatically_ identify a _human_ identity,
then you need a system which provides verifiable human identities.  PGP
provides that, with the WoT; PKIX provides that, with client
certificates.  To scale up then in practice, you're looking at national
identity schemes.  If your threat model includes government agencies of
your local government, then national ID systems are probably not where
you want to go.

> If I am a machine, is there anyway to effectively filter out poisoned
> results?  (which are not poisoned via MITM but just globally
> poisoned)?

Yes.  Read the GnuPG handbook, ponder the difference between "have a
key" and "have a trust path to a key".  Read up on stuff like the Strong
Set.  Don't use keys you don't have a trust-path to.  Locally-sign keys
you import where you do trust the import mechanism.

> Why didn't the mail server people also run local key servers for which
> you could only change your key with your password?
> (while this would not be any strict guarantee of course, it would
> solve the problem of spam, and anyone writing to anything)

If the problem of spam could be resolved by mail-servers, a lot of
postmasters would sigh a huge sigh of relief.

If you want something you have to log in to change, then you're looking
for 'finger', with PGP keys going in ~/.plan files.

There are various keyservers which speak HKP (the PGP usage profile of
HTTP for key search, retrieval and upload) without trying to maintain
the entire set of all publicly known keys.  You asked about using the
public keyservers, which have the characteristics stated.  If you want
to go spidering and retrieving keys by other means, and are confident of
your ability to create a multi-protocol spider which won't trigger abuse
complaints, then go for it.

Or you could look into the Strong Set, which is an identified sub-set of
the public keys for which there might be reason to believe that the
identities are probably valid.

> So basically what I'm getting from this, is if I do this with a machine:
> 
> 1.  There is no trust.

There is plenty of trust, but it's up to _you_, as the client, to trust
and verify.  In PGP, folks tend to not blindly trust remote sources not
under their own control.

> 2.  Changing from one key to another key, if the first key hasn't been
> "officially" revoked, is even less trust.

If I publish a key in which one of the UIDs has my name and a comment
stating that it replaces some other key, and I get enough signatures on
that new key, then you trust that.  Nothing I know of currently parses
such comments to automatically discard old keys.  But frankly, if a key
hasn't had new signatures on it in the past two years, then it's likely
defunct and if it hasn't had signatures in the past five years, then it
really truly is defunct.  Worst case scenario, you generate a new
self-sig and re-upload with no third-party signatures.

> 3.  And in fact, even if the first key was revoked, there is no
> guarantee that the second key is trustworthy.

The only guarantees are those you verify for yourself.

> 4.  I need to continually monitor all keys of my users in the public
> key repository, watch for changes.

No: if you know the ID of a key belonging to one of your users, then the
only changes are new signatures.  That's not an issue and shouldn't
negatively affect trust.

You *might* instead watch for new keys appearing for the same human name
as your users and figure out heuristics for which ones you care about.
If one of your users has a name such as "John Smith" then you'll have
more problems.

Naming is a hard problem.  Third-party independently verifiable naming,
using names that carry semantic value, is even harder.

- -Phil
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlIun4cACgkQQDBDFTkDY3/pzwCdFcj8Xt+oA/Qko4eYJ/IvVI14
Ax0An08KkfUv3fJHxdok/dkwehjF4GuW
=XIrN
-----END PGP SIGNATURE-----