Mailing List Archive

> GnuPG users can interact perfectly well with people who use OpenPGP
> software :) As Robert J. Hansen said, if you (or somebody else) want to
> extend the standard, there is an IETF working group and mailing list for
> that.

Please, just "Rob". :)

I share a name with Robert "rsnake" Hansen of SecTheory. He and I have
both spoken at Black Hat and DEF CON (which has sometimes led to
hilarious results when journalists have tried to track us down to talk
about our research).

In order to reduce confusion I always use my middle initial
professionally. But I go by Rob. :)

Robert J. Hansen wrote:

> > How does this work in general, let's say I am a dev and would add
> > this too, to my OpenPGP app. Is there an OpenPGP board where devs
> > can vote for or against a feature, so that Werner has then to
> > follow suite, or is he in the position to say no and every dev has
> > to follow his GnuPG specs?
>
> The RFC is maintained under auspices of the Internet Engineering Task
> Force (IETF), just like every other RFC. The IETF's motto is "rough
> consensus and running code".
>
> Werner sits as secretary of the (largely dormant) group that guides
> OpenPGP development, but there are a lot of non-GnuPG people who are
> deeply involved in giving feedback on proposed changes. He's the
> secretary, not the dictator.

Thanks for your reply, much appreciated!

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 16-05-2020 15:57, Peter Pentchev wrote:

> But it is
> also fine for other people to say "okay, sure, you have your
> experimental features, but I'll wait until they're standardized until
> I do the work on implementing them myself; also, let's discuss whether
> they are even needed."

Have the bureaucrats who define standards have finally fixed the DOS
issues about keys spammed with signatures or is it still being
"discussed whether they are even needed."?

This strictly following standards removes all flexibility from
implementations. I am beginning to understand Moxie Marlinspike's ideas
about all these committees holding back progress better and better.

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

On 16-05-2020 17:56, Robert J. Hansen wrote:

> I tell them, "I will not be able to use OpenPGP with you until such time
> as you UID conforms to the standard.

You confuse "not being able to" with "not willing to".

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

> Have the bureaucrats who define standards have finally fixed the DOS
> issues about keys spammed with signatures or is it still being
> "discussed whether they are even needed."?

GnuPG had a bug in the key importation code which made it run in time
proportional to the square of the number of signatures. Importing a
certificate with 100,000 signatures was literally a hundred million
times slower than importing a certificate with 10.

That bug has since been fixed. With judicious use of the various -clean
options, the key spamming bug is effectively dead... on the GnuPG side:
on the SKS side, people are still filling up SKS keyservers with spam.

SKS is a completely separate project from GnuPG, and has no RFC guiding
it. So the "bureaucratic" project has it resolved, and the "free to
innovate" project has been unable to innovate.

(Note: I'm not blaming SKS. This is a hard problem. I personally don't
think SKS can be saved.)

On Sat, May 16, 2020 at 04:28:58PM -0400, Robert J. Hansen wrote:
>With judicious use of the various -clean options, the key spamming bug
>is effectively dead...

I’d like to point out that the options you are referring to are actually
enabled by default nowadays (since 2.2.17). So from an user’s point of
view, the judicious thing to do is simply to use the latest GnuPG
version available.

I am pointing that out because people could interpret your comment as
meaning that GnuPG requires some tinkering of its options in order to be
safely usable with regard to the SKS spamming issue. That’s not the
case; the default configuration is fine.

- Damien

> I’d like to point out that the options you are referring to are actually
> enabled by default nowadays (since 2.2.17).

Thank you, Damien. :)

> Werner sits as secretary of the (largely dormant) group that guides
> OpenPGP development, but there are a lot of non-GnuPG people who are
> deeply involved in giving feedback on proposed changes. He's the
> secretary, not the dictator.

Not everyone agrees.

https://mailarchive.ietf.org/arch/msg/openpgp/XxZt89Eh7XUenuVRajbgtcWzWdA/

