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@A and bob@B. 1. Bob sends Alice his public key at Alice email address alice@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@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@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 > <d...@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@gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
