Advanced
Mailing List Archive

Mailing List Archive

  1. Home >
  2. GnuPG>
  3. devel
Re: Preserving non-central and privacy with a "permission recording keyserver"
bernhard at intevation
Jul 9, 2019, 5:51 AM
Post #1 of 19 (2114 views)
Permalink
Dirk,

Am Dienstag 09 Juli 2019 14:13:36 schrieb Dirk Gottschalk via Gnupg-devel:
> Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb Bernhard Reiter:

> I am thinking abour writing a new distributed key server now for a few
> days.

the attack on the existing SKS keyservers show that we need a software
improvement. (I haven't looked at the existing solution, so I don't know if a
fresh implementation is an advantage or not.)

> In my case, just for a company in house solution, but it would be
> interwsting to make it a public solution.

There is probably some extra work involved to make it a more general solution,
but it maybe even good for the company you are working for in the mid term.
(Better tested software, more ideas, more compatibility and maybe even shared
maintenance costs in the long term.)

> Respecting the GDPR was out of scope in my case, but let's simply discuss,
> if you wish.

To me it is useful to think about what happens if there is illegal contents
in the user ids, which includes personal data without permission. This could
also happen in-house, so the ability to somehow "filter" this maybe even
necessary in-house.

> I have some thoughts about how to realize such a
> server, a little mir in Detail. I would like to discuss them, are you
> interested? Would thos be okay here on the list?

In my understanding it is fine to discuss this on the list. If the volume of
messages becomes too large, a different channel can be used. E.g.
wiki.gnupg.org could be used to write down arguments and research results.

Personally would be interested but I may not have much time to particiate
much. You know it is summer holiday period here in Germany.
My main point is that it is possible to do.

> We could even take the upload as implicated
> consent on the legal state.

Probably not, because somebody else may just create a key with a user id that
contains personal data of a different person.

> But, the possibility to share keys without
> UIDs is in some ways a good one. So you can habe ID-less keys for
> automated operations where you don't need the UIDs. By the way, is
> there a way to generate keys with GPG without UIDs? I tried, but I
> failed. Did I oversee an CLI option to do this?

I don't know. It does not seems to be forseen in RFC4880 and other common
OpenPGP implementations. And with lots of stable GnuPG revisions out there in
production and OpenPGP implementations for interoperability, it does not seem
to be a short term solution.

> WKD is in some Cases kind of problematic. Think about users of gmail,
> like me, they don't offer WKD at all. So, a second system is nice to
> have.

I agree that is is nice to have second system, if just to provide history data
and revocation or rollout information if an email provider completely drops
out.

On the gmail case I can only suggest to use an email provider that is more
privacy aware and supports WKD. (>;)) No seriously gmail my offer WKD some
day, if this is the standard emails users demand.

> Just a few lines Background: I work in some company projects, where
> other companies are involved now. Until then, we propagated the keys we
> use over DNS as CERT RRs.in our internal DNS-Server. Now this is no
> longer an options.

But why not WKD? Do you require to transport a group of pubkeys?
Then I'd suggest a https file.

Best Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 9, 2019, 6:55 AM
Post #2 of 19 (2114 views)
Permalink
Hello Bernhard.

Am Dienstag, den 09.07.2019, 14:51 +0200 schrieb Bernhard Reiter:
> Dirk,

> Am Dienstag 09 Juli 2019 14:13:36 schrieb Dirk Gottschalk via Gnupg-
> devel:
> > Am Dienstag, den 09.07.2019, 11:50 +0200 schrieb Bernhard Reiter:
> > I am thinking abour writing a new distributed key server now for a
> > few
> > days.

