"just invent something..."

[Robert J. Hansen]

> - The trust in the correspondent's public key is established only
> by comparing the key fingerprint derived programmatically from the
> locally stored key-file and a copy independently obtained from
> the owner. The only identification of a public key is its fingerprint.
> Since the public key is either known to an adversary, or it is very
> hard to guard against such eventuality, the public key itself should
> not provide the adversary with any useful information.

Okay, but this seems largely redundant with section 8.12 of the FAQ,
which, uh ... does exactly this.  What exactly are you objecting to?

=====

8.12 How do I use another person’s certificate?

In order to send an encrypted message or verify a signature, you must
obtain the certificate for the recipient’s/signer’s public key.

Occasionally you might obtain the certificate physically, by meeting the
certificate holder face-to-face and exchanging the certificate on some
storage medium such as a USB stick, memory card, or portable disk. Or
you might download a copy of the certificate from the holder’s web site.

Once obtained in one of these ways, you can add the certificate to your
collection of public keys by doing:

gpg --import certificate.txt

More commonly, you’ll download a correspondent’s certificate from a
keyserver.

[snip keyserver instructions]

*Why do I need to validate certificates?*

If you were to receive a letter in the mail that claimed to be from the
President of the United States, would you believe it? Probably not,
because anyone can put together official-looking letterhead: you’d
insist on doing some kind of checking to make sure that no one was
fooling with you.

The same applies to email. A certificate can claim to be from anyone.
You have to make sure that the certificate really belongs to whom it
claims it belongs to. That process of making sure is called ‘validation’.

*How do I validate certificates?*

This advice is controversial.

It’s controversial for a simple reason: every Tom, Dick and Harry has
their own idea about the “right way” to validate certificates. Some of
these people are well-informed and some of them are just plain unhinged.
In the end, you are responsible for making your own decisions. That
said, the following is generally agreed upon as being a reasonable
procedure:

    1. Meet the certificate holder face-to-face.
    2. Ask to see two forms of government-issued identification.
    3. Upon verifying the person really is who they claim to be, ask
this person to provide their certificate’s fingerprint, their email
address, and where you can obtain a copy of their certificate. (Example:
“My fingerprint is 4541 BB01 8EA4 8F99 19CA 3701 2380 6BE5 D6B9 8E10,
and you can find it on pool.sks-keyservers.net.”)
    4. On your own computer, retrieve the person’s certificate from the
specified location. Check to make sure the email address they gave you
is one that’s also listed on the certificate. Check to make sure the
fingerprint of the certificate you’ve downloaded matches the fingerprint
the person gave you.
    5. gpg --edit-key [their certificate ID] sign
    6. Once signed, gpg --armor --output signed_cert.asc --export [their
certificate ID]
    7. Send the file signed_cert.asc to the address they gave you

By following this process you first ensure that you’re speaking to the
right person. By comparing the fingerprints of the certificate you have
against the fingerprint they specified, you’re ensuring that you have
the right certificate. Checking to make sure the email address they gave
you is also listed on the certificate is one more check to make sure.
Once that’s done, presto, Bob’s your uncle: there’s nothing left to do
except sign it and return the newly-signed certificate to the other person.

=====

I mean, this seems like 95% of what you want.  You just want the
reference to an email address in step 4 removed?

If you can get the community to agree, I'm all in favor.

> - All gpg operations (key generation, encryption, decryption) are
> carried out on a device not connected to the Internet.

The FAQ covers both online and offline use.