Call me crazy, but ...
if a person, within the EU, would put his COVID vaccination certificate QR-Code in his pub-key as photo-ID I would say that than another GnuPG user, within the EU, or maybe later in the U.S. and elsewhere too, would have the assurance, without that the public key is otherwise signed, that this pub key belongs to that person. On GitHub is a decoder available, which allows users to verify the digital signature of such COVID certs, with trustlists from EU member states. https://github.com/stapelberg/coronaqr Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
What exactly stops me, a person wanting to impersonate that user, from putting the same QR-Code I got from that public key into my own keypair? On 7/14/21 5:45 AM, Стефан Васильев via Gnupg-users wrote: if a person, within the EU, would put his COVID vaccination certificate QR-Code in his pub-key as photo-ID I would say that than another GnuPG user, within the EU, or maybe later in the U.S. and elsewhere too, would have the assurance, without that the public key is otherwise signed, that this pub key belongs to that person. On GitHub is a decoder available, which allows users to verify the digital signature of such COVID certs, with trustlists from EU member states. https://github.com/stapelberg/coronaqr Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users 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
Re: Call me crazy, but ...
Brandon Anderson wrote: What exactly stops me, a person wanting to impersonate that user, from putting the same QR-Code I got from that public key into my own keypair? Nothing, if you obtained the pub key from a key server! The idea would be that Alice and Bob, not having a CA, nor WoT signatures, while they both never met in person, could make a duplicate without the photo-id, which they always use and upload to key servers etc. and for verification purposes the could exchange the pub keys with to photo-id for comparison of both keys. Once compared they both sign then the pub keys which have no photo-id. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
accounts-gn...@holbrook.no wrote: Maybe a bit off topic, but I've tired zbarimg and qtqr to scan that EU covid qr code of mine, but neither could do it. Is that some kind of custom encoding going on? Yes, it should work. What you can try is to use an online QR decoder and use from the obtained text the first string (in base45) and save it in a text file and then run the Golang program only with the text file. coronadecode -verify < base45string.txt. Without using the the trustparameter it uses then by default the German trustlist. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Maybe a bit off topic, but I've tired zbarimg and qtqr to scan that EU covid qr code of mine, but neither could do it. Is that some kind of custom encoding going on? l On Wed, Jul 14, 2021 at 12:45:53PM +, Стефан Васильев via Gnupg-users wrote: > if a person, within the EU, would put his COVID vaccination certificate > QR-Code > in his pub-key as photo-ID I would say that than another GnuPG user, within > the EU, or maybe later in the U.S. and elsewhere too, would have the > assurance, > without that the public key is otherwise signed, that this pub key belongs > to that > person. > > On GitHub is a decoder available, which allows users to verify the digital > signature > of such COVID certs, with trustlists from EU member states. > > https://github.com/stapelberg/coronaqr > > Regards > Stefan > > ___ > 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
Re: Call me crazy, but ...
"online decoder" will part of the point is not to upload my qr to some external site. That should strictly not be necessary. Are there other qr decode apps (cli) out there that people have used successfully with the corona qr surveillance trojan? On Wed, Jul 14, 2021 at 02:11:33PM +, Стефан Васильев wrote: > accounts-gn...@holbrook.no wrote: > > Maybe a bit off topic, but I've tired zbarimg and qtqr to scan that EU > > covid qr code of mine, but neither could do it. > > > > Is that some kind of custom encoding going on? > > Yes, it should work. What you can try is to use an online QR decoder > and use from the obtained text the first string (in base45) and save > it in a text file and then run the Golang program only with the text > file. coronadecode -verify < base45string.txt. Without using the > the trustparameter it uses then by default the German trustlist. > > Regards > Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
accounts-gn...@holbrook.no wrote: "online decoder" will part of the point is not to upload my qr to some external site. That should strictly not be necessary. Are there other qr decode apps (cli) out there that people have used successfully with the corona qr surveillance trojan? I don't know, I have only used zbarimg, as described. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
On 14-07-2021 15:41, Brandon Anderson via Gnupg-users wrote: > What exactly stops me, a person wanting to impersonate that user, from > putting the same QR-Code I got from that public key into my own keypair? Nothing. This latest EU implementation of a social credit system is intended to be used with an offline ID card. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. In general: unless we have other trusted person to verify that public key belongs to certain person, we can not ensure key owner identity before we have some transactions signed with this key. And we should not only trust person that has verified public key certificate, we should also know and trust the procedure this person used to verify public key certificate. And this is very important if there is a dispute, say about a signed contract. This was the flaw in pgp's web of trust: verification procedures were not known. Best regards, Viktor Ageyev CEO, Cryptonomica.net On 14/07/2021 15:45, Стефан Васильев via Gnupg-users wrote: if a person, within the EU, would put his COVID vaccination certificate QR-Code in his pub-key as photo-ID I would say that than another GnuPG user, within the EU, or maybe later in the U.S. and elsewhere too, would have the assurance, without that the public key is otherwise signed, that this pub key belongs to that person. On GitHub is a decoder available, which allows users to verify the digital signature of such COVID certs, with trustlists from EU member states. https://github.com/stapelberg/coronaqr Regards Stefan ___ 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
Re: Call me crazy, but ...
Viktor wrote: It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. But this information can be digitally verified and is issued EU wide by Governemnt trusted sources in this field. In general: unless we have other trusted person to verify that public key belongs to certain person, we can not ensure key owner identity before we have some transactions signed with this key. I think nowadays in digital age the time of single individuals who need to be trusted for digital verification purposes is long over, or how would you manage this if you, for example, are a trusted person with no sigs from others and people in other countries should trust you and your verification skills (and honesty)? And we should not only trust person that has verified public key certificate, we should also know and trust the procedure this person used to verify public key certificate. And this is very important if there is a dispute, say about a signed contract. In EU with eID and eIDAS it is all outlined and nobody has again to trust a single individual or his skill set the person used to verify a valid certificate. The reason why I opened this thread was to show users the cheapest[1] way to put digitally certified data, from trusted EU sources, which can be digitally verified, into a photo-ID, to bind the included full name to the same full name as the pub keys UID. However, just used as duplicate for comaprison and not to be uploaded to keyservers like I said in another reply. [1] In Germany exists Governikus, which acts on behalf of the BSI as CA for OpenPGP users for free, but it never took off under German GnuPG users, because it requires the purchase of an BSI certified card Reader and that the person has already a new ID-card, which this functionallity is activated in the ID-card chip. This was the flaw in pgp's web of trust: verification procedures were not known. I would say they were known, but you could not rely on them. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
> On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users > wrote: > > Viktor wrote: > >> It's the same as putting any other public information in public key >> certificate. You can put first and last name, email address and even >> photo of another person. > > But this information can be digitally verified and is issued EU wide by > Governemnt trusted sources in this field. But this puts logical causality the wrong way around. Just because the thing *being signed* is genuine, does not prove that the thing *doing the signing* is genuine. IMO this proposal is abuse of the public key infrastructure. If you want to sign an ID document, just sign an ID document and distribute it through other channels. Attaching it as a signed packet to a key adds zero value, at nonzero cost. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Andrew Gallagher wrote: On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users wrote: Viktor wrote: It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. But this information can be digitally verified and is issued EU wide by Governemnt trusted sources in this field. But this puts logical causality the wrong way around. Just because the thing *being signed* is genuine, does not prove that the thing *doing the signing* is genuine. IMO this proposal is abuse of the public key infrastructure. If you want to sign an ID document, just sign an ID document and distribute it through other channels. Attaching it as a signed packet to a key adds zero value, at nonzero cost. What abuse do you see here, if I may ask? I see it as an non-public option among virtual GnuPG friends to include in a duplicate certified data, which is not meant to been distributed on keyservers etc. or made public to the world and acts for two pub keys comparison. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
On 14-07-2021 19:32, Стефан Васильев via Gnupg-users wrote: > from trusted EU sources, We may have a different idea about "trusted". There are enough fake official ID's, like undercover police uses. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Johan Wevers wrote: On 14-07-2021 19:32, Стефан Васильев via Gnupg-users wrote: from trusted EU sources, We may have a different idea about "trusted". There are enough fake official ID's, like undercover police uses. And on the other side the WoT and OpenPGP is/was never accepted in Internet businesses, politics etc. and super good things like Governikus never took off among German GnuPG users to spread in the world to make GnuPG an accepted product for trusted digital signatures in Internet businesses etc. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Andrew Gallagher wrote: On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users wrote: Viktor wrote: It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. But this information can be digitally verified and is issued EU wide by Governemnt trusted sources in this field. But this puts logical causality the wrong way around. Just because the thing *being signed* is genuine, does not prove that the thing *doing the signing* is genuine. IMO this proposal is abuse of the public key infrastructure. If you want to sign an ID document, just sign an ID document and distribute it through other channels. Attaching it as a signed packet to a key adds zero value, at nonzero cost. What abuse do you see here, if I may ask? I see it as an non-public option among virtual GnuPG friends to include in a duplicate certified data, which is not meant to been distributed on keyservers etc. or made public to the world and acts for two pub keys comparison. Again, this does not sound very secure or make much sense to me. It also seems to make several assumptions that I do not think are proper in any security situation that would call for GPG to begin with. You want to share a secret credential that you have with someone not in person to prove identity, something which can be copied and shared with others no differently than when you shared it with them. It is like using a government-backed CA but worse because you give everyone you communicate with access to the secret. You are assuming the person you are sharing this picture with won't use it themselves to impersonate you. You are assuming the communication channel you are using to share this picture with is secure and not being intercepted or spied upon, which could result in someone stealing and using this credential themselves. This then begs the question, if you have a channel that securely communicates between the two parties (the other party you trust enough to share this secret credential with) anyways, what the need for the QR code to begin with is? Just share your public key and be done with it. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Brandon Anderson wrote: Andrew Gallagher wrote: On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users wrote: Viktor wrote: It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. But this information can be digitally verified and is issued EU wide by Governemnt trusted sources in this field. But this puts logical causality the wrong way around. Just because the thing *being signed* is genuine, does not prove that the thing *doing the signing* is genuine. IMO this proposal is abuse of the public key infrastructure. If you want to sign an ID document, just sign an ID document and distribute it through other channels. Attaching it as a signed packet to a key adds zero value, at nonzero cost. What abuse do you see here, if I may ask? I see it as an non-public option among virtual GnuPG friends to include in a duplicate certified data, which is not meant to been distributed on keyservers etc. or made public to the world and acts for two pub keys comparison. Again, this does not sound very secure or make much sense to me. It also seems to make several assumptions that I do not think are proper in any security situation that would call for GPG to begin with. You want to share a secret credential that you have with someone not in person to prove identity, something which can be copied and shared with others no differently than when you shared it with them. It is like using a government-backed CA but worse because you give everyone you communicate with access to the secret. You are assuming the person you are sharing this picture with won't use it themselves to impersonate you. You are assuming the communication channel you are using to share this picture with is secure and not being intercepted or spied upon, which could result in someone stealing and using this credential themselves. This then begs the question, if you have a channel that securely communicates between the two parties (the other party you trust enough to share this secret credential with) anyways, what the need for the QR code to begin with is? Just share your public key and be done with it. 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. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
> On 14 Jul 2021, at 19:49, Стефан Васильев wrote: > > Andrew Gallagher wrote: On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users wrote: >>> Viktor wrote: It's the same as putting any other public information in public key certificate. You can put first and last name, email address and even photo of another person. >>> But this information can be digitally verified and is issued EU wide by >>> Governemnt trusted sources in this field. >> But this puts logical causality the wrong way around. Just because the >> thing *being signed* is genuine, does not prove that the thing *doing >> the signing* is genuine. >> IMO this proposal is abuse of the public key infrastructure. If you >> want to sign an ID document, just sign an ID document and distribute >> it through other channels. Attaching it as a signed packet to a key >> adds zero value, at nonzero cost. > > What abuse do you see here, if I may ask? I see it as an non-public option > among virtual GnuPG friends to include in a duplicate certified data, which > is not meant to been distributed on keyservers etc. or made public to > the world and acts for two pub keys comparison. As currently configured, there is nothing to stop this sort of information being uploaded to a keyserver. So while keyserver operators cannot yet forbid it, we should certainly not encourage it. And in any case, we should always ask what value is being added by a particular proposal, weighed against what (potential) costs are being incurred. Remembering that costs are not always borne by those enjoying the benefits. A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
> On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users > 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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. 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
Re: Call me crazy, but ...
On 7/15/2021 12:51 AM, Стефан Васильев via Gnupg-users wrote: Brandon Anderson wrote: Andrew Gallagher wrote: On 14 Jul 2021, at 18:34, Стефан Васильев via Gnupg-users wrote: Viktor wrote: Is 'Стефан Васильев ' the same person that was ban from this very list a fiew month back? It looks like I'm seeing the same stuff as before. -- John Doe ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Brandon Anderson wrote: On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Andrew Gallagher wrote: On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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. If it would be only medical data you are correct! But, and here a big but, this medical data contains the full name and birthday of the certificate holder *digitally signed* by EU *authorities* in this field while the cert holder had to show his *valid* ID-card to the issuer. 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. As I said a duplicate key is not meant for keyserver distribution and if this should happen by accident, well than it happened. No one can be sued about this. It is or was only said in some news that one should not publish such QR-codes on social media. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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 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
Re: Call me crazy, but ...
On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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. If it would be only medical data you are correct! But, and here a big but, this medical data contains the full name and birthday of the certificate holder *digitally signed* by EU *authorities* in this field while the cert holder had to show his *valid* ID-card to the issuer. 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. As I said a duplicate key is not meant for keyserver distribution and if this should happen by accident, well than it happened. No one can be sued about this. It is or was only said in some news that one should not publish such QR-codes on social media. At its core, the problem here is you still are not proving this verifiable secret has not been shared with any other party. Are these being scanned to go to work? Are these being scanned to travel? Are these being used in other hypothetical key exchanges? I am going to assume you currently have one of these QR codes. Assuming you want me to sign your public key, prove to me now that you have never shared or shown it to anyone ever. If you cannot do this, I cannot be assured you are the actual party that is sharing it as it could have been an earlier party you shared it with or someone eavesdropping on the communication channel you shared it upon. 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
Re: Call me crazy, but ...
Brandon Anderson wrote: On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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 ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Brandon Anderson wrote: On 14 Jul 2021, at 23:52, Стефан Васильев via Gnupg-users 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. If it would be only medical data you are correct! But, and here a big but, this medical data contains the full name and birthday of the certificate holder *digitally signed* by EU *authorities* in this field while the cert holder had to show his *valid* ID-card to the issuer. 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. As I said a duplicate key is not meant for keyserver distribution and if this should happen by accident, well than it happened. No one can be sued about this. It is or was only said in some news that one should not publish such QR-codes on social media. At its core, the problem here is you still are not proving this verifiable secret has not been shared with any other party. Are these being scanned to go to work? Are these being scanned to travel? Are these being used in other hypothetical key exchanges? I am going to assume you currently have one of these QR codes. Assuming you want me to sign your public key, prove to me now that you have never shared or shown it to anyone ever. If you cannot do this, I cannot be assured you are the actual party that is sharing it as it could have been an earlier party you shared it with or someone eavesdropping on the communication channel you shared it upon. I or anybody else does not need to do that with you, only *your* virtual long time friends, having no other good option remotely. These QR-codes are meant to be carried mostly on a smartphone and if required the person can show these per request. When those codes are scanned with authorized apps no data is stored on third party servers and only the name and birthday is displayed and the signature verified, while the holder has to show his id-card as well. Regards Stefan ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Call me crazy, but ...
Is 'Стефан Васильев ' the same person that was ban from this very list a fiew month back? No, because no one was ever banned. One user, also named Stefan, was set to moderation (his messages had to be approved by an admin before appearing on list), but this was only for two weeks, and he was never banned. OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
