ways to ensure that GPG public key belongs to right person in business to business communication

[Lou Wynn]

Let me analyze your steps to see what you'd like to achieve in each of them.

0. Alice and Bob knows each other's email addresses: alice at A and bob at B.

1. Bob sends Alice his public key at Alice email address alice at A.

2. Alice relies to Bob with her public key.

3. Alice calls B's support and asks to get Bob on the phone.

4. Bob tells Alice the fingerprint of his public key, and Alice checks
it against what she received at (1).

5. Alice tells Bob her public key fingerprint, and Bob verifies it.

You try to use step 4 and 5 to verify step 1 and 2, but it doesn't work.
Suppose that Ted sends Alice his public key impersonating Bob by a faked
from address but replies to Ted. Ted can be B's support guy who answers
phones. Then your method makes Alice think that Ted is Bob. Step 4 and 5
don't add much value because Bob's public key fingerprint is public, and
the guy in Step 3 doesn't have to be Bob. Basically, step 3 is useless,
and step 4 and 5 are like PGP's web of trust: if someone says Bob's has
that public key, then let's just believe it.

The real value starts with 0, which makes Alice believe that she knows
the owner of email of bob at B when sending to that address. The same holds
true for Bob. In step 2, you should make Alice send her public key to
the bob at B address because that's all the knowledge she has about Bob in
terms of reachability, not reply.

I'm working on a PGP key management system for organizational email
communication. In this system, what I verify is not the identity of a
person; instead, it's the owner of an email address. When I send to an
email address with some secret and get the reply, then I know that I've
been in contact with the owner of the email. I don't care about the real
name of the person who owns the email, or I don't care if it's a shared
email used by several people. All I care about is that I've been in
contact with the email address. The security of organizational email
system starts from here. If you're interested in this concept and trying
out this system, I'll be happy to introduce you more, but it's off topic
to this thread.

Thanks,

Lou


On 10/27/2016 01:52 PM, Martin T wrote:
> Hi,
>
> thanks for reply! Unfortunately, Alice and Bob cannot meet in person
> because of geographical distance. If they could, then this would
> definitely be the best way to exchange public keys. I further
> simplified my initial idea:
>
> Alice from company A asks Bob from company B to send her Bobs public
> key using an e-mail. Both Alice and Bob know each other e-mail
> addresses because they have been in contact before during a project
> which involves both company A and company B. Now when Alice receives
> Bobs public key, she will send hers in return to same e-mail address
> which she received the Bobs public key. Then she looks up the phone
> number of the customer support department of company B from company B
> official website and calls there and asks for Bob. Once she gets Bob
> on the phone, she asks Bob to tell the fingerprint of his public key
> and then Alice tells her public key fingerprint to Bob and asks Bob to
> confirm that it matches.
>
> I guess this provides reasonable security?
>
>
> thanks,
> Martin
>
>
> On Wed, Oct 26, 2016 at 11:51 PM, Daniel Kahn Gillmor
> <dkg at fifthhorseman.net> wrote:
>> Hi Martin--
>>
>> On Wed 2016-10-26 16:21:48 -0400, Martin T wrote:
>>
>>> let's say that Alice from company A and Bob from company B need to
>>> exchange some private data with each other. Alice and Bob need to
>>> encrypt data just that one time, they do not belong to web-of-trust,
>>> but both company A and company B websites are trusted by certification
>>> authority, secure and available only over TLS. This gives a first
>>> option where both Alice and Bob ask their IT departments to publish
>>> their public keys on the company website so Alice can get Bobs public
>>> key over TLS from company B website and the other way around. Or when
>>> for example website of company B is not trusted by CA, then Alice can
>>> pick up the phone, call the customer-support of the company B and ask
>>> for Bob and then ask Bob to send her an e-mail with a public key and
>>> verify the fingerprint of the public key over a phone? Are there
>>> better(easier to use or more secure) ways to ensure that GPG public
>>> key belongs to right person in business to business communication?
>> It depends on how much involvement you want the IT department to have.
>>
>> There are a few more options:
>>
>>  * if Alice and Bob can meet in person, they can give each other
>>    business cards with their fingerprints on them.  If this is how Alice
>>    finds Bob's e-mail address in the first place, this is a natural
>>    place to exchange cryptographic details as well.
>>
>>  * the two companies could use WKD (web key directory), which is in its
>>    infancy, but is at least supported by GnuPG 2.1.x.
>>
>>  * Alice and Bob could submit their keys to a third-party notary like
>>    Symantec's PGP Global Directory (if such a thing still exists)
>>
>>  * Alice and Bob could publish their public keys in the public
>>    keyservers (e.g. gpg --send-key $FINGERPRINT) when they create their
>>    keys.  Then they could look each other up in the public keyservers;
>>    if Alice finds only one public key associated with Bob's e-mail
>>    address, she might just decide to assume it's the right one.
>>
>> These all have slightly different security properties and failure modes,
>> which might have different value to Alice and Bob, depending on their
>> threat model and any other economic or logistical pressure they're
>> under.
>>
>>       --dkg
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20161215/cb777f1d/attachment-0001.html>