> the attack on the existing SKS keyservers show that we need a
> software improvement. (I haven't looked at the existing solution, so
> I don't know if a fresh implementation is an advantage or not.)

That would have to be checked. It's just a theorethical thing in my
head right now.


> > In my case, just for a company in house solution, but it would be
> > interwsting to make it a public solution.

> There is probably some extra work involved to make it a more general
> solution, but it maybe even good for the company you are working for
> in the mid term.
> (Better tested software, more ideas, more compatibility and maybe
> even shared maintenance costs in the long term.)

Yes, that's what I had in mind.


> > Respecting the GDPR was out of scope in my case, but let's simply
> > discuss, if you wish.

> To me it is useful to think about what happens if there is illegal
> contents in the user ids, which includes personal data without
> permission. This could also happen in-house, so the ability to
> somehow "filter" this maybe even necessary in-house.

A warning and a clause in terms that state "By uploading your key..."
which has to be accepted is sufficient by german law. But stripping the
UIDs also has some efforts. Hard decision. But nothing stands again
implementing both solutions.


> > I have some thoughts about how to realize such a
> > server, a little mir in Detail. I would like to discuss them, are
> > you interested? Would thos be okay here on the list?

> In my understanding it is fine to discuss this on the list. If the
> volume of messages becomes too large, a different channel can be
> used. E.g. wiki.gnupg.org could be used to write down arguments and
> research results.

> Personally would be interested but I may not have much time to
> particiate
> much. You know it is summer holiday period here in Germany.
> My main point is that it is possible to do.

Yes, I know, holidays here in NRW start by the beginning of the next
week. I will think about my ideas and write them down in the next few
days. It would be a good think to have some kind of "proposal" what
could be discusses. Even if it never leaves the stage of a theoretical
work, it would still have some benefits for the fürther development, I
think.


> > We could even take the upload as implicated
> > consent on the legal state.

> Probably not, because somebody else may just create a key with a user
> id that contains personal data of a different person.

That'S where some kind of first upload authentication comes into the
game, like Hagrid does. That's an approach that is worth consideration
in that point.

> > But, the possibility to share keys without
> > UIDs is in some ways a good one. So you can habe ID-less keys for
> > automated operations where you don't need the UIDs. By the way, is
> > there a way to generate keys with GPG without UIDs? I tried, but I
> > failed. Did I oversee an CLI option to do this?

> I don't know. It does not seems to be forseen in RFC4880 and other
> common OpenPGP implementations. And with lots of stable GnuPG
> revisions out there in production and OpenPGP implementations for
> interoperability, it does not seem to be a short term solution.

Right, I read the document a while ago. The UIDs are nothing that
disturb even in automated environments. So that's not a heavy thing.


> > WKD is in some Cases kind of problematic. Think about users of
> > gmail, like me, they don't offer WKD at all. So, a second system is
> > nice to have.

> I agree that is is nice to have second system, if just to provide
> history data and revocation or rollout information if an email
> provider completely drops out.

That's one of the points I thought about.


> On the gmail case I can only suggest to use an email provider that is
> more privacy aware and supports WKD. (>;)) No seriously gmail my
> offer WKD some day, if this is the standard emails users demand.

Yes, but there are other cases where WKD is not an option.


> > Just a few lines Background: I work in some company projects, where
> > other companies are involved now. Until then, we propagated the
> > keys we
> > use over DNS as CERT RRs.in our internal DNS-Server. Now this is no
> > longer an options.

> But why not WKD? Do you require to transport a group of pubkeys?
> Then I'd suggest a https file.

This is related to the underlaying infrastructure. This has been there
before I began working for them and I have to fight hard for any change
or improvement I want to implement.

Regards,
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
dominik at schuermann
Jul 9, 2019, 7:09 AM
Post #3 of 19 (2113 views)
Permalink
On 7/9/19 2:51 PM, Bernhard Reiter wrote:
>> We could even take the upload as implicated
>> consent on the legal state.
>
> Probably not, because somebody else may just create a key with a user id that
> contains personal data of a different person
Yep, exactly. GDPR is all about consent (Art 7). Consent can not be
given implicitly. This is generally interpreted in a way that leads to
the requirement of a double opt-in. This ensures that consent is given
by the person related to this PII ('data subject'). In simple terms: If
I upload a key with Bernhard's email address, Bernhard must be asked to
give consent. This works by sending an email to Bernhard.

One goal of keys.openpgp.org is that it's GDPR-compliant. Thus, email
validation using double opt-in is implemented.

Cheers
Dominik

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 9, 2019, 10:45 AM
Post #4 of 19 (2113 views)
Permalink
On Tue, 2019-07-09 at 16:09 +0200, Dominik Schuermann wrote:
> On 7/9/19 2:51 PM, Bernhard Reiter wrote:
> > > We could even take the upload as implicated
> > > consent on the legal state.
> >
> > Probably not, because somebody else may just create a key with a user id that
> > contains personal data of a different person
> Yep, exactly. GDPR is all about consent (Art 7). Consent can not be
> given implicitly. This is generally interpreted in a way that leads to
> the requirement of a double opt-in. This ensures that consent is given
> by the person related to this PII ('data subject'). In simple terms: If
> I upload a key with Bernhard's email address, Bernhard must be asked to
> give consent. This works by sending an email to Bernhard.
>
> One goal of keys.openpgp.org is that it's GDPR-compliant. Thus, email
> validation using double opt-in is implemented.
>

