Re: Preventing public key upload to key-servers
Am Mo den 31. Jan 2022 um 22:39 schrieb jonkomer via Gnupg-users: > But the reason for my original post was not to find > better ways of communication mechanics while the > relationship exists, it was specific and quite narrow: > how can both sides do all they reasonably can in order > to avoid making it public knowledge that the > relationship existed *after it has been dissolved*. > > There is significant difference between a one-time > "third-party" correspondent misusing his knowledge of > the relationship after it has been dissolved, from > that same knowledge being published in perpetuity via > a simple, automated Internet query. Specifically, > the question was if there is any mitigation against > the action of an uninformed (or, perhaps by a stretch, > malicious?) correspondent adding signatures and > uploading the key to the network of synchronizing > pubkey servers. Well, there is none. Well, there is no technology that can ever prevent that human error/fault. What you want is simply not possible. Even if there is technology to prevent the upload to a key server, someone could just publish your key via twitter, or put it into bitcoin keychain or via any other way you might imagine. And even if he is not in possession of the original key, he can create a own key (setting date to somewhen in the past) with you mail address and publish it. Or what does prevent others to create a facebook account in your name? You would have pretty much trouble to get that facebook account removed again. The problem, you described, is a human problem, not a technical one. GDPR cannot prevent leaks. And when it is leaked, there is no law that could remove the data again. You can remove it from one platform but the ghost is out of the bottle. GDPR is, as I already told, just a nearly lame duck that just ignores how technology and internet works. Regards Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16Klaus Ethgen Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 31-01-2022 18:11, Andrew Gallagher via Gnupg-users wrote: > This is incorrect. All three of the commonly-used HKP servers can remove > keys; this has been done for years to remove poison (i.e. oversized) > keys that cause DoS. However doing so comes with costs. Yes, that was the issue that I know about. I seem to have mistaken HKP for SKS. -- 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 https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
This sounds like a perfect use case for WKD You are correct. But the reason for my original post was not to find better ways of communication mechanics while the relationship exists, it was specific and quite narrow: how can both sides do all they reasonably can in order to avoid making it public knowledge that the relationship existed *after it has been dissolved*. There is significant difference between a one-time "third-party" correspondent misusing his knowledge of the relationship after it has been dissolved, from that same knowledge being published in perpetuity via a simple, automated Internet query. Specifically, the question was if there is any mitigation against the action of an uninformed (or, perhaps by a stretch, malicious?) correspondent adding signatures and uploading the key to the network of synchronizing pubkey servers. Well, there is none. Europe is (in my experience) over-represented in the OpenPGP development community Then I stand corrected. (My impression was based only on the "US pop-culture coloured" and clearly emotional response to the mere mention of GDPR). Jon K. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
> On 31 Jan 2022, at 21:39, jonkomer wrote: > > There is significant difference between a one-time > "third-party" correspondent misusing his knowledge of > the relationship after it has been dissolved, from > that same knowledge being published in perpetuity via > a simple, automated Internet query. Are you worried about people discovering this relationship, or confirming a suspected relationship? A ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 28/01/2022 20:02, jonkomer via Gnupg-users wrote: >> A. G. via : >> The short answer is "no", or at best "not yet"... > > Thank you very much for the response and comprehensive > comments. > > In this case, the mail domain owner is actually the one > that needs this level of control: he insists on the ability > to positively respond to individual e-mail users' GDPR > "forget me" requests. ... > Domain owner intends to operate a "members only" public key > dissemination and fingerprint verification mechanism. When > the user is removed from the "membership", (either by the > domain owner action or by his or her own request), the mail > address (and any/all other personal data) is deleted and > promptly removed from the publicly exposed Internet domain > presence. This sounds like a perfect use case for WKD. It is under the full control of the domain owner (the data controller), and RTBF does not arise. Publication of the key is necessary to provide the service, and the data controller deletes personal data immediately on cessation of that service. > After the user removal the domain owner is ipso facto > GDPR compliant. However, he would prefer that a naive user > (rightly or not) does not consider him unresponsive, and both > sides Both sides? > have some interest in preventing any Internet server > from keeping an active and publicly exposed user's name > and (now defunct) e-mail-address, thus indiscriminately > advertising forever the fact that John Doe was at some point > in time a member of Example.org. This is not an OpenPGP-specific concern - anyone with John Doe's name and email in their address book can potentially "leak" the fact that JD was once associated with example.com, even if he never creates a public key. These are presumably the same people that he is corresponding with using OpenPGP. GDPR actively helps you here, by ensuring that if you are corresponding with a company that does business in the EU, they must have internal processes to minimise such leaks. Otherwise, you are at the mercy of your correspondents, GDPR or not. What is to stop them posting JD's contact details on Twitter, for example? Or synchronising their address books with a badly-run cloud service? > How do individual key-server owner/operators react to > formal GDPR "forget me" requests; either by e-mail users, or > by mail domain owners? Any known legal precedents? The mail domain owner cannot make an RTBF request on behalf of a user; GDPR applies to personal data, and the domain owner is not the data owner. Hockeypuck server operators can add the fingerprint of the offending key to their block list. SKS operators have to recompile, but in theory can also comply. A OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 29/01/2022 01:55, Johan Wevers via Gnupg-users wrote: > There are known technical issues: the HKP keyserver does not allow keys > to be removed, GDPR or not. When the keyserer operator operates outside > of the EU I don't think that is a legal problem. This is incorrect. All three of the commonly-used HKP servers can remove keys; this has been done for years to remove poison (i.e. oversized) keys that cause DoS. However doing so comes with costs. SKS does not properly support removing keys, however it is often patched to include a list of known poison keys that should be ignored. This obviously does not scale. Other keyservers (Hockeypuck and Hagrid) have proper support for removing keys. The longer-term cost is that keyserver sync (in SKS and Hockeypuck) degrades as the list of blocked keys grows. Hockeypuck caches sync failures and so (in theory) degrades more gracefully than SKS, which does not. A OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 29/01/2022 03:51, Shawn K. Quinn via Gnupg-users wrote: > If the server is physically in the US, administered by someone residing > in the US, is the EU really expecting US courts to enforce EU > laws/directives like the GDPR on a US citizen? The short answer is no, of course not. The practical consequence of the GDPR's "universality" is that if you want to do business in the EU, you have to comply across your worldwide operations. For mom and pop stores, this will therefore never be an issue. But for multinational companies (Google, Facebook, etc.), this has real teeth. In particular, it means that they can't hide behind "yes we broke your rules but we laundered it through another jurisdiction so you can't touch us". A OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
Unrelated note: I find the rhetoric of a few posts in this thread absolutely astounding. From a crypto question to red scare and "my army is going to kick your country's ass if it dares talk to me" in two easy steps ? This is vile. "Tell it to the Marines" is a standard American and British proverb. It even has its own Wikipedia page. Television shows like "Happy Days" and "M*A*S*H" had episodes named "Tell It to the Marines", and it was even used in a "Doctor Who" episode once. The British use it to mean "I am not so foolish as to believe your claims." In America, it can have the same meaning as the British, but we also have a sense of "your plan requires that I comply, and I will not; and any attempt to compel my compliance will be resisted with overwhelming force." When someone claims that American citizens without any connection to the EU must obey EU laws, "tell it to the Marines" and its rhetorical brethren seem entirely appropriate, in both the British and American senses. It's a profoundly silly statement which, if taken seriously, would be absolutely guaranteed to be resisted vigorously by the United States. OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On Fri, 28 Jan 2022 13:02:03 -0700, jonkomer via Gnupg-users wrote: > After the user removal the domain owner is ipso facto > GDPR compliant. However, he would prefer that a naive user > (rightly or not) does not consider him unresponsive, and both > sides have some interest in preventing any Internet server > from keeping an active and publicly exposed user's name > and (now defunct) e-mail-address, thus indiscriminately > advertising forever the fact that John Doe was at some point > in time a member of Example.org. How many signatures are expected to be on such key ? If there are none (or maybe very few, especially if none links to example.org administration), then would it be reasonable to argue that this key can have been forged and the association with that domain is an unverifiable claim ? I have no idea how it would legally fly, and there is certainly a question of scale (enough individually unverifiable but globally concordant claims become a globally convincing picture). Unrelated note: I find the rhetoric of a few posts in this thread absolutely astounding. From a crypto question to red scare and "my army is going to kick your country's ass if it dares talk to me" in two easy steps ? This is vile. -- Vincent Pelletier GPG fingerprint 983A E8B7 3B91 1598 7A92 3845 CAC9 3691 4257 B0C1 ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
PS: I guess by the "emotional reactions" you mean Robert J. Hansen mails, since replies by other people seem much more technical in nature. If by 'emotional' people mean 'amused', then yes. I thought it was cuter than a pailful of kittens. :) If by 'emotional' people mean angry, annoyed, or perturbed, then no. You shouldn't generalize from one person to "all creators and maintainers". Especially given that I'm neither of the two! OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
(changing back the thread subject) On 2022-01-29 at 09:38 -0700, jonkomer wrote: > I was the one to suggest to them to use e-mail and OpenPG > encryption. The reasons were two-fold: first to avoid one of > those centralized, web-browser based, single-point-of-failure, > essentially insecure communication setups so common today; > the second was to make their member's communication > interoperable with general Internet population in order > to increase organization's visibility and promote wider > adoption of encrypted e-mail. I posted my original question > only in order to find out some technical details on how to > do that. > > Posting the question was worthwhile, as I have learned > that: > > (a) Unfortunately, OpenPG email encryption is incompatible > with GDPR and should not be used by those that either want > or need to be GDPR compliant. That's a non-sequitur from the thread. Your GDPR issue is with people uploading keys to the PGP keyservers without consent, not with OpenPGP (which doesn't need keyserver nor even specify the use of keyservers, although they are related technology). Think about it: If you sent me a physical letter full of personal information, and I then publish it on the newspaper, with no legitimacy to do so, in violation of GDPR. Would that make snail-mail incompatible with GDPR? Regarding your problem, I would suggest not to include the first/last name in the key. Only the email address. (Yes, the name part is optional). So instead of John Smith if would simply be The name part is inherently unreliable, since it cannot know if the owner is *the* John Smith you want to write to (assuming the user is actually named John Smith!). On the other hand, the key can be easily matched with the provided email address. Of course, a member wanting to correspond with John Smith needs to find out that their email is john@example.org but that was likely already the case before, and something which is probably solved through that "internal verification mechanism" (which I'm a bit wary about, I would recommend that the keys were provided signed by the domain owner, so members would only need to trust(sign) that key to know that they have a valid example.org pgp key. They could be published through WKD. This doesn't preclude that access to the keys could require authentication). A second issue on having the users rely (and the owner needing to assert) on the name displayed on the key would have been what to do when a second John Smith wanted to become a member. Best regards PS: I guess by the "emotional reactions" you mean Robert J. Hansen mails, since replies by other people seem much more technical in nature. You shouldn't generalize from one person to "all creators and maintainers". In fact, I think -but have not checked- that most of GnuPG code will have been written inside the EU. There are lots of OpenPGP users inside the EU, under GDPR, including Government entities (as Robert J Hansen noted). ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 2022-01-28 at 20:43 -0700, jonkomer wrote: > > When the keyserer operator operates outside > > of the EU I don't think that is a legal problem. > > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. > > Jon K. Not really. If an EU resident is travelling on nonEUland, the GDPR wouldn't apply. And it protect as well an noneulander which was only temporarily on EU. In order for the GDPR to apply to a company (controller/processor) not established in the EU, the people whose data is being processed must be in the EU (irrespective of whether they are a resident or staying for a couple of days) and the company would need to be: a) offering of goods or services (even if it's for free) to such people in the Union; or b) monitoring their behavior (which takes place in the Union) See article 3 for the details: https://gdpr.eu/article-3-requirements-of-handling-personal-data-of-subjects-in-the-union/ Best regards ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 29-01-2022 4:43, jonkomer via Gnupg-users wrote: >> When the keyserer operator operates outside >> of the EU I don't think that is a legal problem. > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. That's what the EU claims. Other countries can value that opinion just as much as some other countries that want people convicted outside their borders for insulting Dear Leader. If the EU isn't ready to use the ultimate law (might makes right) then it's just a dead letter. -- 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 https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
If an individual that requests his personal information is removed (i.e., the "right to be forgotten") is EU resident, GDPR applies regardless of the jurisdiction in which the information server is located. "Right to be forgotten" doesn't exist in the United States. It's a violation of our First Amendment, which guarantees our right to communicate essentially anything that's true -- and even many things that are false! -- so long as we haven't signed a security clearance agreement. We take this so seriously that when a major news magazine wanted to publish accurate details about the design of nuclear weapons, they were allowed to do so and no one went to jail for it. (_The Progressive,_ November 1979, if you feel like looking it up in your library. It was the first public release of the physics behind the H-bomb.) If the United States is forbidden from stopping me from sharing facts about nuclear weapon design, it's also going to be forbidden from enforcing the GDPR's prohibition on my telling other people your email address. The EU likes to claim the GDPR applies everywhere information on EU residents is kept. So long as we've got United States Marines, y'all are going to have real problems convincing us of that. :) OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 1/28/22 21:43, jonkomer via Gnupg-users wrote: > If an individual that requests his personal information is > removed (i.e., the "right to be forgotten") is EU resident, > GDPR applies regardless of the jurisdiction in which the > information server is located. > > Jon K. If the server is physically in the US, administered by someone residing in the US, is the EU really expecting US courts to enforce EU laws/directives like the GDPR on a US citizen? That's the big issue with a "right to be forgotten" law: every country or almost every country has to be in agreement to enforce it or it's pretty much worthless. -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
jonkomer via Gnupg-users wrote: When the keyserer operator operates outside of the EU I don't think that is a legal problem. If an individual that requests his personal information is removed (i.e., the "right to be forgotten") is EU resident, GDPR applies regardless of the jurisdiction in which the information server is located. It may *purport* to apply, but if the keyserver is outside of EU jurisdiction, the server is outside of EU jurisdiction. This is a very good thing, or would you prefer to be subject to whatever "long arm" nonsense Communist China can cook up? -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
When the keyserer operator operates outside of the EU I don't think that is a legal problem. If an individual that requests his personal information is removed (i.e., the "right to be forgotten") is EU resident, GDPR applies regardless of the jurisdiction in which the information server is located. Jon K. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 28-01-2022 21:02, jonkomer via Gnupg-users wrote: > How do individual key-server owner/operators react to > formal GDPR "forget me" requests; either by e-mail users, or > by mail domain owners? Any known legal precedents? There are known technical issues: the HKP keyserver does not allow keys to be removed, GDPR or not. When the keyserer operator operates outside of the EU I don't think that is a legal problem. -- 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 https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
A. G. via : The short answer is "no", or at best "not yet"... Thank you very much for the response and comprehensive comments. In this case, the mail domain owner is actually the one that needs this level of control: he insists on the ability to positively respond to individual e-mail users' GDPR "forget me" requests. He is running an in-house mail server, and would like to direct "members" to use OpenGP encrypted mail for all member-to-member communication, and encourage the same for members' "general" e-mail correspondence. To this end it is desirable to give the users the option to create "personalized" mail account addresses (i.e., ) and include their first/last name in the public key. Domain owner intends to operate a "members only" public key dissemination and fingerprint verification mechanism. When the user is removed from the "membership", (either by the domain owner action or by his or her own request), the mail address (and any/all other personal data) is deleted and promptly removed from the publicly exposed Internet domain presence. In order to use OpenPG encrypted mail with the correspondents on other domains, the user must attach his public key to an outgoing message as the domain owner does not serve keys to the general Internet population. However, while the user/key is active, and with the user's permission, anybody in the possession of the public key can verify the fingerprint using the the same mechanism as is provided to the members. After the user removal the domain owner is ipso facto GDPR compliant. However, he would prefer that a naive user (rightly or not) does not consider him unresponsive, and both sides have some interest in preventing any Internet server from keeping an active and publicly exposed user's name and (now defunct) e-mail-address, thus indiscriminately advertising forever the fact that John Doe was at some point in time a member of Example.org. How do individual key-server owner/operators react to formal GDPR "forget me" requests; either by e-mail users, or by mail domain owners? Any known legal precedents? Jon K. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Preventing public key upload to key-servers
On 26/01/2022 22:03, jonkomer via Gnupg-users wrote:
> Is there anything that a public key owner can do, to actually
> *ensure* that, if some careless or malicious correspondent
> ignores the comment ("Please do not upload...") and attempts
> to upload his or her (otherwise fully functional) public key
> to the key-server(s), the key upload is rejected?
The short answer is "no", or at best "not yet".
There is a "keyserver preferences/no-modify" flag defined in rfc4880:
```
0x80 | No-modify | The key holder requests that this key only be
modified or updated by the key holder or an administrator of the key server.
```
But this is technically fraught. Most keyservers just ignore this flag,
while keys.openpgp.org effectively assumes that it is always set, but
even then doesn't behave exactly as the spec implies.
keys.openpgp.org will not publish the userID of a key until the key's
purported owner performs an email-based verification, and won't serve
third-party sigs at all. It will however serve the non-userID components
(by fingerprint search) no matter who uploaded it.
Synchronising keyservers don't perform the verification step, due to
conceptual incompatibilities between the (universal) sync model and
(subjective) verification, and so the full key material will be made
available regardless of who uploads them.
There was a proposal in the old rfc4880bis draft that the "no-modify"
flag should specifically prevent distribution of non-attested
third-party sigs, but this would still not affect distribution of the
userIDs and self-sigs, and has not been replicated in the new
crypto-refresh draft. It is also quite likely that once sig attestations
become commonplace, keyservers will stop distributing non-attested
third-party sigs regardless of whether a key owner sets this flag.
Note also that a domain administrator can publish the key of any email
address in the domain via WKD, and this is effectively equivalent to
publishing it on a keyserver.
A
OpenPGP_signature
Description: OpenPGP digital signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
