Call me crazy, but ...

[Стефан Васильев]

Brandon Anderson wrote:
>>>>> 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.

How do you initiate a key signing session, with 3 levels, GnuPG offers,
when you started using GnuPG with virtual contacts and what level
would you choose for this proposal? I have wittnessed people running
a GnuPG CA with a key certification policy which gave well know people
remotely a sig2 or 3, without getting in contact with the user and 
without
asking the user. So much for the classical WoT nobody can rely on.

In Alice and Bob's case, regardless if they sign keys or not, they know
each other for a long time virtually. If Eve would play man in the 
middle
since they first met, yes than this is a problem, but then (signing or 
not)
we can consider public key cryptography as a general problem, regardless
if you use GnuPG with all it's many features and FAQs or other crypto
software. And here we would be then at the Governikus topic and you
and others can happily ask, why the majority of German GnuPG users
do not use such a fine certifcation service ... or why other (EU) 
countries
did not follow the Governikus route (for CA cross certification)???


Regards
Stefan