- V

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Hey folks,

this thread touches on userid-less keys, and keyservers.

I agree with Peter and Rob's points that userid-less keys are questionable for
use as-is. OpenPGP transfers information in the self-signatures of user ids. If
we use keys without any known UID, we might miss out on e.g. expiration dates,
or key flags.

There is one more angle to this topic: key updates. keys.openpgp.org uses
userid-less keys in some cases, to distribute revocations and subkey updates.
More specifically, this happens when no User ID on a key has been verified.

The logic is simple:

1. Without consent, we don't distribute email addresses.
2. We want to distribute revocations and subkey updates regardless.
3. Revocations and key updates are cryptographically independent from User IDs.

A key store that already has a UserID for some key can integrate revocation
certificates and subkey updates from such a userid-less key into its local
certificate. Implementation-wise, this is easy to do.

GnuPG upstream rejects such updates. Conretely, if you hand a primary key with
only a revocation signature to GnuPG, it will parse the revocation, verify that
it is cryptographically valid, and then throw it away.

For those interested, this issue has been discussed at length here:
https://dev.gnupg.org/T4393

Cheers

- V


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

I'm just curious as to what this "GNU" way is? I assume you would just a
non identifiable email address and then either leave your name blank,
incomplete, or just plain incorrect.

Is there another way I am missing?

Thanks

On 5/16/2020 8:56 AM, Robert J. Hansen wrote:
>> So, when you like to communicate with a person who uses such a new
>> key how do you proceed then?
> I tell them, "I will not be able to use OpenPGP with you until such time
> as you UID conforms to the standard. Would you like help in making your
> user ID standards-conformant in a way that reveals nothing about your
> real-world identity?"
>
> This is, in fact, the preferred GNU way. "I'd love to be able to work
> with you on this document, but you're using a proprietary format I can't
> read. There's an open format we can both use, though, and I'd be happy
> to help you get started with it."
>
>
>
> _______________________________________________
> Gnupg-users mailing list
> Gnupg-users@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-users

> I'm just curious as to what this "GNU" way is? I assume you would
> just a non identifiable email address and then either leave your
> name blank, incomplete, or just plain incorrect.

GNU is a project by the Free Software Foundation. They're very focused
on what they call "free software", where freedom is about liberty and
not price. (Most people call it "open source software" instead, but FSF
and GNU are very particular about the language they use.)

FSF and GNU are both very concerned about the spread of proprietary
formats. For instance, for many years only Microsoft Word could read
.doc files. This was a problem for people who wished to only use free
software.

So the FSF/GNU way was, whenever someone tried to send them a document
in a proprietary format, was to tell the sender

> "I'd love to be able to work with you on this document, but you're
> using a proprietary format I can't read. There's an open format we
> can both use, though, and I'd be happy to help you get started with
> it."

GnuPG is part of the GNU project. I think we should use the standard
GNU response when people want us to use certificate formats that don't
comply with the OpenPGP standard.

You can learn more about the FSF at:

https://www.fsf.org/about/

You can learn more about GNU at:

http://www.gnu.org/gnu/about-gnu.html

Hope this helps.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On Sun, 17 May 2020 10:48, Vincent Breitmoser said:

> 1. Without consent, we don't distribute email addresses.

And by that changing the distributed system of keyservers into a
centralized key database like PGP tried this with their Universal
Server. Which unavoidable will change OpenPGP to a centralized systems.
If you want that use X.509 or to get complete centralization use Signal.

> 2. We want to distribute revocations and subkey updates regardless.

Go readup on the failures and impracticalities of CRLs and OCSP.

> GnuPG upstream rejects such updates. Conretely, if you hand a primary
> key with only a revocation signature to GnuPG, it will parse the
> revocation, verify that it is cryptographically valid, and then throw

There is a simple reason for that: You don't want to type in an entire
keyblock in the case you need to revoke your key and you only got the
printout of the revocation certificate.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Stefan Claas wrote:

> Robert J. Hansen wrote:

> > If you want the documentation to reflect PII-free UIDs, please say
> > that. This could be a useful discussion. If the community believes
> > PII-free UIDs should be in the FAQ I will happily write up an entry
> > for it.
>
> Please discuss it with the community and try to add it later to the
> documentation as equally treated, in the key generation process.

I would like to start the discussion, because I like to point out one
more thing, why I like the UID-less and label approach, compared to a
freeform UID.

Let's say I would regularly communicate with you, dkg and Werner etc.

In sequoia I would import the public keyblocks and could label them,
for example with rjh or rob, dkg and wk and would then use for the
recipient parameter -r rob -r dkg -r wk, which I can easily memorize.

With the freeform approach, when I would have to use (auto) generated
random chars or the fingerprint then I would have problems memorizing
if this was your, dkg's or Werner's public keyblock and it could be
also more error prone (typos), when using this method, in CLI mode.

You can argue now that you can give a freeform UID the name rob or rjh
too, but this would maybe not so good, because your are publicity known
as rob or rjh, thus defeating the purpose a bit.

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 18/05/2020 12:12, Stefan Claas wrote:
> You can argue now that you can give a freeform UID the name rob or rjh
> too, but this would maybe not so good, because your are publicity known
> as rob or rjh, thus defeating the purpose a bit.

If your threat model includes your endpoint device being compromised and
leaking your contact list, then you should be implementing an extra
layer of protection such as Tails and/or a hidden VeraCrypt volume. In
the vast majority of scenarios, endpoint compromise is Game Over, and
tinkering with obfuscation will not help you.

--
Andrew Gallagher

Andrew Gallagher wrote:

> On 18/05/2020 12:12, Stefan Claas wrote:
> > You can argue now that you can give a freeform UID the name rob or
> > rjh too, but this would maybe not so good, because your are
> > publicity known as rob or rjh, thus defeating the purpose a bit.
>
> If your threat model includes your endpoint device being compromised
> and leaking your contact list, then you should be implementing an
> extra layer of protection such as Tails and/or a hidden VeraCrypt
> volume. In the vast majority of scenarios, endpoint compromise is
> Game Over, and tinkering with obfuscation will not help you.

Agreed! It should be also mentioned, that if UID-less public keyblocks
end up more and more on keyservers it is harder for 3rd parties to
maintain a database, since as you know, everybody is still be able to
download complete keyserver dumps from SKS.

Thanks to Vincent this is no longer possible with Hagrid!

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

> And by that changing the distributed system of keyservers into a
> centralized key database like PGP tried this with their Universal
> Server. Which unavoidable will change OpenPGP to a centralized systems.

I think that's a little excessive, Werner. OpenPGP was always intended
to be flexible on the subject of certificate distribution, and there are
many use cases where a single authoritative keyserver is preferred over
a distributed federation.

In 2001 I was the chief system administrator for a law firm which used
OpenPGP to secure client communications. (It didn't require clients to
use OpenPGP but provided it as an option for clients who were concerned
about email privacy.) The procedure was simple: when you opted into
OpenPGP you showed up at your attorney's office in person with your
certificate burned on a CD. Your attorney then called in a member of
the sysadmin staff (usually me) who would check fingerprints with you,
before signing it with the firm's trusted-introducer key and uploading
it to the firm's own keyserver.

Doing it this way meant we could skip long conversations about, "but
can't anybody get my certificate if it's on the internet?" Instead of
spending 30 minutes talking about why it's okay if public certificates
are shared, we could instead just say "we're not going to share your
public key with anyone without your written consent" and spend those 30
minutes talking abut more productive things.

Centralized key management schemes are sometimes very useful.

On 18-05-2020 18:16, Robert J. Hansen wrote:

