"just invent something..."

[Ángel]

On 2020-05-23 at 12:30 -0400, Robert J. Hansen wrote:
> > - 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,

Handy link to the FAQ:
https://gnupg.org/faq/gnupg-faq.html#using_certificates



I see a big hole in the validation part. The steps providex are
validating the offline identity but not matching it to the certificate
uid.

> *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.
I meet Rob, face-to-face

>     2. Ask to see two forms of government-issued identification.
He shows me two ids that I consider acceptable

>     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.

He gives me his email address <donaldtrump at sixdemonbag.org>, its
certificate fingerprint and place to download (WKD).



>     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.

I download the certificate, I verify that it has the provided
fingerprint and that the provided email address does appear on the
certificate: “Donald Trump <donaldtrump at sixdemonbag.org>”


>     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

I sign the certificate, and send it to donaldtrump at sixdemonbag.org, so
he can share my signature attesting his identity.


> 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.


And yet, I find something unsettling about that key with a Donald Trump
name just by meeting Rob Hansen face-to-face ;)


I would _probably_ keep some records somewhere that I had signed that
key based on meeting a certain Robert Hansen, but that actually means
keeping your own out-of-keyring identity map.
There might be an unwritten assumption that the name must match, too.
But in that case it should be explicit


It's also not clear what should be there. Consensus seem to be that
there must be _some_ kind of loose matching. Maybe, but for Robert
Hansen vouching for that certificate, the identity might be
* Robert J. Hansen
* Robert Hansen
* Rob Hansen
* Rob J. Hansen
* rjh


And he's far from being the only Robert Hansen, anyway:
https://en.wikipedia.org/wiki/Robert_Hansen_(disambiguation)


Nonetheless, a name of ‘Donald Trump’ should probably not be accepted,
unless he is the name he goes by in certain circles.

(In fact, on [some] common law jurisdictions, it is possible to change
your name just by asking to be called that way)


Another scenario would be an identity where only an email was provided,
although in that case, it's not clear why you would want a
government-issued identification. You only need an attestation that the
key is owned by the mailbox owner.

It is already quite long, but I think this part should be expanded to
explain about how to treat the names in the certificates.


I'd also clarify that 7 is optional, and you don't *need* to send your
signature to the other party. This is actually much easily fixed.

Best regards