Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n95MFUbU053761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 15:15:31 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n95MFUvQ053760; Mon, 5 Oct 2009 15:15:30 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n95MFMKc053748 for ; Mon, 5 Oct 2009 15:15:30 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 77148 invoked from network); 5 Oct 2009 22:15:21 -0000 Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay03.pair.com with SMTP; 5 Oct 2009 22:15:21 -0000 X-pair-Authenticated: 216.254.70.154 Message-ID: <4ACA7100.2000801@fifthhorseman.net> Date: Mon, 05 Oct 2009 18:19:44 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: IETF OpenPGP Working Group Subject: Re: email hashes in PGP keys as protection against spam References: <200910050409.00014.mailinglisten@hauke-laging.de> <4AC975EF.8050808@fifthhorseman.net> <200910051145.40639.mailinglisten@hauke-laging.de> In-Reply-To: <200910051145.40639.mailinglisten@hauke-laging.de> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig2157C8505DA1C1116F6507AF" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2157C8505DA1C1116F6507AF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/05/2009 05:45 AM, Hauke Laging wrote: > Am Montag 05 Oktober 2009 schrieb Daniel Kahn Gillmor: >> 0) you only talk about digesting the e-mail part of the address. wha= t >> about the human-specific name? Would this need to be digested also? >> Why or Why not? >=20 > From a technical point of view that nearly does not matter so one could= =20 > leave this up to each user. i don't think you can leave this up to the user effectively, unless you want clients to need to query for a potentially-lengthy series of different digested addresses. If something like this is going to work, you need to have one widely-adopted digest, and to change it *very* infrequently, so clients would never need to try more than two digests in a search. > But there is a second argument, privacy. This is valid for the email=20 > hashing, too. In an ideal world the key server data could not be used f= or=20 > anything their "owner" does not want it to be used for. If you want to advocate for a standard for digested User IDs, I think the general privacy argument is a much stronger one than the spam argument. For example, consider a Bordurian dissident who is being persecuted by her government. She may very well want to exchange secure, private e-mails without people being able to search for her by name, and without publically binding her name to the e-mail address she's using (though she may be willing to confide that information to her associates). she may also want to take advantage of the revocation, certification, and expiration features of the WoT (all features which are enhanced by using public keyservers) without exposing the names of her personal contacts to direct review or searching on the public keyservers. Beyond names and e-mail addresses, there are other things that could be stored in an OpenPGP User ID which people might not want to be publicly enumerable or searchable, though they might want the associated material to be found if someone else already knows the relevant name. For example, i work on the Monkeysphere project, which provides a PKI for OpenSSH servers using the WoT and public keyservers as a PKI (for certification, revocation, etc). We've had some potential users express concern about using it because they don't want their infrastructure to be mappable or enumerable from the public keyservers. https://labs.riseup.net/code/issues/show/1181 Using a privately-held keyserver could solve this problem for a certain class of these users (those who maintain a "walled-garden" network, for example), but this requires an authentication/authorization policy for access to the private keyserver, it creates another point of failure in the system, and it doesn't work well at all for people who prefer a federated approach over a "walled garden" approach. Allowing these folks to take advantage of a broader keyserver network for distributing their data might make this use case more feasible. > I do not know the openpgp key format. Would it be easily possible to ad= d=20 > the signed information whether the UID of this key may or must not be=20 > uploaded to a key server in cleartext, at best distinguishing between n= ame=20 > and email? OpenPGP User IDs are defined as UTF-8-encoded textual data, and can in principle range from 0B to 4GB (though in practice i've never seen one even as long as 1KB). There's no reason that they couldn't be used to store the digest encoded as a text string. If you wanted that to work smoothly, though, you probably want to have a single unique form so that they could be found. > One small additional point: This hashing approach would be used for all= =20 > published keys, not only for key servers. I guess that most PGP users h= ave=20 > their public key on their web site. right, otherwise someone could download the key from a web site and post it to the keyservers. Note, however, that most people who publish their keys to their web site have already provided an easy way for people to come up with their name and e-mail address. Those people's contact info has probably already been transferred into a mailing list that has been sold to a spammer, so the cat is probably out of the bag for them (as it is for everyone who participates in public mailing list discussions). A proposal like this would really only be useful for people who prefer to avoid having their User ID publicly searchable in any way. But such people exist, and it would be good to allow them to use the nicer features of the WoT as well without divulging their information directly in the User ID packets. --dkg --------------enig2157C8505DA1C1116F6507AF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSspxBMzS7ZTSFznpAQr69A//Rt2XGujXN1MVK6MEhfEprT5BbbidxMgM Gg9wVLuoNs4OUDukyNJUbdtCKEanIYjhUJFv40t8RDrEEvFVCNOw5kWIKxsKW5Cp uouvhz2JjARYQAfBJ/F/0WW8ObhbgMfIBp1uqCa6QxEZamH9eqb5kYdtoWRptApd EE3o4NnDWGUFYK8QiVMMC4bJ+p0QTjVReCCFTfqxbumFtCLyzaBXj6qYHLLHgAQM hXk40X+z+AXJb7LCXctLl9ExZAO/RQntzzxA6yhM2sqoWqnbqvbZARONdqbTQrLC RoIP+y0IBjDOn/jR9MW+JTqyVRYVwjt4NFvOfLdQKpXaruZTqS/laKStngP4XMVb Xs28pFHnz38MlXRr2ZgJCAT0tRbrXFC+45WSeClsRhA75/wO0RYtRXU2mmUblSx8 WY879rbFYwdJjmvRWzZ1zCAmgw9g3dPutudf7o6WQ3ENrlGKaiQJ0dH5lp3noST0 1N+NbHytnnEeDyFyX7+vjM+iV83pyTlhgZ90GVi5u7bmBHSdIgePXgmlDNHMtx22 AfhBNlXeCa/GhfBaxzCjct83dwR+lBIMptbOftLz0SVkew+tvBbMqx+o11tTqL89 HUs37cmmmPU6LZwb/6VgMgs57QGf/Phzu8xl6hDXfaiCOgEJWy54ZYSMGBk2tYyZ gr/5AWQMsX4= =JBcU -----END PGP SIGNATURE----- --------------enig2157C8505DA1C1116F6507AF-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n959jhuD000226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Oct 2009 02:45:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n959jhUJ000225; Mon, 5 Oct 2009 02:45:43 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from wp028.webpack.hosteurope.de (wp028.webpack.hosteurope.de [80.237.132.35]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n959jgvF000218 for ; Mon, 5 Oct 2009 02:45:42 -0700 (MST) (envelope-from mailinglisten@hauke-laging.de) Received: from e178150111.adsl.alicedsl.de ([85.178.150.111] helo=inno); authenticated by wp028.webpack.hosteurope.de running ExIM with esmtpsa (TLSv1:RC4-SHA:128) id 1Muk8T-0000hK-Ho; Mon, 05 Oct 2009 11:45:41 +0200 From: Hauke Laging To: IETF OpenPGP Working Group Subject: Re: email hashes in PGP keys as protection against spam Date: Mon, 5 Oct 2009 11:45:40 +0200 User-Agent: KMail/1.9.10 References: <200910050409.00014.mailinglisten@hauke-laging.de> <4AC975EF.8050808@fifthhorseman.net> In-Reply-To: <4AC975EF.8050808@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200910051145.40639.mailinglisten@hauke-laging.de> X-bounce-key: webpack.hosteurope.de;mailinglisten@hauke-laging.de;1254735942;86c34e64; Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Am Montag 05 Oktober 2009 schrieb Daniel Kahn Gillmor: Hello, > Interesting proposal (about digesting User IDs), but i suspect that the > ietf's openpgp working group is a better place to discuss this kind of > change than the tool-specific gpg-devel list. of course, this in a general approach, not a tool specific one. I didn't=20 know that this working group exists. On the other hand the technical part=20 seems quite easy to me so it might be helpful if somebody just did it for=20 one tool (not officially, rather for testing purposes) so that one could=20 play around with it and discuss the general implementation based on some=20 experience > For that reason, i'm sending my reply there, and i've set Reply-To there > as well. i hope that's OK with you. Sure, I have subscribed to that list now. > some questions your proposal raises for me: > > 0) you only talk about digesting the e-mail part of the address. what > about the human-specific name? Would this need to be digested also? > Why or Why not? =46rom a technical point of view that nearly does not matter so one could=20 leave this up to each user. I think that the spam protection effect of hiding names is quite limited.=20 You prevent trying firstname.lastname@popularmailservice.com only. Would=20 any spammer do that? Names can be fetched from other sources though less=20 clear (from a parser's perspective). But there is a second argument, privacy. This is valid for the email=20 hashing, too. In an ideal world the key server data could not be used for=20 anything their "owner" does not want it to be used for. Thus I suggest to let the user decide whether he wants his name hashed or=20 not. The problem with names is that their notation is less clear than that= =20 of email addresses, at least for names which contain "strange" characters=20 and people with several first names (mentioned at all, fully written or=20 just the initial?). When talking about privacy the same question moves to the comment field.=20 Hashing it does not make much sense to me as this information cannot=20 easily obtained from another source. So I would leave it empty or in=20 cleartext. The PGP usage may change to fetching the raw key from a server and=20 receiving the full key from its owner with the first reply. > 1) your proposal lacks a concrete example case; What would the User ID > for 'Jane Doe ' look like under this policy? The > devil is often in the details, and an explicit example would help sort > out the details. "Jane Doe" -> cac7bbb6b67b44ea0ab997d34a88e4ea9b4d3d62 jane@example.org -> 77baeb8633437c80bc3f06a7bcfbad66185ca14b I see three possible variants: =2D the email hash only =2D cleartext name and email hash 'Jane Doe ' =2D name and email hashed 'sha1:cac7bbb6b67b44ea0ab997d34a88e4ea9b4d3d62=C2=A0' I just notice a problem: You obviously have to know the hash function which= =20 the key owner has used. So if you want to allow several functions you have= =20 to accept the additional traffic at the key servers by trying all=20 functions. > 2) Would the act of keysigning need to change under your proposal? If > so, what would keysigners need to do differently than they currently do? This act would not have to change at all. Everything could be done within=20 the gpg software. I would mainly change the key listing format as it does=20 not make sense to show all UIDs twice (thus suppredd hash UIDs by=20 default). But it makes sense to ask for the hashed string. As my description points=20 out you will hardly ever meet a raw hash key, one for which you don't have= =20 the cleartext UID (or at least email). So if the pgp software is to sign a= =20 hashed key it should check that the hash matches the additional (outside=20 the key) information. But this ist just an organizational help to guard=20 against malicious keys, not a technical requirement. I do not know the openpgp key format. Would it be easily possible to add=20 the signed information whether the UID of this key may or must not be=20 uploaded to a key server in cleartext, at best distinguishing between name= =20 and email? One small additional point: This hashing approach would be used for all=20 published keys, not only for key servers. I guess that most PGP users have= =20 their public key on their web site. Hauke Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n954OCTP080610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Oct 2009 21:24:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n954OCLQ080608; Sun, 4 Oct 2009 21:24:12 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n954O6mM080596 for ; Sun, 4 Oct 2009 21:24:11 -0700 (MST) (envelope-from dkg@fifthhorseman.net) Received: (qmail 48514 invoked from network); 5 Oct 2009 04:24:05 -0000 Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay00.pair.com with SMTP; 5 Oct 2009 04:24:05 -0000 X-pair-Authenticated: 216.254.116.241 Message-ID: <4AC975EF.8050808@fifthhorseman.net> Date: Mon, 05 Oct 2009 00:28:31 -0400 From: Daniel Kahn Gillmor Reply-To: IETF OpenPGP Working Group User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) MIME-Version: 1.0 To: Hauke Laging CC: GnuPG Development List , IETF OpenPGP Working Group Subject: Re: email hashes in PGP keys as protection against spam References: <200910050409.00014.mailinglisten@hauke-laging.de> In-Reply-To: <200910050409.00014.mailinglisten@hauke-laging.de> X-Enigmail-Version: 0.95.7 OpenPGP: id=D21739E9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9433F6C8AF79B89EAD7A282B" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9433F6C8AF79B89EAD7A282B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hauke-- Interesting proposal (about digesting User IDs), but i suspect that the ietf's openpgp working group is a better place to discuss this kind of change than the tool-specific gpg-devel list. For that reason, i'm sending my reply there, and i've set Reply-To there as well. i hope that's OK with you. On 10/04/2009 10:08 PM, Hauke Laging wrote: > The description is on my web site: > http://www.hauke-laging.de/ideen/gpg-hash/index.en.html [...] > Of course, I am interested in comments in order to improve the concept = if=20 > necessary. (full message here: http://lists.gnupg.org/pipermail/gnupg-devel/2009-October/025378.html ) some questions your proposal raises for me: 0) you only talk about digesting the e-mail part of the address. what about the human-specific name? Would this need to be digested also? Why or Why not? 1) your proposal lacks a concrete example case; What would the User ID for 'Jane Doe ' look like under this policy? The devil is often in the details, and an explicit example would help sort out the details. 2) Would the act of keysigning need to change under your proposal? If so, what would keysigners need to do differently than they currently do? Regards, --dkg --------------enig9433F6C8AF79B89EAD7A282B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSsl18MzS7ZTSFznpAQoQXg//QVxbwJMcXE4r3op3cqS1iv3KUgtjlzgd dDF2WwYhqDE8mANBvf69NqJ7J1uM3wCi6S1UIfB0J3rjcG+NmEkN7RtsTbUmW+Pz p3tAdenanba3pL2UuZAxsxx+27a2G5uEzTSsl6BkFhhrikTjDBhKIxJaN85Lehs6 OyGTtj2zEi0AGMC890T/647kElFMe0C5g2BclOUTfmhyj1SllVdpjdw7I9KZGKjv 05Z0BoZNQibfm2MV4GFnYj6Yw38x3Nuf1FctzSKDRIndps9/HFd78o+0Rg45eSkI 5ZQQt40NucCATqSmOuxXqE1bfYXnVzG6cm8NckP/Z5a7GiTRJHz5veoIuDGlY3Os itv9e80YWjRRUfXXzO8AJxuAVurtZJ1/hL7xSUmu4so0WvIUz0Ja/dvyWw/J3XEt Lq7N7KwI7/AXUdSRQGIOfMdq9S/OKd8Ki/8q9/J6F4NN3pQIMv3ojzKW8gkG7vLJ LYjfB+N/8IoEg3YRUuQh316dDPXxZziNIRoCjfQPQlyzOXroVdSPRKrAVryUYAkA +GlFiCquQWnvFeEnD2KUr4wJrMP2KtX6lbMNGEnjH9YP7H1X8PKQJDoseFVAPf7H Q1kVVNiYycXVZScDFzVC5i0NM+lx6runIWN4Uifjod3vh5dqDiPW1MKP/MW9hyKC RmtaE+4wgyE= =sPPk -----END PGP SIGNATURE----- --------------enig9433F6C8AF79B89EAD7A282B--