> Instead of
> spending 30 minutes talking about why it's okay if public certificates
> are shared, we could instead just say "we're not going to share your
> public key with anyone without your written consent" and spend those 30
> minutes talking abut more productive things.

Which might be a good thing for those customers, the fact alone that
someone is a customer of a certain law firm might be sensitive
information in some cases.

--
ir. J.C.A. Wevers
PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html

On Mon, 18 May 2020 12:16, Robert J. Hansen said:

> Centralized key management schemes are sometimes very useful.

I fully agree and I personally known that this is a common use case.

However, people requiring such a use case do not talk in the public
about their specific infrastructure and are also not affected by the
alleged privacy enhancements needs people are talking about.

The nice thing with OpenPGP is that you can implement any kind of PKI
with it and you are not as restricted as with X.509/PKIX. And it is
just one RFC and not several dozens RFCs and other documents you all
need to read, analyze, and guess like we see the PKIX world.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

> With the freeform approach, when I would have to use (auto) generated
> random chars or the fingerprint then I would have problems memorizing
> if this was your, dkg's or Werner's public keyblock and it could be
> also more error prone (typos), when using this method, in CLI mode.
--group {name=value}
Sets up a named group, which is similar to aliases in email pro?
grams. Any time the group name is a recipient (-r or --recipi?
ent), it will be expanded to the values specified. Multiple
groups with the same name are automatically merged into a single
group.

The values are key IDs or fingerprints, but any key description
is accepted. Note that a value with spaces in it will be treated
as two different values. Note also there is only one level of
expansion --- you cannot make an group that points to another
group. When used from the command line, it may be necessary to
quote the argument to this option to prevent the shell from
treating it as multiple arguments.

The feature you want, GnuPG already has. If my certificate had no email
address listed, you could put

group rjh@sixdemonbag.org=0x1DCBDC01B44427C7

... and then whenever you asked GnuPG to encrypt something for
rjh@sixdemonbag.org, GnuPG would silently substitute my certificate.

So let's recap:

* PII-free UIDs are possible today
* Nobody is forced to put PII in a UID
* Certificates can be relabeled with the 'group' option

It really seems like after all this discussion the only thing left is
you think GnuPG ought do a better job documenting how to create a
PII-free UID. And if you can get the community to back you on that I'll
draft it myself.

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Robert J. Hansen wrote:

> > With the freeform approach, when I would have to use (auto)
> > generated random chars or the fingerprint then I would have
> > problems memorizing if this was your, dkg's or Werner's public
> > keyblock and it could be also more error prone (typos), when using
> > this method, in CLI mode.
> --group {name=value}
> Sets up a named group, which is similar to aliases in email
> pro? grams. Any time the group name is a recipient (-r or --recipi?
> ent), it will be expanded to the values specified.
> Multiple groups with the same name are automatically merged into a
> single group.
>
> The values are key IDs or fingerprints, but any key
> description is accepted. Note that a value with spaces in it will be
> treated as two different values. Note also there is only one level
> of expansion --- you cannot make an group that points to another
> group. When used from the command line, it may be necessary
> to quote the argument to this option to prevent the shell from
> treating it as multiple arguments.
>
> The feature you want, GnuPG already has. If my certificate had no
> email address listed, you could put
>
> group rjh@sixdemonbag.org=0x1DCBDC01B44427C7
>
> ... and then whenever you asked GnuPG to encrypt something for
> rjh@sixdemonbag.org, GnuPG would silently substitute my certificate.

Thanks for the info, I was not aware of it.

> So let's recap:
>
> * PII-free UIDs are possible today
> * Nobody is forced to put PII in a UID
> * Certificates can be relabeled with the 'group' option
>
> It really seems like after all this discussion the only thing left is
> you think GnuPG ought do a better job documenting how to create a
> PII-free UID. And if you can get the community to back you on that
> I'll draft it myself.

I doubt that I can get the community to back this ... But thanks for
the offer.

