Re: [Sks-devel] GDPR (equine corpse) (WAS: Re: The pool is shrinking)

[brent s.]

On 8/17/19 8:08 AM, Stefan Claas wrote:
> brent s. wrote:
> 
>> 4.) *Real* identifiable personal information is by *no means* a
>> requirement for the creation of a key, nor making it available on a
>> keyserver. Granted, you're going to face some challenges at a
>> traditional keysigning party, but simply
> 
> How about email submission like we had in the '90s and getting
> rid of --send-keys or the WWW submit button?
> 
> I believe installing postfix or exim etc. can be easily done
> by operators and a person could quickly write a script which
> then pipes the received keys to the database.
> 
> Regards
> Stefan
> 

I'm going to anticipate what you're suggesting this solves - that only
key owners can upload their own key by ensuring the sender matches one
of the key's identities. There's flaws with that:

1.) You've now broken the ability to upload keys with no real
identifiable information (i.e. no real email address), thus *forcing*
users of a keyserver to provide personal identifiable information. This
breaks anonymity.

2.) Key signatures (key signatures are called "certifications" in the
design documentation) are now broken since signers cannot upload key
signatures, breaking the Web-of-Trust. When you upload a certification,
you are uploading the updated public key. You can strip certifications
from a key, you can't strip a key from certifications. See RFC 4880[0] §
11.1[1]. Actually, read the whole RFC. It's insightful and gives a lot
of knowledge into the output from "gpg --list-packets".

   a.) inb4 "But why can't the signer just send the updated key to the
key owner, and the owner can upload it?"

       See #1. While I have this feature in a keysigning tool I wrote[2]
(which is currently incredibly messy and needs a major refactoring, I
know), it still only works if the signed key has a valid email address
and it furthermore would still require a valid email address by the
owner to upload to a keyserver if email addresses were received by mail
(even if the signed key was passed to the owner via a previously agreed
upon non-email/alternate email communication).

   b.) Remember, key signatures are intended for public consumption -
it's how trust is arbitrated via the Web-of-Trust so you can apply trust
levels to keys that you yourself have not been able to directly verify
with the owner. The Web-of-Trust is not flat, it's by degrees (e.g. "Bob
signed Alice's key, and I trust Bob's veracity in checking validity of
key ownership completely because I know how thorough he is, so I can
apply a medium level of trust to this key locally" - which also, thanks
to the Web-of-Trust, allows others to trust Alice AND Bob's key because
you trust Bob.[3]

   c.) Similarly, this also requires the *signer* to expose a real email
address to the owner of the key they signed at the LEAST, breaking the
*signer's* option for anonymity (and requires that at LEAST the key
owner know beforehand which communication identity the signed key is
coming from).

3.) This also depends further on an MTA being run on keyservers (or at
the least in tandem with them by the same operator). Running a mail
server is not a demand to be made lightly on anyone, given that mail is
a quagmire that the inexperienced should not approach lightly. There's a
reason that many places have a single operator designated entirely to
the maintenance of their email.



[0] https://tools.ietf.org/html/rfc4880
[1] https://tools.ietf.org/html/rfc4880#section-11.1
[2] https://git.square-r00t.net/OpTools/tree/gpg/kant
[3] https://www.gnupg.org/gph/en/manual/x547.html
    (pay close attention to paragraphs 3 and 4)

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature