When designing a scheme for cryptography, you should always assume the worst situation, so it is secure in every situation. So in this hypothetical, you are only using this scheme if Bob has already somehow verified Alices' public key? How has he managed to do so? I assume either in person or with the web of trust. However, Bob has managed to do this should be the same way Alice verified Bob's key. This brings us right back to the this QR-code does not prove ownership of Bob's public key. Again if Eve ever has seen this QR-code, either with an earlier communication or otherwise, Eve could be sending the encrypted message to Alice with Bob's QR code. From Alice's viewpoint, who has not verified Bob's public key, there is no way for her to know who is sending it, so she should not trust it.On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users <gnupg-users@gnupg.org> wrote:That’s what ordinary third-party sigs do. Adding medical data to a public key does not add anything to the process.It would tell me as 3rd party that for WoT puposes, if this is still used, Alice and her good friend Bob were able to sign their pub keys remotely,based on a free of charge verification method.You should also beware that medical information is treated as sensitive personal data under GDPR, and this subject to stricter rules. Keyserver operators already have enough legal issues handling ordinary personal data (email addresses etc) without adding vaccination certificates to the dataset.AI would argue what he is proposing doesn't do that at all. It is like publically posting a password to your google account and telling people they can verify it is your account by trying to sign in! Once you send your 'proof of identity,' anyone can make the same claims even if you are not sharing this on a keyserver. It's made worse by this being something I expect people will be sharing to prove vaccination, so it will likely have many potential areas to be copied. If you tell me you have not shared it with anyone yet, that still means nothing because you could be impersonating the persons whose QR code you already received from an earlier exchange. Even if this was not the case, and it indeed was a verifiable secret never shared with anyone, it does not verify the identity of the public key owner because it's susceptible to a simple man-in-the-middle attack. Assume Bob wishes to prove his ownership of public key pub_bob to Alice. Bob and Alice are communicating in a way compromised by Eve. Bob affixes his Vaccine QR code to a public key and transmits it to Alice. On route to Alice, Eve intercepts the public key, generates a key pair Pub/Priv_eve, adds bobs QR code to the public key Pub_eve, and sends it to Alice. Alice sees Pub_eve with Bob's QR code and concludes that Pub_eve is owned by Bob and signs it as verified. Again, this is not a secure way to verify identity. Do not do this. It is considerably worse than just having a public key exchange over the phone/video call because it gives others a way to impersonate you. If you wanted to have a video call over the internet and show "proof of identity" over that call and that was sufficient for you, then fine, but whatever you do, don't attach your proof of identity to the public key.Why do you assume such a workflow? Alice sends the duplicate ASCII armored in an encrypted and signed message to Bob. Bob is already for a long time in possession of Alice's pub key. After receiving Alice's message he extracts the QR-code, verifies it and compares both pub keys fingerprints. Once done he deletes the duplicate and the extracted QR-code. Finally he can sign Alice's pub key, sends it back to her and she can then upload it to a keyserver.
Sincerely, Brandon Anderson
OpenPGP_0x255837AEF812E87E.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