Regards
Stefan

--
Signal (Desktop) +4915172173279
https://keybase.io/stefan_claas


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi


On Friday 15 May 2020 at 11:12:31 PM, in
<mid:20200515221231.GP9891@straylight.m.ringlet.net>, Peter Pentchev
wrote:-


> to generate a random UID?

Would a random UID be the way to go? How about a placeholder UID that
was replaced at the end of key generation by a UID that matches the
key-ID or fingerprint?

- --
Best regards

MFPA <mailto:2017-r3sgs86x8e-lists-groups@riseup.net>

Do what you can, with what you have, where you are.
-----BEGIN PGP SIGNATURE-----

iNUEARYKAH0WIQSWDIYo1ZL/jN6LsL/g4t7h1sju+gUCXsRutl8UgAAAAAAuAChp
c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0OTYw
Qzg2MjhENTkyRkY4Q0RFOEJCMEJGRTBFMkRFRTFENkM4RUVGQQAKCRDg4t7h1sju
+jZJAQDVaEo+PB3C0QTUfb7gctrOWZKtXCKPDkqCiv8V++1K5wD8CHrq0AOsORzX
Kv5zqkj8FJDcQvRdK4UkUv3LNKtUQwCJApMEAQEKAH0WIQRSX6konxd5jbM7JygT
DfUWES/A/wUCXsRutl8UgAAAAAAuAChpc3N1ZXItZnByQG5vdGF0aW9ucy5vcGVu
cGdwLmZpZnRoaG9yc2VtYW4ubmV0NTI1RkE5Mjg5RjE3Nzk4REIzM0IyNzI4MTMw
REY1MTYxMTJGQzBGRgAKCRATDfUWES/A/+7PEACgIrT0WJ11w3B/IXOxr8CtFVCW
4cCUlu2mWyGC2ZJolwtWvvEf5MPkd5qlBJ78y8sjG7VovZQeyd058dhFO6ScO7xs
zhdcPDGG88XE0KuHyPDaabty5s3/ZeTRIELcOf7WmKWO28MlDIe62b6uS9/10Hj6
HkGFbJovrX3x/NLdGo9Icg2UD4OduXQga+AA+qDWrqZQUeqAQSKA5+4YKqrviaZF
QBaYzUuUoAkjoVQ8DqB0a04qgvQ+ctcW+5OL6d2hMLEAFE5WWHS2MSDNAlUsESKP
Uo1zWal7DwlRCXta6QQVji4oX5w8/GPvXMNqVJkqcu6+KFDimBKSg1Rasl+BTBln
OZHY0YWGW1wTXC7xqHa/AHjW+MbL/n2IOMIxIWxmVWqbAV6WpSt+CMj5x0pnRc7V
lwN8mXA1Fh9PgLnPzPJnr/BSvNbH+yGKv3KZXLm3s97QI7KZjX0S2uXDdKNhoZe2
I9lmneUP44OHXBxODdPdPF0pBPZ1H5eLn4QB1LLYWk0Q/zby0UIa+XOKAoQ+F3ub
41OjN3ocImQj7FsqWjWZ9hOB8QyvN1e+3hVYzwwp3+nksx+q+357oyXj+m1adwGG
DZj2y5AgWdvgp82VneBNI2i8AJfGiOvJ6bRusjAUe3CbgulQvjict6MOULTZ6uDI
9AeVasGsXEmmIn6KPA==
=Xl+u
-----END PGP SIGNATURE-----


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Just to test this out I tried creating a new key in Kleopatra with no
name and then with just a single name and it would not let me do it. It
had to have a first and at least a last initial. 