I don't really understand why e-mail validation is proper consent to
real name which is not verified at all.

--
Best regards,
Micha? Górny

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 9, 2019, 12:37 PM
Post #5 of 19 (2113 views)
Permalink
On Tue, 9 Jul 2019 14:13, gnupg-devel@gnupg.org said:

>> === Record deletions
>> If someone requests a deletion (which means this person can prove
>> that it is there personal data), this is also recorded, only by key
>> number, so this can also be synced with other keyservers.
>
> Sure, technically not a big thing.

Right, we have most tthings already in place. To delete a key the owner
of the key just needs to publish a revocation certificate. The
keyserver validates the revocation and removes everything from the key
but the primary public key and the revocation signature.

We can also make use of the reason-for-revocation flag. For example

No reason specified --> Delete as described.
Key is superseded --> Keep keyblock.
Key material has been compromised --> Delete as described
Key is retired and no longer used --> Keep keyblock

In the keep cases the server should be prepared to see another
revocation to delete the key. This is a bit questionable in the "key
compromised" case.


Salam-Shalom,

Werner

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

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 9, 2019, 4:15 PM
Post #6 of 19 (2113 views)
Permalink
Hello.

Am Dienstag, den 09.07.2019, 21:37 +0200 schrieb Werner Koch:
> On Tue, 9 Jul 2019 14:13, gnupg-devel@gnupg.org said:

> > > === Record deletions
> > > If someone requests a deletion (which means this person can prove
> > > that it is there personal data), this is also recorded, only by
> > > key
> > > number, so this can also be synced with other keyservers.

> > Sure, technically not a big thing.

> Right, we have most tthings already in place. To delete a key the
> owner of the key just needs to publish a revocation certificate. The
> keyserver validates the revocation and removes everything from the
> key but the primary public key and the revocation signature.

This is a really good starting point.

> We can also make use of the reason-for-revocation flag. For example

> No reason specified --> Delete as described.
> Key is superseded --> Keep keyblock.
> Key material has been compromised --> Delete as described
> Key is retired and no longer used --> Keep keyblock

Yes, this makes sense. For a revoked key there is no need for a UID-
Packet. A refresh would get the 'cut' packet and add the revocation.

The UID packet on the client side shoule be left untouched so that the
user is still able to see whoms key has been revoked.


> In the keep cases the server should be prepared to see another
> revocation to delete the key. This is a bit questionable in the "key
> compromised" case.

Yes, I see. In this case there shoule be some kind of additional
confirmation mechanism to avoid abuse.

Regards,
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
angel at pgp
Jul 9, 2019, 6:13 PM
Post #7 of 19 (2113 views)
Permalink
On 2019-07-09 at 19:45 +0200, Micha? Górny via Gnupg-devel wrote:
> I don't really understand why e-mail validation is proper consent to
> real name which is not verified at all.

I'm not convinced it could be done.

For validation you need a clear identifier. When you have an email you
can easily validate its owner accepts it to be published, but if there's
anything else attached to it, such as a secret you can't really validate
it.
Suppose someone uploaded a key named:
clarkentissuperman <lex@lexcorp.com>

You can programmatically check that someone which currently has access
to <lex@lexcorp.com> says "Yes, I am clarkentissuperman, own key
0xDEADBEEF and wish that key to be uploaded to the keyservers"

So far, so good, but is the name clarkentissuperman really his name (o
alias)? Or is it framing someone else?
Not only is that not automated, but it's really not decidable.

Now someone comes called Clark Kent (he provides a government issued
identification showing that), stating that such key is framing him.

Maybe. Or maybe not.
May someone have been named "clarkentissuperman"? Surely there could be
several people named Clark Kent, but who would name a kid 'superman'?¹ ²

Not to mention that it would make whole sense to use such name for
someone whose online identity was that nickname.³

The classic WoT solution uses signatures from people that validated it
IRL to vouch that the uid is correct (not that everyone does that
correctly, though).

But other than mandating the usage of keys with only an email address in
the uid field (or no uid field at all), there's little to do here.

