Call me crazy, but ...

[Brandon Anderson]

>>>> On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 
>>>> <gnupg-users at gnupg.org> wrote:
>>>>
>>>> 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.
>>> That’s what ordinary third-party sigs do. Adding medical data to a 
>>> public key does not add anything to the process.
>>>
>>> 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.
>>>
>>> A
>> I 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.
>
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.

Sincerely,

Brandon Anderson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x255837AEF812E87E.asc
Type: application/pgp-keys
Size: 15950 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210715/8c2bf042/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210715/8c2bf042/attachment-0001.sig>