On 5/19/2020 7:29 AM, Robert J. Hansen wrote:
>> With the freeform approach, when I would have to use (auto) generated
>> random chars or the fingerprint then I would have problems memorizing
>> if this was your, dkg's or Werner's public keyblock and it could be
>> also more error prone (typos), when using this method, in CLI mode.
> --group {name=value}
> Sets up a named group, which is similar to aliases in email pro?
> grams. Any time the group name is a recipient (-r or --recipi?
> ent), it will be expanded to the values specified. Multiple
> groups with the same name are automatically merged into a single
> group.
>
> The values are key IDs or fingerprints, but any key description
> is accepted. Note that a value with spaces in it will be treated
> as two different values. Note also there is only one level of
> expansion --- you cannot make an group that points to another
> group. When used from the command line, it may be necessary to
> quote the argument to this option to prevent the shell from
> treating it as multiple arguments.
>
> The feature you want, GnuPG already has. If my certificate had no email
> address listed, you could put
>
> group rjh@sixdemonbag.org=0x1DCBDC01B44427C7
>
> ... and then whenever you asked GnuPG to encrypt something for
> rjh@sixdemonbag.org, GnuPG would silently substitute my certificate.
>
> So let's recap:
>
> * PII-free UIDs are possible today
> * Nobody is forced to put PII in a UID
> * Certificates can be relabeled with the 'group' option
>
> It really seems like after all this discussion the only thing left is
> you think GnuPG ought do a better job documenting how to create a
> PII-free UID. And if you can get the community to back you on that I'll
> draft it myself.
>
> _______________________________________________
> 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

> On 20 May 2020, at 06:32, Mark <azbigdogs@gmx.com> wrote:
>
> Just to test this out I tried creating a new key in Kleopatra with no
> name and then with just a single name and it would not let me do it. It
> had to have a first and at least a last initial.

This must be a Kleopatra limitation. I have successfully created IDs consisting of a single word using the gpg command line.

Such a limitation would be user-hostile, as there are people in some cultures who have only one name, the Indonesian dictator Suharto being one famous example.

A
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

On 18/05/2020 07:14, Werner Koch via Gnupg-users wrote:
> Go readup on the failures and impracticalities of CRLs and OCSP.

While I agree that revocation is a Very Hard Problem, I'm not convinced
that its abandonment is warranted. Letsencrypt have sidestepped the
issue by issuing short-expiration certs and requiring users to
continually refresh. This is practical for servers under X509 (where
automation is easy and the trust model is centralised) but not for
hyper-distributed PGP. So while revocation cannot be entirely relied
upon, it's still better than nothing and I think we should continue to
support it as best we can.

--
Andrew Gallagher

On Tue, 19 May 2020 10:29, Robert J. Hansen said:

> * PII-free UIDs are possible today

Well, according to European law this is not that easy because a public
key is in most cases an attribute which identifies a natural person.
This is the same as with phone numbers and mail addresses. In Germany
even dynamically assigned IP addresses are attributes which can be used
to identify a person and thus are subject to GDPR.

OTOH, the GDPR does not forbid the use of this data, there are just
rules on how they can be used. WP describes the basic rules as:

Unless a data subject has provided informed consent to data processing
for one or more purposes, personal data may not be processed unless
there is at least one legal basis to do so. Article 6 states the
lawful purposes are:

(a) If the data subject has given consent to the processing of his or
her personal data;

(b) To fulfill contractual obligations with a data subject, or for
tasks at the request of a data subject who is in the process of
entering into a contract;

(c) To comply with a data controller's legal obligations;

(d) To protect the vital interests of a data subject or another
individual;

(e) To perform a task in the public interest or in official authority;

(f) For the legitimate interests of a data controller or a third
party, unless these interests are overridden by interests of the
data subject or her or his rights according to the Charter of
Fundamental Rights (especially in the case of children).

IMHO, point d covers the case of distributing and using a public key for
the purpose of securing the communication with the data subject. The
key may of course not be used for any other purpose (i.e. tracking
behaviour etc). Hacker be aware, the lay is not a machine, it works
different than we tend to assume.


Shalom-Salam,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.