And then, the next step would be to create a clarkentissuperman@gmail.com
account...


Best regards


¹ https://i.pinimg.com/736x/62/76/ca/6276ca0474520316f8173896835b23fe.jpg
² https://www.pinterest.com/pin/351280839654707652
³ https://en.wikipedia.org/wiki/Nymwars


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-devel
Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
bernhard at intevation
Jul 10, 2019, 12:15 AM
Post #8 of 19 (2113 views)
Permalink
Am Mittwoch 10 Juli 2019 01:15:48 schrieb Dirk Gottschalk via Gnupg-devel:
> Am Dienstag, den 09.07.2019, 21:37 +0200 schrieb Werner Koch:
> > On Tue, 9 Jul 2019 14:13, gnupg-devel@gnupg.org said:
> > > > === Record deletions
> > > > If someone requests a deletion (which means this person can prove
> > > > that it is there personal data), this is also recorded, only by
> > > > key
> > > > number, so this can also be synced with other keyservers.
> > >
> > > Sure, technically not a big thing.
> >
> > Right, we have most things already in place. To delete a key the
> > owner of the key just needs to publish a revocation certificate.

As the problem I like to solve is with personal data about A that comes
from a key that A does not control. So if A then requests deletion,
which will be possible, because otherwise it wouldn't be personal data from A,
the keyserver must record this. But because the keyserver and A do not control
the key, it must be recorded differently. It cannot be a signature of the key
in question.

Once a pubkey is found to distribute personal data of A which A does not like,
the full pubkey is not distributed anymore.

Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
bernhard at intevation
Jul 10, 2019, 12:23 AM
Post #9 of 19 (2113 views)
Permalink
Am Mittwoch 10 Juli 2019 03:13:48 schrieb Ángel:
> On 2019-07-09 at 19:45 +0200, Micha? Górny via Gnupg-devel wrote:
> > I don't really understand why e-mail validation is proper consent to
> > real name which is not verified at all.

Because if the real name is not enough to identify a person, it is not
personal data. So we publish is as non-personal data and do not need
consent.

> For validation you need a clear identifier. When you have an email you
> can easily validate its owner accepts it to be published, but if there's
> anything else attached to it, such as a secret you can't really validate
> it.

And you don't need to, we do not want to "validate" it, which is impossible,
we just want to avoid abuse and allow anonymous usage.

> Suppose someone uploaded a key named:
> clarkentissuperman <lex@lexcorp.com>

Which obviously isn't a personal data of "clarkent", because it is not
his email address.

> Now someone comes called Clark Kent (he provides a government issued
> identification showing that), stating that such key is framing him.

So the operator of the keyserver gets an email by Clark and sees by the
description that this really is personal data of him, then this operator
would manually record a deletion for this pubkey in question and note
the explanation down (for later requests).

Regards,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
andrewg at andrewg
Jul 10, 2019, 1:49 AM
Post #10 of 19 (2113 views)
Permalink
On 10/07/2019 00:15, Dirk Gottschalk via Gnupg-devel wrote:
>> In the keep cases the server should be prepared to see another
>> revocation to delete the key. This is a bit questionable in the "key
>> compromised" case.
> Yes, I see. In this case there shoule be some kind of additional
> confirmation mechanism to avoid abuse.

I don't follow. If a key is compromised, then the keyblock gets deleted.
What's the additional confirmation mechanism for?

--
Andrew Gallagher

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
andrewg at andrewg
Jul 10, 2019, 2:01 AM
Post #11 of 19 (2113 views)
Permalink
On 10/07/2019 08:15, Bernhard Reiter wrote:
> Once a pubkey is found to distribute personal data of A which A does not like,
> the full pubkey is not distributed anymore.

A validating, non-synchronising keyserver can perform this function in
the same way that any other website can, by simply deleting the data on
(reasonable) request.

--
Andrew Gallagher

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 10, 2019, 2:18 AM
Post #12 of 19 (2113 views)
Permalink
Hi Andrew.

Am Mittwoch, den 10.07.2019, 09:49 +0100 schrieb Andrew Gallagher:
> On 10/07/2019 00:15, Dirk Gottschalk via Gnupg-devel wrote:
> > > In the keep cases the server should be prepared to see another
> > > revocation to delete the key. This is a bit questionable in the
> > > "key
> > > compromised" case.
> > Yes, I see. In this case there shoule be some kind of additional
> > confirmation mechanism to avoid abuse.
>
> I don't follow. If a key is compromised, then the keyblock gets
> deleted.
> What's the additional confirmation mechanism for?

A compromised key will not be deleted in Werners scenario, just
stripped down to primary key and revocation. Not a full Detetion. The
confirmation is for the scenario when the full dataset should be
deleted. Porobably I misunderstood Werner. If so, please forgive me.

Regards,
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
andrewg at andrewg
Jul 10, 2019, 2:27 AM
Post #13 of 19 (2113 views)
Permalink
On 10/07/2019 10:18, Dirk Gottschalk wrote:
> A compromised key will not be deleted in Werners scenario, just
> stripped down to primary key and revocation. Not a full Detetion. The
> confirmation is for the scenario when the full dataset should be
> deleted. Porobably I misunderstood Werner.

Maybe *I* misunderstood Werner. :-)

I don't think we should ever delete the full dataset (i.e. including the
primary). We still need to be able to distribute revocations, and that's
only going to work if they're attached to something.

Compromised keys shouldn't be searchable by ID, so deleting everything
except the primary makes sense in such cases. Merely superseded keys
should be searchable by ID because we may wish to verify historical
signatures, and that's only possible if they are stored in full.

--
Andrew Gallagher

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
bernhard at intevation
Jul 10, 2019, 4:51 AM
Post #14 of 19 (2113 views)
Permalink
Am Mittwoch 10 Juli 2019 11:01:09 schrieb Andrew Gallagher:
> On 10/07/2019 08:15, Bernhard Reiter wrote:
> > Once a pubkey is found to distribute personal data of A which A does not
> > like, the full pubkey is not distributed anymore.
>
> A validating, non-synchronising keyserver can perform this function in
> the same way that any other website can, by simply deleting the data on
> (reasonable) request.

Yes, but I want to build a synchronising keyserver network. ;)

This is why the keyserver receiving the explicit non-permission must put this
in their list and share it with others, so the pubkey does not get
distributed by any (reasonable) keyserver anymore.

Once we know a pubkey is rouge, it shall not be distributed anymore, because
it means the key owner does not respect somebody's personal data preferences.
If this is by mistake, a new key can be generated using a different uid which
is improved in this regard.

Best,
Bernhard

--
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
andrewg at andrewg
Jul 10, 2019, 5:06 AM
Post #15 of 19 (2113 views)
Permalink
On 10/07/2019 12:51, Bernhard Reiter wrote:
> Am Mittwoch 10 Juli 2019 11:01:09 schrieb Andrew Gallagher:
>>
>> A validating, non-synchronising keyserver can perform this function in
>> the same way that any other website can, by simply deleting the data on
>> (reasonable) request.
>
> Yes, but I want to build a synchronising keyserver network. ;)

Then it can't be a validating network, because there's no way to
cryptographically validate a reasonable request, not without trusting
root authorities to sign legal documents.

> This is why the keyserver receiving the explicit non-permission must put this
> in their list and share it with others, so the pubkey does not get
> distributed by any (reasonable) keyserver anymore.

There are two ways for the key subject to deny permission - either
cryptographically, which only works if they are in possession of the
private key; or non-cryptographically, which only works if there is a
single source of (legally compelled?) truth.

That's why I proposed separating the keyserver network into validating
keyservers (hagrid, keybase.io) which validate non-cryptographic key
content but don't synchronise with each other, and caching keyservers
which sync but refer to the validating keyservers as a source of
non-cryptographic content.

--
Andrew Gallagher

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 10, 2019, 10:54 AM
Post #16 of 19 (2113 views)
Permalink
On Wed, 10 Jul 2019 10:27, andrewg@andrewg.com said:

> I don't think we should ever delete the full dataset (i.e. including the
> primary). We still need to be able to distribute revocations, and that's
> only going to work if they're attached to something.

Some folks are talking about privacy reasons not to distribute the
user-id. I don't buy this argument because the user has already given
his consent (with most MUAs and with gpg's command line) to use a mail
address along with a key and the specific format is a requirement.

Anyway in the case of a compromised key it might make sense to delete
everything but the primary key and the revocation signature: Anyone who
has access to the compromised key can add user-ids and other stuff to
the key at will and thus harm the repudiation of the user (We all know
that people don't look at details of a key, like [REVOKED], when they see
some kind of interesting data in the key). But that's up to discussion.

> except the primary makes sense in such cases. Merely superseded keys
> should be searchable by ID because we may wish to verify historical

A key on a keyserver should never be searchable by user-id. It is not
required and only an attractor to use the keyserver as free and
searchable data storage. We only need lookups by fingerprint. Keys
should in general be discovered by other reliable mail to key mapping
services. If that is not possible there is always the fallback to first
send a signed mail and the recipients tool can then lookup the key via
the fingerprint (which is embedded in the signature) at a keyserver.


Shalom-Salam,

Werner

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

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
andrewg at andrewg
Jul 10, 2019, 11:05 AM
Post #17 of 19 (2113 views)
Permalink
On 2019/07/10 18:54, Werner Koch wrote:
> On Wed, 10 Jul 2019 10:27, andrewg@andrewg.com said:
>
>> I don't think we should ever delete the full dataset (i.e. including the
>> primary). We still need to be able to distribute revocations, and that's
>> only going to work if they're attached to something.
>
> Some folks are talking about privacy reasons not to distribute the
> user-id. I don't buy this argument because the user has already given
> his consent (with most MUAs and with gpg's command line) to use a mail
> address along with a key and the specific format is a requirement.

The problem with the consent argument is that consent must be active and
explicit; you cannot presume consent just because someone has used a
service. But I don't think the consent argument is relevant, because
(IMO) keyservers fall under "subject has placed the information in the
public domain" - so long as there has been a reasonable verification
step to ensure that it was the data subject that did it.

The real trick is vindicating the right to deletion...

> Anyway in the case of a compromised key it might make sense to delete
> everything but the primary key and the revocation signature:

Agreed.

> A key on a keyserver should never be searchable by user-id. It is not
> required and only an attractor to use the keyserver as free and
> searchable data storage. We only need lookups by fingerprint. Keys
> should in general be discovered by other reliable mail to key mapping
> services. If that is not possible there is always the fallback to first
> send a signed mail and the recipients tool can then lookup the key via
> the fingerprint (which is embedded in the signature) at a keyserver.

That works for email userids. But email is only one use case for PGP, so
there is still a need for some form of lookup by ID, at least in the
short term.

--
Andrew Gallagher

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 10, 2019, 2:28 PM
Post #18 of 19 (2113 views)
Permalink
Hello Werner

Am Mittwoch, den 10.07.2019, 19:54 +0200 schrieb Werner Koch:
> On Wed, 10 Jul 2019 10:27, andrewg@andrewg.com said:
>
> > I don't think we should ever delete the full dataset (i.e.
> > including the
> > primary). We still need to be able to distribute revocations, and
> > that's
> > only going to work if they're attached to something.
>
> Some folks are talking about privacy reasons not to distribute the
> user-id. I don't buy this argument because the user has already
> given his consent (with most MUAs and with gpg's command line) to use
> a mail address along with a key and the specific format is a
> requirement.

Yes, that's my thaught.

[...]

> A key on a keyserver should never be searchable by user-id. It is
> not required and only an attractor to use the keyserver as free and
> searchable data storage. We only need lookups by fingerprint. Keys
> should in general be discovered by other reliable mail to key mapping
> services. If that is not possible there is always the fallback to
> first send a signed mail and the recipients tool can then lookup the
> key via the fingerprint (which is embedded in the signature) at a
> keyserver.

Then, the --search-keys option og gpg CLI is obsolete. That would be
okay, but this option should be disables in newer versions of gpg.

Regards,
Dirk

--
Dirk Gottschalk

GPG: 4278 1FCA 035A 9A63 4166 CE11 7544 0AD9 4996 F380
Keybase: https://keybase.io/dgottschalk
GitHub: https://github.com/Dirk1980ac

Attached Files:

Re: Preserving non-central and privacy with a "permission recording keyserver" [ In reply to ]
gnupg-devel at gnupg
Jul 10, 2019, 2:42 PM
Post #19 of 19 (2113 views)
Permalink
> Then, the --search-keys option og gpg CLI is obsolete. That would be
> okay, but this option should be disables in newer versions of gpg.

This is in progress: https://dev.gnupg.org/T4599

- V


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

©2024 GT.net. A Gossamer Threads company.
5th Floor, 455 Granville St., Vancouver, BC V6C 1T1, Canada | Legal