From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:13 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09203 for ; Fri, 9 Jan 2004 10:58:12 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06HW2ib052321 for ; Tue, 6 Jan 2004 09:32:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i06HW1LH052320 for ietf-openpgp-bks; Tue, 6 Jan 2004 09:32:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06HVwib052312 for ; Tue, 6 Jan 2004 09:31:59 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 7764669A9F; Tue, 6 Jan 2004 12:31:59 -0500 (EST) Message-ID: <3FFAF072.9F35AB8E@systemics.com> Date: Tue, 06 Jan 2004 12:29:22 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: ietf-openpgp@imc.org Subject: Re: cleartext signed messages - UTF-8 - stripping the whitespace References: <3FF981B2.91E72DAF@systemics.com> <200401052057.21742@fortytwo.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Adrian 'Dagurashibanipal' von Bidder wrote: > > On Monday 05 January 2004 16:24, Ian Grigg wrote: ... > > 3. What was the original deep dark motivation > > for stripping whitespace from the end of lines > > anyway? > > > > 4. Do we care if UTF-8 has some weird whitespace/ > > line endings? > > IIRC from previous discussions (I wasn't around for years when PGP was > introduced to the world...): some mailers (MUAs and MTAs) used to strip > whitespace occasionally or do other weird things. Thinking about it, I've come across editors and desktops that do something similar, they add spaces to the end of lines in arbitrary fashions, and sometimes modify newlines (take away, add) at the end of files (but newlines are adequately protected already in the draft). > Those old mailers would probably either treat all non-ASCII whitespace and > line-endings as normal characters, or not be 8-bit clean anyway and so cause > problems in any case. So the answer to (4) is probably a clear no. So, the upshot is that only the defined US-ASCII whitespace chars should be included in the canonicalisation: .... Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. In which case it might be worth adding a comment to that effect. Because of the difficulties of predicting the future here, I'd suggest the following: Also, any trailing whitespace (0x20, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Implementations MAY elect to clean line endings of whitespace in the final signed form of the document, including UTF-8 forms. Thus, when we hit upon some troublesome mailer that mangles non-english language Word-prepared UTF-8 documents, the OpenPGP plugin can pre-emptively clean it up and still be in accord with the standard. If applications start adding UTF-8 whitespace afterwards, then we have more of a problem. I guess at that point, implementations can agree to add additional characters to the "ignore" list. iang From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09221 for ; Fri, 9 Jan 2004 10:58:15 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05JvQib011098 for ; Mon, 5 Jan 2004 11:57:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05JvQnn011097 for ietf-openpgp-bks; Mon, 5 Jan 2004 11:57:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from gluggsi.fortytwo.ch (zux006-032-031.adsl.green.ch [81.6.32.31]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05JvOib011085 for ; Mon, 5 Jan 2004 11:57:25 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: from altfrangg.fortytwo.ch (altfrangg.fortytwo.ch [192.168.1.17]) by gluggsi.fortytwo.ch (Postfix) with ESMTP id 4869198FE1 for ; Mon, 5 Jan 2004 20:57:22 +0100 (CET) From: "Adrian 'Dagurashibanipal' von Bidder" To: ietf-openpgp@imc.org Subject: Re: cleartext signed messages - UTF-8 - stripping the whitespace Date: Mon, 5 Jan 2004 20:57:18 +0100 User-Agent: KMail/1.5.4 References: <3FF981B2.91E72DAF@systemics.com> In-Reply-To: <3FF981B2.91E72DAF@systemics.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_hGc+/fRzPla9c3B"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401052057.21742@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_hGc+/fRzPla9c3B Content-Type: text/plain; charset="iso-8859-1" Content-Description: signed data Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Monday 05 January 2004 16:24, Ian Grigg wrote: [...] > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > 2. Are there UTF-8 whitespace encodings that > are not in the definitions above? > > I.e., not in "spaces, and tabs, 0x09" . > > 3. What was the original deep dark motivation > for stripping whitespace from the end of lines > anyway? > > 4. Do we care if UTF-8 has some weird whitespace/ > line endings? IIRC from previous discussions (I wasn't around for years when PGP was=20 introduced to the world...): some mailers (MUAs and MTAs) used to strip=20 whitespace occasionally or do other weird things. Those old mailers would probably either treat all non-ASCII whitespace and= =20 line-endings as normal characters, or not be 8-bit clean anyway and so caus= e=20 problems in any case. So the answer to (4) is probably a clear no. cheers =2D- vbi =2D-=20 featured product: PostgreSQL - http://postgresql.org --Boundary-02=_hGc+/fRzPla9c3B Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAj/5waFgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWSdkAn1Udm/e8rfsOeCFf+f+utjjE pf6zAJoD8YFkbqWtdRhBXDeorb/ye0D+mA== =iY1l -----END PGP SIGNATURE----- --Boundary-02=_hGc+/fRzPla9c3B-- From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:22 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09223 for ; Fri, 9 Jan 2004 10:58:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05FRBib098152 for ; Mon, 5 Jan 2004 07:27:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05FRB5x098151 for ietf-openpgp-bks; Mon, 5 Jan 2004 07:27:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05FRAib098146 for ; Mon, 5 Jan 2004 07:27:10 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 8644069A80; Mon, 5 Jan 2004 10:27:11 -0500 (EST) Message-ID: <3FF981B2.91E72DAF@systemics.com> Date: Mon, 05 Jan 2004 10:24:34 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: cleartext signed messages - UTF-8 - stripping the whitespace Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm working on some code that deals with cleartext signed messages over UTF-8 [1]. In debugging the treatment of UTF-8, I looked at the definition of mods that OpenPGP does to the cleartext (paras 3,5) for signature treatment [2]: As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical line endings. The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. .... Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Here are the questions: 1. In UTF-8, are there such things as line endings that are not of and/or form? 2. Are there UTF-8 whitespace encodings that are not in the definitions above? I.e., not in "spaces, and tabs, 0x09" . 3. What was the original deep dark motivation for stripping whitespace from the end of lines anyway? 4. Do we care if UTF-8 has some weird whitespace/ line endings? 5. Are we explicitly ignoring these? Hence the question 3, perhaps the answer can guide us.... It seems the easiest thing is to say that we explicitly do not include any UTF-8 characters in the above discussion. And add a clarifying comment to that effect. Perhaps also something to the effect of: Implementations MAY strip whitespace (including any UTF-8 whitespace that is recognised) from line endings before signing, so that the resultant cleartext signed message will not include any complex lines. (That's essentially what I try and do in my code, but I recognise that this goes beyond the standard....) Alternatively, if someone can nail what UTF-8 does in whitespace, it might be possible to put in more consideration. iang [1] Code is based on Edwin Woudt's OpenPGP in Java as found at http://www.cryptix.org/products/openpgp/index.html The application is Ricardian Contracts in Spanish. [2] Looking at at section 7.1, Dash-Escaped Text, of the current draft: draft-ietf-openpgp-rfc2440bis-09.txt http://carmen.cselt.it/internet-drafts/draft-ietf-openpgp-rfc2440bis-09.txt From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09225 for ; Fri, 9 Jan 2004 10:58:23 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EwVib097109 for ; Mon, 5 Jan 2004 06:58:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05EwVjB097108 for ietf-openpgp-bks; Mon, 5 Jan 2004 06:58:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EwRib097102 for ; Mon, 5 Jan 2004 06:58:28 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id A799569A80; Mon, 5 Jan 2004 09:58:22 -0500 (EST) Message-ID: <3FF97AF0.A32F3D24@systemics.com> Date: Mon, 05 Jan 2004 09:55:44 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: cleartext signatures - consistent naming Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Searching on the draft 2440bis-09.txt, I find several variations of the cleartext signature naming: signatures following clearsigned messages. p48 particularly important when computing a cleartext signature This is used only in clear-signed messages. p49 7. cleartext signature framework another way to clear sign messages ... The cleartext signed message consists of: ... It seems that the word "cleartext" is the dominant form, followed by signing in some appropriate verb form. It would be nice if the parts outside section 7 (lines 1,3 above) also used that convention, to make searching easier. iang From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09295 for ; Fri, 9 Jan 2004 10:58:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05DVuib092704 for ; Mon, 5 Jan 2004 05:31:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05DVu3n092703 for ietf-openpgp-bks; Mon, 5 Jan 2004 05:31:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from zbasel.fortytwo.ch (postfix@zbasel.fortytwo.ch [212.254.206.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05DVtib092698 for ; Mon, 5 Jan 2004 05:31:55 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: from onaras.ch (zux174-013.adsl.green.ch [80.254.174.13]) by zbasel.fortytwo.ch (Postfix) with ESMTP id 91C3F103; Mon, 5 Jan 2004 14:31:51 +0100 (CET) From: Adrian von Bidder To: , Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide? Date: Mon, 5 Jan 2004 14:31:50 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_GdW+/lK0Ha2Hbm9"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401051431.50915@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_GdW+/lK0Ha2Hbm9 Content-Type: text/plain; charset="iso-8859-1" Content-Description: signed data Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [sorry. ralf, of course I meant to answer to the lists] On Monday 05 January 2004 14:06, Ralf Hauser wrote: > To my understanding, > > If I send a message with attachments, the attachment filename is visible > without cryptanalysis. > Would it be hard to give the encrypted file a random name and only upon > decryption, give it back its real name? > > http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this > issue. > > Isn't that kind of giving away information that could be easily protected= - > or did I miss something? Hi, You did miss rfc3156 (PGP/MIME). The structure of these (encrypted) emails = is: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =46rom: whatever To: whatever Subject: whatever Date: whatever Content-Type: multipart/encrypted; protocol=3D"application/pgp-encrypted"; boundary=3D"Boundary-02=3D_5Plx/pJ9Yq8C9E0" =2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0 Content-Type: application/pgp-encrypted Version: 1 =2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0 Content-Type: application/octet-stream =2D----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.3 (GNU/Linux) hQEOAzLIxTMIwnnYEAP.... =2E... AFWzv4cn5IDmQ5A93JaApgQg6g=3D=3D =3DpVu5 =2D----END PGP MESSAGE----- =2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D And the encrypted part is again a full MIME message, with attachments and a= ll.=20 So the only relevant bits that go over the wire unencrypted are From/To=20 (unavoidable to the extent of the email addresses) and the Subject (I have = a=20 proposal that could address this cooking slowly, I think I posted it in som= e=20 places a few months ago). Greetings =2D- vbi =2D-=20 joeyh now has a terminal at the couch? That guy is wired, I swear =3D3D> Knghtbrd: laptop and I don't mean the cats. --Boundary-02=_GdW+/lK0Ha2Hbm9 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAj/5Z0ZgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6+swAn0FQMt82dPEXK1qy7bMqhNtm whPDAJ4wcQcQqaRF/6xP9kvqrwofqtlHBA== =ahv8 -----END PGP SIGNATURE----- --Boundary-02=_GdW+/lK0Ha2Hbm9-- From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:33 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09261 for ; Fri, 9 Jan 2004 10:58:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EAWib094068 for ; Mon, 5 Jan 2004 06:10:32 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05EAVuT094067 for ietf-openpgp-bks; Mon, 5 Jan 2004 06:10:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EASib094060 for ; Mon, 5 Jan 2004 06:10:28 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 9B89910E59D; Mon, 5 Jan 2004 06:10:28 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id i05EASKs055906; Mon, 5 Jan 2004 06:10:28 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id i05EASOX055905; Mon, 5 Jan 2004 06:10:28 -0800 (PST) Message-Id: <200401051410.i05EASOX055905@mailserver2.hushmail.com> Date: Mon, 5 Jan 2004 06:10:28 -0800 To: ietf-openpgp@imc.org, gnupg-users@gnupg.org Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 05 Jan 2004 05:06:54 -0800 Ralf Hauser wrote: > >To my understanding, > >If I send a message with attachments, the attachment filename is >visible >without cryptanalysis. >Would it be hard to give the encrypted file a random name and only >upon >decryption, give it back its real name? there is a simple workaround you might be interested in: armor the attachment (without encryption) and include the armored attachment as part of the plaintext of the message, and then encrypt the entire message not only the filename, but even the fact that you are sending an attachment, will not be apparent (although it may be guessed at by the size of the message) vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:40 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09293 for ; Fri, 9 Jan 2004 10:58:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05Desib092958 for ; Mon, 5 Jan 2004 05:40:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05DesnV092957 for ietf-openpgp-bks; Mon, 5 Jan 2004 05:40:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ethos.braverock.com (IDENT:G8oh9If5RDETGXsm7dHrgW7BApljLOqq@dsl092-142-180.chi1.dsl.speakeasy.net [66.92.142.180]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05Derib092952 for ; Mon, 5 Jan 2004 05:40:53 -0800 (PST) (envelope-from brian@braverock.com) Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by ethos.braverock.com (8.12.8/8.12.5) with ESMTP id i05DeoTl030326; Mon, 5 Jan 2004 07:40:50 -0600 Received: (from apache@localhost) by ethos.braverock.com (8.12.8/8.12.5/Submit) id i05DenAX030324; Mon, 5 Jan 2004 07:40:49 -0600 Received: from 38.115.154.129 (SquirrelMail authenticated user brian); by mail.braverock.com with HTTP; Mon, 5 Jan 2004 07:40:49 -0600 (CST) Message-ID: <62000.38.115.154.129.1073310049.squirrel@38.115.154.129> In-Reply-To: References: Date: Mon, 5 Jan 2004 07:40:49 -0600 (CST) Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide? From: "Brian G. Peterson" To: hauser@acm.org Cc: ietf-openpgp@imc.org, gnupg-users@gnupg.org User-Agent: SquirrelMail/1.4.3 [CVS] X-Mailer: SquirrelMail/1.4.3 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Ralf Hauser said: > > To my understanding, > > If I send a message with attachments, the attachment filename is visible > without cryptanalysis. > Would it be hard to give the encrypted file a random name and only upon > decryption, give it back its real name? > > http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this > issue. > > Isn't that kind of giving away information that could be easily protected > - > or did I miss something? > > Rgds > Ralf Ralf, This is totally an implementation detail. Many mail programs that integrate PGP or GnuPG already *do* obfuscate the filename, calling it encrypted.dat.asc or data.asc or somerandomstring.asc. If the asc file has an embedded filename, any OpenPGP compatible client should be able to retrieve the file name upon decryption. There are times when knowing the filenmae may be more important than obfuscating it for security reasons. The reverse is most certainly true as well. In my opinion, it should probably be left as an implementation detail for each OpenPGP compatible mail client to decide on. Regards, - Brian From owner-ietf-openpgp@mail.imc.org Fri Jan 9 10:58:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09297 for ; Fri, 9 Jan 2004 10:58:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05D5Nib091759 for ; Mon, 5 Jan 2004 05:05:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05D5Nwk091758 for ietf-openpgp-bks; Mon, 5 Jan 2004 05:05:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.10/8.12.8) with SMTP id i05D5Hib091744 for ; Mon, 5 Jan 2004 05:05:18 -0800 (PST) (envelope-from ralfhauser@gmx.ch) Received: (qmail 7943 invoked by uid 65534); 5 Jan 2004 13:05:11 -0000 Received: from adsl-62-167-79-128.adslplus.ch (EHLO rhauserPCGF590K) (62.167.79.128) by mail.gmx.net (mp014) with SMTP; 05 Jan 2004 14:05:11 +0100 X-Authenticated: #14555992 Reply-To: From: "Ralf Hauser" To: , Subject: filenames of encrypted attachments visible ? How hard would it be to hide? Date: Mon, 5 Jan 2004 14:06:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit To my understanding, If I send a message with attachments, the attachment filename is visible without cryptanalysis. Would it be hard to give the encrypted file a random name and only upon decryption, give it back its real name? http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this issue. Isn't that kind of giving away information that could be easily protected - or did I miss something? Rgds Ralf Sample use case: Some investment banker uses PGP and sends around an attachment with the name "UnfriendlyTakeoverOfListedCorpXYZ.doc.asc" - isn't that kind of an invitation to insiders? Sure, it wouldn't be hard to rename the file before sending, but this kind of negligence is happening all over... and I hope applications like gpg/pgp could eventually become fool-proof/fail-safe to this level? From subs-reminder@imc.org Fri Jan 9 11:18:00 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10659 for ; Fri, 9 Jan 2004 11:17:57 -0500 (EST) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i072a5ib003932 for ; Tue, 6 Jan 2004 18:36:05 -0800 (PST) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i072a5Cn003931; Tue, 6 Jan 2004 18:36:05 -0800 (PST) Date: Tue, 6 Jan 2004 18:36:05 -0800 (PST) Message-Id: <200401070236.i072a5Cn003931@above.proper.com> To: openpgp-archive@ietf.org Subject: [[442247616]] Subscription to ietf-openpgp for openpgp-archive@lists.ietf.org Greetings. This message is a periodic reminder that openpgp-archive@lists.ietf.org is subscribed to the ietf-openpgp mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openpgp mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openpgp-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "openpgp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openpgp@mail.imc.org Mon Jan 12 15:26:19 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17093 for ; Mon, 12 Jan 2004 15:26:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CJx1ib003097; Mon, 12 Jan 2004 11:59:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CJx1IN003096; Mon, 12 Jan 2004 11:59:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CJwxib003090 for ; Mon, 12 Jan 2004 11:59:00 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0CJwBE15591 for ietf-openpgp@imc.org; Mon, 12 Jan 2004 14:58:11 -0500 Date: Mon, 12 Jan 2004 14:58:11 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: The last word (hopefully) on back-signatures Message-ID: <20040112195811.GB3329@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (76% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Apologies for the delay in this. I've had a lot on my plate recently. In November, I posted two proposals for comment on the "stolen signature"/back-signatures problem. Here now is my final proposal with the various comments taken into account: First to briefly recap the purpose for this, there is a minor problem in the current subkey design where a signing subkey can be taken from an existing key, and bound to the attacker's primary key with a binding signature issued by the attacker's key. The attacker cannot use this stolen key to issue a signature of course, but can claim that an existing signature was issued by him. The proposed fix is to add an additional signature into the mix - currently we have only a binding signature issued by the primary key on the signing subkey. I suggest we add a signature (the "back-signature") issued by the subkey on the primary key. This prevents the attack as the attacker cannot issue this signature, and thus cannot claim ownership of an existing signature. The back-signature design seemed to enjoy greater approval than the other, as well as having the nice detail that it could automatically protect signatures issued before the back-signature was added. The specifics (suggestions - I'm not wedded to this particular language): 1) Define a new type of signature subpacket that consists of a regular signature contained in a subpacket. Add to section 5.2.3.1 ("Signature Subpacket Specification"): 32 = embedded signature Add a new section to 5.2.3.x: 5.2.3.26. Embedded Signature (1 signature packet body) This subpacket contains a complete signature packet body as specified in section 5.2 above. It is useful when one signature needs to refer to, or be incorporated in, another signature. 2) Define a new signature class (Hal suggested 0x19), that is defined as a subkey signature on a primary key. Add to section 5.2.1 ("Signature Types"): 0x19: Primary key Binding Signature This signature is a statement by a signing subkey, indicating that it is owned by the primary key. This signature is calculated directly on the primary key itself, and not on any User ID or other packets. 3) At (sub)key generation time (or later, for existing keys) create this 0x19 signature and store it as a subpacket on the subkey binding signature. It does not matter whether it is a hashed subpacket or not. The hashing rules for 0x19 are the same as a 0x18 signature - we hash the primary key, then the subkey, and issue a signature from the subkey over this hash. In section 5.2.1, add to the description of the 0x18 signature: Signing subkeys have an embedded signature subpacket on this signature which contains a 0x19 signature by the signing subkey on the primary key. In section 5.2.4, change the sentence: A subkey signature (type 0x18) then hashes the subkey, using the same format as the main key (also using 0x99 as the first octet). to: A subkey binding signature (type 0x18), or primary key binding signature (0x19) then hashes the subkey, using the same format as the main key (also using 0x99 as the first octet). In section 10.1, change the sentence: Each Subkey packet must be followed by one Signature packet, which should be a subkey binding signature issued by the top level key. to: Each Subkey packet must be followed by one Signature packet, which should be a subkey binding signature issued by the top level key. For subkeys that can issue signatures, the subkey binding signature must contain an embedded signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top level key. That should do it. I've tried to keep the number of changes to a minimum, so this may seem somewhat terse. I do think it is sufficient to explain the proper way to write the additional signature. I have code for GnuPG that follows this basic design, and it works well. David From owner-ietf-openpgp@mail.imc.org Tue Jan 13 03:49:20 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01792 for ; Tue, 13 Jan 2004 03:49:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D8Onib093064; Tue, 13 Jan 2004 00:24:49 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D8Onkj093063; Tue, 13 Jan 2004 00:24:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from zbasel.fortytwo.ch (postfix@zbasel.fortytwo.ch [212.254.206.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D8Omib093037 for ; Tue, 13 Jan 2004 00:24:49 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: from onaras.ch (zux174-013.adsl.green.ch [80.254.174.13]) by zbasel.fortytwo.ch (Postfix) with ESMTP id 0CD12A1 for ; Tue, 13 Jan 2004 09:24:45 +0100 (CET) From: Adrian von Bidder To: ietf-openpgp@imc.org Subject: Re: The last word (hopefully) on back-signatures Date: Tue, 13 Jan 2004 09:24:43 +0100 User-Agent: KMail/1.5.4 References: <20040112195811.GB3329@jabberwocky.com> In-Reply-To: <20040112195811.GB3329@jabberwocky.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Lt6AAZ+FoIhfEfo"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401130924.43953@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_Lt6AAZ+FoIhfEfo Content-Type: text/plain; charset="iso-8859-1" Content-Description: signed data Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Monday 12 January 2004 20:58, David Shaw wrote: > I have > code for GnuPG that follows this basic design, and it works well. Will it be possible to convert existing subkeys? AFAICT, putting the 0x19=20 signature in an unhashed packet, this should be relatively painless. (Will= =20 keyservers properly deal with subkeys with the additional packet suddenly=20 appearing?) cheers =2D- vbi =2D-=20 featured product: vim - http://vim.org --Boundary-02=_Lt6AAZ+FoIhfEfo Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAkADq0tgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6rXsAn2kHqESpZaIaNcNeU9yT3PGp KcNUAKCBhYPK3kyUu92toM3OKMg8qRbHIQ== =95v1 -----END PGP SIGNATURE----- --Boundary-02=_Lt6AAZ+FoIhfEfo-- From owner-ietf-openpgp@mail.imc.org Tue Jan 13 13:44:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02570 for ; Tue, 13 Jan 2004 13:44:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DILvib056509; Tue, 13 Jan 2004 10:21:57 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DILvut056508; Tue, 13 Jan 2004 10:21:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DILuib056503 for ; Tue, 13 Jan 2004 10:21:57 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0DILCY28648 for ietf-openpgp@imc.org; Tue, 13 Jan 2004 13:21:12 -0500 Date: Tue, 13 Jan 2004 13:21:12 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: The last word (hopefully) on back-signatures Message-ID: <20040113182112.GA28614@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20040112195811.GB3329@jabberwocky.com> <200401130924.43953@fortytwo.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401130924.43953@fortytwo.ch> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (73% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jan 13, 2004 at 09:24:43AM +0100, Adrian von Bidder wrote: Content-Description: signed data > On Monday 12 January 2004 20:58, David Shaw wrote: > > I have > > code for GnuPG that follows this basic design, and it works well. > > Will it be possible to convert existing subkeys? AFAICT, putting the 0x19 > signature in an unhashed packet, this should be relatively painless. (Will > keyservers properly deal with subkeys with the additional packet suddenly > appearing?) Yes, it is possible to convert existing subkeys. One of the reasons I advocated using a subpacket was for this ability. Based on a number of tests, and a conversation with the author of SKS, I don't see any problem with updating existing subkeys on the PKSD or SKS servers. I haven't looked at the LDAP server yet. David From owner-ietf-openpgp@mail.imc.org Tue Jan 13 15:58:42 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12657 for ; Tue, 13 Jan 2004 15:58:41 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJYDib060800; Tue, 13 Jan 2004 11:34:13 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DJYDMY060799; Tue, 13 Jan 2004 11:34:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from slc-exch-1.forumsys.com (67.107.202.130.ptr.us.xo.net [67.107.202.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJYCib060791 for ; Tue, 13 Jan 2004 11:34:12 -0800 (PST) (envelope-from hmujtaba@forumsys.com) Received: from bstn-exch1.forumsys.com ([10.5.2.12]) by slc-exch-1.forumsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jan 2004 12:34:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: check for complementary keys Date: Tue, 13 Jan 2004 14:34:06 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D01570F@bstn-exch1.forumsys.com> Thread-Topic: check for complementary keys Thread-Index: AcPaC89j3wWv/86PQim0vYrypPFbsw== From: "Hasnain Mujtaba" To: X-OriginalArrivalTime: 13 Jan 2004 19:34:08.0873 (UTC) FILETIME=[36B3ED90:01C3DA0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0DJYDib060795 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi all, What is a good way to check whether an openpgp public and private key pair is complementary? One way I can think of is to do an encrypt/decrypt test with the keypair. But is there another way to determine this just by looking at the key material of the two keys? Thanks Hasnain. From owner-ietf-openpgp@mail.imc.org Tue Jan 13 16:22:47 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13904 for ; Tue, 13 Jan 2004 16:22:44 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DL0qib064300; Tue, 13 Jan 2004 13:00:52 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DL0qVd064299; Tue, 13 Jan 2004 13:00:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DL0oib064294 for ; Tue, 13 Jan 2004 13:00:51 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0DL07v30175 for ietf-openpgp@imc.org; Tue, 13 Jan 2004 16:00:07 -0500 Date: Tue, 13 Jan 2004 16:00:06 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: check for complementary keys Message-ID: <20040113210006.GB29673@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <4DCE15B9C4E66F4CA967EBF64C53D64D01570F@bstn-exch1.forumsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCE15B9C4E66F4CA967EBF64C53D64D01570F@bstn-exch1.forumsys.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (65% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jan 13, 2004 at 02:34:06PM -0500, Hasnain Mujtaba wrote: > > Hi all, > > What is a good way to check whether an openpgp public and private key > pair is complementary? One way I can think of is to do an > encrypt/decrypt test with the keypair. But is there another way to > determine this just by looking at the key material of the two keys? The OpenPGP packet format for private keys contains a complete copy of the corresponding public key. If you are not concerned about manipulation of the secret key packet, you could simply compare this embedded public key to the public key in question. David From owner-ietf-openpgp@mail.imc.org Tue Jan 13 18:27:03 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22342 for ; Tue, 13 Jan 2004 18:27:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DN2Pib069886; Tue, 13 Jan 2004 15:02:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DN2P2V069885; Tue, 13 Jan 2004 15:02:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from slc-exch-1.forumsys.com (67.107.202.130.ptr.us.xo.net [67.107.202.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DN2Nib069879 for ; Tue, 13 Jan 2004 15:02:24 -0800 (PST) (envelope-from hmujtaba@forumsys.com) Received: from bstn-exch1.forumsys.com ([10.5.2.12]) by slc-exch-1.forumsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jan 2004 16:02:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: check for complementary keys Date: Tue, 13 Jan 2004 18:02:19 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D19023F@bstn-exch1.forumsys.com> Thread-Topic: check for complementary keys Thread-Index: AcPaGlOlIeq4nmG7SKyN6dVI0HOUIQADl3Bw From: "Hasnain Mujtaba" To: X-OriginalArrivalTime: 13 Jan 2004 23:02:20.0973 (UTC) FILETIME=[4C931DD0:01C3DA29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0DN2Oib069881 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thanks. This will make it easier for me to read the public key from the private key and then do a match on the fingerprints of the two public keys. -----Original Message----- From: owner-ietf-openpgp@mail.imc.org [mailto:owner-ietf-openpgp@mail.imc.org] On Behalf Of David Shaw Sent: Tuesday, January 13, 2004 4:00 PM To: ietf-openpgp@imc.org Subject: Re: check for complementary keys On Tue, Jan 13, 2004 at 02:34:06PM -0500, Hasnain Mujtaba wrote: > > Hi all, > > What is a good way to check whether an openpgp public and private key > pair is complementary? One way I can think of is to do an > encrypt/decrypt test with the keypair. But is there another way to > determine this just by looking at the key material of the two keys? The OpenPGP packet format for private keys contains a complete copy of the corresponding public key. If you are not concerned about manipulation of the secret key packet, you could simply compare this embedded public key to the public key in question. David From owner-ietf-openpgp@mail.imc.org Thu Jan 22 18:05:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18569 for ; Thu, 22 Jan 2004 18:05:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MMi7ib087544; Thu, 22 Jan 2004 14:44:07 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MMi7xi087541; Thu, 22 Jan 2004 14:44:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (IDENT:root@226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MMi5ib087535 for ; Thu, 22 Jan 2004 14:44:06 -0800 (PST) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id i0MMhb614460 for ietf-openpgp@imc.org; Thu, 22 Jan 2004 14:43:37 -0800 Date: Thu, 22 Jan 2004 14:43:37 -0800 From: "Hal Finney" Message-Id: <200401222243.i0MMhb614460@finney.org> To: ietf-openpgp@imc.org Subject: Reason for V4 signature postscript Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I got some email from Peter Gutmann asking why we do the bizarre "postscript" in the hashing of V4 signatures. I didn't remember, but some digging into the code shed light on it, and gradually the reasons came back. Here is the mail I sent to him, which may be useful for future software archaeologists. The general concern we had was "aliasing", meaning that a specific set of bytes which were hashed could mean different things in different contexts. Specifically, we were worried that a V3 sig could have the same bytes hashed as a V4. The problem is that V3 sigs don't hash the sig version. They hash the body of the data, which could be anything, and then they hash the sig type and then 4 bytes of sig creation time. We wanted to make certain that you couldn't conjure up a document and get someone to put a V3 sig on it, and then turn that into a V4 sig on something else. So we wanted to make sure the last 5 hashed bytes for a V4 sig could never look like the last 5 hashed bytes for a V3 sig. The oldest version of the code I could find reads like this: /* Add hash "postscript", ensure hashed data not alias anything */ postscript[0] = PGPVERSION_4; /* Hash-convention version */ postscript[1] = 0xff; /* 5th from end, != any sig type value */ postscript[2] = (PGPByte)(l >> 24); postscript[3] = (PGPByte)(l >> 16); postscript[4] = (PGPByte)(l >> 8); postscript[5] = (PGPByte)(l >> 0); PGPContinueHash (temp_hc, postscript, sizeof(postscript)); The 4 is the hash-convention version, which I guess we meant to distinguish from the signature version. The FF is there as that is never a value found in the 5th from the end (or 4th from the end if you count differently) of the data hashed for a V3 sig. This assures that no V4 and V3 sigs will ever have the same bytes hashed. I remember now why the length was there. It allows for unambiguous parsing of the fields of the signature packet, counting from the far end. Without that, there may be ambiguity about how to parse it out, because there is no way, starting from the front, to know where the signed-document's data ends and the data from the signature begins. The signed-document's data is hashed with no headers, just the content of the document, so you don't know where it ends. As long as the hashed data can be unambiguously parsed from one end or the other, there is no danger of border-shifting, where data that is supposed to be part of one field can be interpreted as being part of another. Without this length field, that is a problem. So that explains the length, and the FF. The 4 still seems a little redundant, but by the end of one of these exercises, you get sort of paranoid about both making sure no ambiguities are possible, and also leaving yourself an escape so that the next version of the software won't suffer from this. Since we were relying on parsing from the end to prevent aliasing, it felt a little safer to put a version field right near that end. That way if we ever went to a V5 signature we could do so without worry that it could be aliased with a V4 sig. Hal Finney From owner-ietf-openpgp@mail.imc.org Sat Jan 24 18:20:08 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29028 for ; Sat, 24 Jan 2004 18:20:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ON0vib070346; Sat, 24 Jan 2004 15:00:57 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0ON0v51070345; Sat, 24 Jan 2004 15:00:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from [63.202.92.156] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ON0tic070335; Sat, 24 Jan 2004 15:00:55 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sat, 24 Jan 2004 15:00:56 -0800 To: (various IETF lists) From: Paul Hoffman / IMC Subject: New mail-ng mailing list open for sign-ups Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-openpgp@mail.imc.org Wed Jan 28 17:55:36 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05066 for ; Wed, 28 Jan 2004 17:55:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SMVCBe066342; Wed, 28 Jan 2004 14:31:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SMVCMR066341; Wed, 28 Jan 2004 14:31:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SMVArC066330 for ; Wed, 28 Jan 2004 14:31:11 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id i0SMUwc23433 for ; Wed, 28 Jan 2004 17:31:03 -0500 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0SMT9w19348 for ietf-openpgp@imc.org; Wed, 28 Jan 2004 17:29:09 -0500 Date: Wed, 28 Jan 2004 17:29:09 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Minor MDC inconsistency in bis-09 Message-ID: <20040128222909.GA19258@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (47% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In bis-09, section 5.13 says in regards to what gets hashed into the MDC: "The input to the hash function includes the prefix data described above". The next section, 5.14, says in regards to the body of the MDC packet: "...NOT including prefix data...". (my emphasis) Given the evidence of working code, I suspect section 5.14 is incorrect. David From owner-ietf-openpgp@mail.imc.org Thu Jan 29 04:49:11 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10659 for ; Thu, 29 Jan 2004 04:49:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0T9K35m073435; Thu, 29 Jan 2004 01:20:03 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0T9K3lj073434; Thu, 29 Jan 2004 01:20:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.cubis.de (send.cubis.de [195.226.172.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0T9K1bO073364 for ; Thu, 29 Jan 2004 01:20:01 -0800 (PST) (envelope-from Thorsten.Weins@secunet.com) Received: from mailscan-1.tuev-mitte.de (mailscan-1.cubis.de [10.0.142.44]) by mailgate.cubis.de (Switch-2.2.9/Switch-2.2.4) with SMTP id W0T90JYK00001050 for ; Thu, 29 Jan 2004 10:19:34 +0100 Received: From mailscan-2.tuev-mitte.de ([10.0.142.43]) by mailscan-1.tuev-mitte.de (WebShield SMTP v4.5 MR1a P0803.345); id 1075367970922; Thu, 29 Jan 2004 10:19:30 +0100 Received: From snsrv003.secumail.de ([10.36.12.43]) by mailscan-2.tuev-mitte.de (WebShield SMTP v4.5 MR1a); id 1075367963571; Thu, 29 Jan 2004 10:19:23 +0100 content-class: urn:content-classes:message Subject: Trust Packets MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Jan 2004 10:19:30 +0100 Message-ID: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: Trust Packets Thread-Index: AcPmSSiJ7HQZlv23T6Cwd78kRsSxXw== From: "Weins, Thorsten" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0T9K2bO073420 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hello, the implementation of Trust Packets is implementation specific. Does anybody know, how these packets are implemented in PGP 7.x or higher? BTW, is there a reason why they are implementation specific? If somebody uses different implementations (e.g. on different platforms) of PGP, he will not be able to use his "one and only" keyring. Thanks in advance, Thorsten From owner-ietf-openpgp@mail.imc.org Thu Jan 29 08:30:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16358 for ; Thu, 29 Jan 2004 08:30:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TD95Gw009108; Thu, 29 Jan 2004 05:09:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TD94r4009107; Thu, 29 Jan 2004 05:09:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TD92eo009086 for ; Thu, 29 Jan 2004 05:09:03 -0800 (PST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 1AmBvh-0002t8-00 for ; Thu, 29 Jan 2004 14:09:57 +0100 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 1AmBue-0002IL-00; Thu, 29 Jan 2004 14:08:52 +0100 To: "Weins, Thorsten" Cc: Subject: Re: Trust Packets References: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Thu, 29 Jan 2004 14:08:52 +0100 In-Reply-To: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> (Thorsten Weins's message of "Thu, 29 Jan 2004 10:19:30 +0100") Message-ID: <87brom9a1n.fsf@alberti.g10code.de> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004 10:19:30 +0100, Weins, Thorsten said: > BTW, is there a reason why they are implementation specific? If somebody > uses > different implementations (e.g. on different platforms) of PGP, he will OpenPGP defines message and key transport formats but not how an application stores the key for its own purpose. The concept of a keyring is PGP specific, other implementations may use an SQL DB or use a mixed approach, where the trust information is kept separate from the keys. Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org From owner-ietf-openpgp@mail.imc.org Thu Jan 29 09:32:57 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19252 for ; Thu, 29 Jan 2004 09:32:57 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TECsVH014253; Thu, 29 Jan 2004 06:12:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TECswT014252; Thu, 29 Jan 2004 06:12:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0TECrd8014246 for ; Thu, 29 Jan 2004 06:12:53 -0800 (PST) (envelope-from iang@systemics.com) Received: (qmail 8828 invoked from network); 29 Jan 2004 14:12:53 -0000 Received: from unknown (HELO systemics.com) (24.244.145.15) by relay.pair.com with SMTP; 29 Jan 2004 14:12:53 -0000 X-pair-Authenticated: 24.244.145.15 Message-ID: <40191400.9080708@systemics.com> Date: Thu, 29 Jan 2004 09:09:04 -0500 From: Ian Grigg User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040113 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Weins, Thorsten" CC: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> In-Reply-To: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Weins, Thorsten wrote: > Hello, > > the implementation of Trust Packets is implementation specific. > Does anybody know, how these packets are implemented in PGP 7.x or > higher? > > BTW, is there a reason why they are implementation specific? If somebody > uses > different implementations (e.g. on different platforms) of PGP, he will > not be > able to use his "one and only" keyring. Some random comments. One of the most perceptive decisions that the early PGP designers made was to not define trust. This was a good decision because trust defies definition. Trust is too much wrapped up in context of the user and her companion users, and the programmer can't really narrow that down usefully ahead of time. Encouraging an implementation to more closely define trust, and standardising this across implementations, would break it. An example of this is the x.509 PKI in use in HTTPS - they define trust as being a CA-signed cert that includes, for example, some notion of what country you are in (? from?). In terms of keyrings - Werner mentioned the local issues with databases. Trust includes lots of information that will/should never be exported. By not standardising the format of the keyrings (and suggesting inter-program exports to be done by means of ascii-armoured keys) PGP votes to encourage experimenting with trust at the implementation level. This allows an implementation to add some special notes in there, or turn it into an addressbook, or build up signing networks. That's much more beneficial than some committee trying to define trust. iang From owner-ietf-openpgp@mail.imc.org Fri Jan 30 05:20:56 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06178 for ; Fri, 30 Jan 2004 05:20:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U9sneX055250; Fri, 30 Jan 2004 01:54:49 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0U9snC1055249; Fri, 30 Jan 2004 01:54:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U9sdCE055157 for ; Fri, 30 Jan 2004 01:54:42 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 65966340CB; Fri, 30 Jan 2004 22:53:43 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0U9sTs08395; Fri, 30 Jan 2004 22:54:29 +1300 Date: Fri, 30 Jan 2004 22:54:29 +1300 Message-Id: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Thorsten.Weins@secunet.com, wk@gnupg.org Subject: Re: Trust Packets Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: >The concept of a keyring is PGP specific, other implementations may use an >SQL DB or use a mixed approach, where the trust information is kept separate >from the keys. Just out of interest, is there anyone using an SQL DB to store PGP keys? I've thought about this a bit in the past (I use databases to store other types of keys) but because of the free-form association of different bits and pieces of keys with identifying information I can't think of any easy way to do it unless you use a multi-level lookup. That is, you can't do a: SELECT key FROM table WHERE email = foo because there could be an arbitrary number of email addresses attached to a key, and there could be an arbitrary number of keys associated with an email address. So you need something like: SELECT keyID FROM indexTable WHERE email = foo SELECT key FROM sigKeyTable WHERE keyID = foo which isn't very efficient (multiple tables, multi-level lookups, etc etc). Peter. From owner-ietf-openpgp@mail.imc.org Fri Jan 30 05:31:38 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06559 for ; Fri, 30 Jan 2004 05:31:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAA7bv061027; Fri, 30 Jan 2004 02:10:07 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UAA7LJ061025; Fri, 30 Jan 2004 02:10:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAA4Ck060982 for ; Fri, 30 Jan 2004 02:10:05 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id CBA8634007; Fri, 30 Jan 2004 23:09:08 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0UA9xG08487; Fri, 30 Jan 2004 23:09:59 +1300 Date: Fri, 30 Jan 2004 23:09:59 +1300 Message-Id: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: iang@systemics.com, Thorsten.Weins@secunet.com Subject: Re: Trust Packets Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian Grigg writes: >An example of this is the x.509 PKI in use in HTTPS - they define trust as >being a CA-signed cert that includes, for example, some notion of what >country you are in (? from?). Since we're getting a bit philosphical here, I don't know if what X.509 enforces is really "trust". PGP's web of trust is a reasonably accurate use of the term "trust", but with X.509 you need to read "trust" as "dependency" (in the sense of "is forced to depend upon"). For example if I make a CC purchase from foo.com, I don't trust them because of their Verisign cert, but I have no choice but to depend upon them because if I don't I can't make my purchase. So PGP's mechanisms propagate trust, X.509's propagate dependency. Peter. From owner-ietf-openpgp@mail.imc.org Fri Jan 30 05:50:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07282 for ; Fri, 30 Jan 2004 05:50:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAUZoD065449; Fri, 30 Jan 2004 02:30:35 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UAUZJS065448; Fri, 30 Jan 2004 02:30:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAUXmX065429 for ; Fri, 30 Jan 2004 02:30:34 -0800 (PST) (envelope-from news@branwen.iks-jena.de) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UAUSUf027360 for ; Fri, 30 Jan 2004 11:30:28 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.11/8.12.1/Submit) id i0UAUSKv027359 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 11:30:28 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Trust Packets Date: Fri, 30 Jan 2004 10:30:28 +0000 (UTC) Organization: IKS GmbH Jena Lines: 40 Message-ID: References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1075458628 22964 217.17.192.37 (30 Jan 2004 10:30:28 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Fri, 30 Jan 2004 10:30:28 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Peter Gutmann wrote: > Just out of interest, is there anyone using an SQL DB to store PGP keys? Yes, here. Keyserver on DB. > I've thought about this a bit in the past (I use databases to store other > types of keys) but because of the free-form association of different bits > and pieces of keys with identifying information I can't think of any easy > way to do it unless you use a multi-level lookup. I distribute the keys over a bunch of tables. pgp=# \dt List of relations Schema | Name | Type | Owner --------+-----------------------+-------+------- public | asymmetric_algorithm | table | lutz public | compression_algorithm | table | lutz public | hash_algorithm | table | lutz public | pubkey | table | lutz public | revocation | table | lutz public | revocation_class | table | lutz public | sig | table | lutz public | sigtype | table | lutz public | symmetric_algorithm | table | lutz public | userid | table | lutz (10 rows) > SELECT keyID FROM indexTable WHERE email = foo > SELECT key FROM sigKeyTable WHERE keyID = foo Yes. > which isn't very efficient (multiple tables, multi-level lookups, etc etc). This is very efficient compared to the alternatives: - You search the only the part of the data associated with the query. - Intertable links are indexed using hashs or btrees. - Records are dense. From owner-ietf-openpgp@mail.imc.org Fri Jan 30 06:42:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10257 for ; Fri, 30 Jan 2004 06:42:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UBE1VX070462; Fri, 30 Jan 2004 03:14:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UBE13d070461; Fri, 30 Jan 2004 03:14:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UBDxQn070450 for ; Fri, 30 Jan 2004 03:13:59 -0800 (PST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 1AmWbl-0001Ai-00 for ; Fri, 30 Jan 2004 12:14:45 +0100 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 1AmWZV-0003i8-00; Fri, 30 Jan 2004 12:12:25 +0100 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: Thorsten.Weins@secunet.com, ietf-openpgp@imc.org Subject: Re: Trust Packets References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 30 Jan 2004 12:12:25 +0100 In-Reply-To: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> (Peter Gutmann's message of "Fri, 30 Jan 2004 22:54:29 +1300") Message-ID: <87u12d667a.fsf@alberti.g10code.de> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 30 Jan 2004 22:54:29 +1300, Peter Gutmann said: > Just out of interest, is there anyone using an SQL DB to store PGP keys? I've I don't know. From the discussions on the GnuPG MLs I surmised that a some folks are trying to do it. > which isn't very efficient (multiple tables, multi-level lookups, etc etc). But these are the real cool things you can do with SQL. Werner From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:11:06 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28743 for ; Fri, 30 Jan 2004 12:11:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGjQAU087782; Fri, 30 Jan 2004 08:45:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGjQtk087781; Fri, 30 Jan 2004 08:45:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGjJLs087771 for ; Fri, 30 Jan 2004 08:45:20 -0800 (PST) (envelope-from ietf-ietf-openpgp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AmXn3-0005d5-00 for ; Fri, 30 Jan 2004 13:30:29 +0100 Received: from h213n3c1o299.bredband.skanova.com ([217.208.174.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri Jan 30 12:30:29 2004 Received: from jas by h213n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri Jan 30 12:30:29 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-openpgp@imc.org From: Simon Josefsson Subject: Re: Trust Packets Date: Fri, 30 Jan 2004 13:22:57 +0100 Lines: 60 Message-ID: References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org Gmane-NNTP-Posting-Host: h213n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:jVgWlMtaph5sjz8hOE7PQMAlzFU= Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Werner Koch writes: > >>The concept of a keyring is PGP specific, other implementations may use an >>SQL DB or use a mixed approach, where the trust information is kept separate >>from the keys. > > Just out of interest, is there anyone using an SQL DB to store PGP keys? I am, in a DNS-based OpenPGP key server. It separates key fingerprints with uid like this: create table cks_key_id_table ( key_id char(8) NOT NULL, fkey_id char(16) NOT NULL, fp varchar(40) NOT NULL, PRIMARY KEY(fp) ); create table cks_uid_table ( fkey_id varchar(16) NOT NULL, p_uid int2 NOT NULL, fp varchar(40) NOT NULL, uid varchar(6000) NOT NULL ); > I've thought about this a bit in the past (I use databases to store > other types of keys) but because of the free-form association of > different bits and pieces of keys with identifying information I > can't think of any easy way to do it unless you use a multi-level > lookup. That is, you can't do a: > > SELECT key FROM table WHERE email = foo > > because there could be an arbitrary number of email addresses attached to a > key, and there could be an arbitrary number of keys associated with an email > address. So you need something like: > > SELECT keyID FROM indexTable WHERE email = foo > SELECT key FROM sigKeyTable WHERE keyID = foo > > which isn't very efficient (multiple tables, multi-level lookups, etc etc). Have you tried this and found that performance is the most performance critical area? I am often surprised how efficient modern databases are. When I measured, the network related delays was about five times longer than the database query delay (I'm using multiple tables, two SQL queries per DNS query), even on local network. I admit most of the delays was in the Perl DNS server implementation, or in my use of it, which appear to be rather inefficient, but anyway it suggested to me that I shouldn't worry much about database performance. (The database contained the equivalent of ~2GB PGP keyrings worth of data, although the machine had enough memory to store the entire database in RAM.) Regards, Simon From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:17:37 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29432 for ; Fri, 30 Jan 2004 12:17:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGtlCB001330; Fri, 30 Jan 2004 08:55:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGtl3d001328; Fri, 30 Jan 2004 08:55:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGtjk1001310 for ; Fri, 30 Jan 2004 08:55:46 -0800 (PST) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 0FC0422E2; Fri, 30 Jan 2004 11:02:26 -0500 (EST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> From: Greg Troxel Date: 30 Jan 2004 11:02:26 -0500 In-Reply-To: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Since we're getting a bit philosphical here, I don't know if what X.509 > enforces is really "trust". PGP's web of trust is a reasonably accurate use > of the term "trust", but with X.509 you need to read "trust" as "dependency" > (in the sense of "is forced to depend upon"). For example if I make a CC > purchase from foo.com, I don't trust them because of their Verisign cert, but > I have no choice but to depend upon them because if I don't I can't make my > purchase. So PGP's mechanisms propagate trust, X.509's propagate dependency. You of course do have a choice - whether or not to make the purchase. I have declined to buy things because I don't trust people, and I'd hope everyone else is in the same boat. With pgp, you choose whether to believe a message or use a key for encryption. If you "have to" send the message, you "don't have a choice". The ultimate trust model is really no different; it's the kinds of decisions that you can make easily that get encoded into software that differ (and this is important). With foo.com, you choose 1) whether foo.com is actually reputable and you are willing to deal with them (same in PGP and x509 case) and 2) whether you believe that the key you have for foo.com really belongs to foo.com (by choosing to believe that verisign is adequately careful in issuing certs and protecting the CA key), or via some essentially equivalent operation wtih a PGP signature. The real difference is that x509 has a bunch of rules about which signatures won't be believed (due to name subordination) and the cultural (not spec) notion that 'root CAs' are inherently trustworthy, together with the notion and practice that a specific list is included by default. I agree that in practice this cultural difference is large. I think it would be a mistake for the openpgp spec to move in the direction of suggesting that some keys be preconfigured as trusted (where trusted specifically means that name/key bindings signed by those keys are believed). But I don't think anyone is suggesting that. -- Greg Troxel From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:19:10 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29644 for ; Fri, 30 Jan 2004 12:19:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH1kkB001858; Fri, 30 Jan 2004 09:01:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UH1kLZ001857; Fri, 30 Jan 2004 09:01:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH1hRa001842 for ; Fri, 30 Jan 2004 09:01:43 -0800 (PST) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id DD1C345028; Fri, 30 Jan 2004 09:01:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id CC3B54802B; Fri, 30 Jan 2004 09:01:25 -0800 (PST) Date: Fri, 30 Jan 2004 09:01:25 -0800 (PST) From: Len Sassaman X-X-Sender: rabbi@thetis.deor.org To: Ian Grigg Cc: "Weins, Thorsten" , ietf-openpgp@imc.org Subject: Re: Trust Packets In-Reply-To: <40191400.9080708@systemics.com> Message-ID: References: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> <40191400.9080708@systemics.com> X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004, Ian Grigg wrote: > Some random comments. > > One of the most perceptive decisions that the early PGP > designers made was to not define trust. This was a good > decision because trust defies definition. Trust is too > much wrapped up in context of the user and her companion > users, and the programmer can't really narrow that down > usefully ahead of time. I wouldn't say that they didn't define trust. PGP has internal trust calculation algorithms, which happen not to be documented within the IETF. I have always thought this unfortunate. I agree that trust calculation should be orthogonal to the OpenPGP message format specification, but I do wish that it were documented. From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:27:26 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01067 for ; Fri, 30 Jan 2004 12:27:25 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH50M9002220; Fri, 30 Jan 2004 09:05:00 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UH5031002219; Fri, 30 Jan 2004 09:05:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH4w5q002206 for ; Fri, 30 Jan 2004 09:04:59 -0800 (PST) (envelope-from news@branwen.iks-jena.de) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UCVGos031226 for ; Fri, 30 Jan 2004 13:31:16 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.11/8.12.1/Submit) id i0UCVGdD031225 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 13:31:16 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Trust Packets Date: Fri, 30 Jan 2004 12:31:16 +0000 (UTC) Organization: IKS GmbH Jena Lines: 5 Message-ID: References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> <87u12d667a.fsf@alberti.g10code.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1075465876 31190 217.17.192.37 (30 Jan 2004 12:31:16 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Fri, 30 Jan 2004 12:31:16 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Werner Koch wrote: > But these are the real cool things you can do with SQL. Example: Give me all keys whose trust level might be changed by updateing this keyid. So --check-trust does scale. From owner-ietf-openpgp@mail.imc.org Fri Jan 30 12:40:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02628 for ; Fri, 30 Jan 2004 12:40:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHOUwo004082; Fri, 30 Jan 2004 09:24:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHOUvl004081; Fri, 30 Jan 2004 09:24:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHOSNZ004043 for ; Fri, 30 Jan 2004 09:24:29 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 5DC42340D7; Sat, 31 Jan 2004 01:20:06 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0UCKvg09248; Sat, 31 Jan 2004 01:20:57 +1300 Date: Sat, 31 Jan 2004 01:20:57 +1300 Message-Id: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, lutz@iks-jena.de Subject: Re: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz Donnerhacke writes: >I distribute the keys over a bunch of tables. Hmm, I was afraid you were going to say that. OTOH once it's all set up you can do some powerful stuff using the SQL query capabilities, e.g. list all keys that are about to expire, or all keys signed by X, or whatever. (In case anyone's interested, I did a paper on using relational databases as key stores for ACSAC 2000, you can get it from http://www.acsac.org/2000/thu.html. A longer version is available from my home page, the ACSAC page limit was 10 pages so I had to cut some bits out). >This is very efficient compared to the alternatives: > - You search the only the part of the data associated with the query. > - Intertable links are indexed using hashs or btrees. > - Records are dense. You forgot: - Maintaining 10 tables at once is entertaining for the software developer. Peter :-). From owner-ietf-openpgp@mail.imc.org Fri Jan 30 13:22:09 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06282 for ; Fri, 30 Jan 2004 13:22:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvHFH006966; Fri, 30 Jan 2004 09:57:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHvHce006965; Fri, 30 Jan 2004 09:57:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from excalibur.iks-jena.de (root@excalibur.iks-jena.de [217.17.192.67]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvDI7006955 for ; Fri, 30 Jan 2004 09:57:15 -0800 (PST) (envelope-from lutz@iks-jena.de) Received: from taranis.iks-jena.de (taranis.iks-jena.de [217.17.192.37]) by excalibur.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UCSdD1002139 for ; Fri, 30 Jan 2004 13:28:39 +0100 Received: (from lutz@localhost) by taranis.iks-jena.de (8.12.11/8.12.1/Submit) id i0UCSd7a001167 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 13:28:39 +0100 Date: Fri, 30 Jan 2004 13:28:38 +0100 From: Lutz Donnerhacke To: ietf-openpgp@imc.org Subject: Re: Trust Packets Message-ID: <20040130122838.GF768@taranis.iks-jena.de> References: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i X-message-flag: Please send plain text messages only. Thank you. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2004 at 01:20:57AM +1300, Peter Gutmann wrote: > Lutz Donnerhacke writes: > >I distribute the keys over a bunch of tables. > > Hmm, I was afraid you were going to say that. OTOH once it's all set up you > can do some powerful stuff using the SQL query capabilities, e.g. list all > keys that are about to expire, or all keys signed by X, or whatever. Exactly. I added some stuff to automatically remove signatures from revoked keys, etc. pp. Furthermore it's easy to implement a keyserver, because you notice how many new keys/signatures/userid etc. pp. occured. So merging keys is very simple. > (In case anyone's interested, I did a paper on using relational databases as Thanx. I should publish the sql based keyserver, too. > You forgot: > - Maintaining 10 tables at once is entertaining for the software developer. Yep. Obtaining standard query strings from you local DB developer (it's fun for him) and using them as black box is plain recovery. ;-) From owner-ietf-openpgp@mail.imc.org Fri Jan 30 13:55:21 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08421 for ; Fri, 30 Jan 2004 13:55:20 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UIadZK011319; Fri, 30 Jan 2004 10:36:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UIadgg011317; Fri, 30 Jan 2004 10:36:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from slc-exch-1.forumsys.com (67.107.202.130.ptr.us.xo.net [67.107.202.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UIaara011302 for ; Fri, 30 Jan 2004 10:36:37 -0800 (PST) (envelope-from lutz@iks-jena.de) Received: from mail pickup service by slc-exch-1.forumsys.com with Microsoft SMTPSVC; Fri, 30 Jan 2004 11:22:01 -0700 Received: from above.proper.com ([208.184.76.39]) by slc-exch-1.forumsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jan 2004 11:16:27 -0700 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvHFH006966; Fri, 30 Jan 2004 09:57:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHvHce006965; Fri, 30 Jan 2004 09:57:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from excalibur.iks-jena.de (root@excalibur.iks-jena.de [217.17.192.67]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvDI7006955 for ; Fri, 30 Jan 2004 09:57:15 -0800 (PST) (envelope-from lutz@iks-jena.de) Received: from taranis.iks-jena.de (taranis.iks-jena.de [217.17.192.37]) by excalibur.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UCSdD1002139 for ; Fri, 30 Jan 2004 13:28:39 +0100 Received: (from lutz@localhost) by taranis.iks-jena.de (8.12.11/8.12.1/Submit) id i0UCSd7a001167 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 13:28:39 +0100 Date: Fri, 30 Jan 2004 13:28:38 +0100 From: Lutz Donnerhacke To: ietf-openpgp@imc.org Subject: Re: Trust Packets Message-ID: <20040130122838.GF768@taranis.iks-jena.de> References: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i X-message-flag: Please send plain text messages only. Thank you. List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Jan 2004 18:16:27.0802 (UTC) FILETIME=[2D82AFA0:01C3E75D] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2004 at 01:20:57AM +1300, Peter Gutmann wrote: > Lutz Donnerhacke writes: > >I distribute the keys over a bunch of tables. > > Hmm, I was afraid you were going to say that. OTOH once it's all set up you > can do some powerful stuff using the SQL query capabilities, e.g. list all > keys that are about to expire, or all keys signed by X, or whatever. Exactly. I added some stuff to automatically remove signatures from revoked keys, etc. pp. Furthermore it's easy to implement a keyserver, because you notice how many new keys/signatures/userid etc. pp. occured. So merging keys is very simple. > (In case anyone's interested, I did a paper on using relational databases as Thanx. I should publish the sql based keyserver, too. > You forgot: > - Maintaining 10 tables at once is entertaining for the software developer. Yep. Obtaining standard query strings from you local DB developer (it's fun for him) and using them as black box is plain recovery. ;-) From owner-ietf-openpgp@mail.imc.org Fri Jan 30 14:32:07 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11158 for ; Fri, 30 Jan 2004 14:32:06 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UJ1m2t013255; Fri, 30 Jan 2004 11:01:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UJ1m0s013254; Fri, 30 Jan 2004 11:01:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UJ1k5g013244 for ; Fri, 30 Jan 2004 11:01:47 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i0UJ1hJE013632; Fri, 30 Jan 2004 14:01:43 -0500 To: ietf-openpgp@imc.org Subject: Meeting in Seoul -- call for Agenda Items. From: Derek Atkins Date: Fri, 30 Jan 2004 14:01:43 -0500 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I'd like to schedule a meeting in Seoul. Do people have specific items they would like to talk about? I know Jon can't make it but I'd like someone to present a 2440bis status (Jon, can you find someone to provide the status). I'll work on the list of open issues and mail that out early next week. We also need to update the milestones for the WG. I'll work with the document editors to flush out that proposal and present it here ASAP. Are there other orders of business for Seoul? Any other presentations to be made? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Fri Jan 30 22:05:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20624 for ; Fri, 30 Jan 2004 22:05:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2b58Y042047; Fri, 30 Jan 2004 18:37:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V2b5mC042046; Fri, 30 Jan 2004 18:37:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail1.wiktel.com (mail1.wiktel.com [204.221.145.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2b1OZ042038 for ; Fri, 30 Jan 2004 18:37:04 -0800 (PST) (envelope-from rlaager@wiktel.com) Received: from NB1131X (unverified [209.32.118.218]) by wiktel.com (Rockliffe SMTPRA 5.3.4) with ESMTP id for ; Fri, 30 Jan 2004 20:37:45 -0600 From: "Richard Laager" To: Subject: RE: Trust Packets Date: Fri, 30 Jan 2004 20:36:50 -0600 Organization: Wikstrom Telecom Internet Message-ID: <002a01c3e7a3$15525a70$da7620d1@umcrookston.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Gutmann wrote: ... > For example if > I make a CC > purchase from foo.com, I don't trust them because of their > Verisign cert, but > I have no choice but to depend upon them because if I don't I > can't make my > purchase. So PGP's mechanisms propagate trust, X.509's > propagate dependency. No, X.509 propagates trust. The root certificates in your browser's certificate store are there because you trust them. I realize that the browser vendor pre-loads a bunch of certificates. This is to make things easier for the end user. If you don't trust VeriSign to issue signatures, remove them from the root certificate store. Now, once that's done, does the certificate for foo.com appear valid? No. You've revoked your trust of VeriSign, so it shouldn't. Using the site is NOT dependent on VeriSign. You can make the SSL connection without trusting the certificate. Then, it becomes the same (security-wise) as HTTP; you can't be sure you're avoiding a MITM attack. This would be exactly the same if a Linux vendor preloaded /etc/skel/.gnupg/ with default keys marked as trusted. There is no dependency introduced, just pre-loaded trust. If you didn't trust the pre-loaded keys, you could just remove them. X.509 has its flaws, but it's trust model is in fact based on trust. It's just different from PGP's Web-of-Trust. If you disagree with it because it forces you into rigid hierarchies (typically promoted by commercial interests), fine. But, the underlying technology isn't creating any sort of trust-like dependency. A good definition of "trust" in a computer security context is, "An entity which can break your security policy." (I don't know if this is attributable to the DoD or whom.) In other words, if you have VeriSign in your root certificates, they can break your security policy by issuing a bad certificate. This is not dependence. Richard Laager -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBQBsUmm31OrleHxvOEQKAmwCgz2KoZ1S8yqXWk1uSDLvYH1aVBCsAnR0i L9l/Gcrcx8eLXuDH56bAG3P+ =O1aK -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 30 22:05:59 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20623 for ; Fri, 30 Jan 2004 22:05:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2bBtf042058; Fri, 30 Jan 2004 18:37:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V2bBMn042057; Fri, 30 Jan 2004 18:37:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2b8qf042039 for ; Fri, 30 Jan 2004 18:37:10 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A45123401D; Sat, 31 Jan 2004 15:36:11 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0V2b5u13998; Sat, 31 Jan 2004 15:37:05 +1300 Date: Sat, 31 Jan 2004 15:37:05 +1300 Message-Id: <200401310237.i0V2b5u13998@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, lutz@iks-jena.de Subject: Re: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz Donnerhacke writes: >Furthermore it's easy to implement a keyserver, because you notice how many >new keys/signatures/userid etc. pp. occured. So merging keys is very simple. Yup, and real-time status queries are also incredibly trivial, the user submits a request (e.g. via HTTP, http://......?keyID=abcd), you translate it into "SELECT COUNT(*) FROM validKeys WHERE keyID=abcd" and return the output to the user (there's an RFC draft on this floating around somehere on ietf.org). >>You forgot: >> - Maintaining 10 tables at once is entertaining for the software developer. > >Yep. Obtaining standard query strings from you local DB developer (it's fun >for him) and using them as black box is plain recovery. ;-) While we're rhapsodising about the joys of SQL keyservers, it also makes debugging incredibly easy, you just drop your favourite SQL browse tool onto the database and you can check everything that happens, arranged/filtered by whatever criteria you want. Peter. From owner-ietf-openpgp@mail.imc.org Fri Jan 30 23:02:29 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22367 for ; Fri, 30 Jan 2004 23:02:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V3ghlK046553; Fri, 30 Jan 2004 19:42:43 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V3ghX5046552; Fri, 30 Jan 2004 19:42:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V3gg6S046542 for ; Fri, 30 Jan 2004 19:42:42 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 04E493401D; Sat, 31 Jan 2004 16:41:46 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0V3gdi14441; Sat, 31 Jan 2004 16:42:39 +1300 Date: Sat, 31 Jan 2004 16:42:39 +1300 Message-Id: <200401310342.i0V3gdi14441@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, rlaager@wiktel.com Subject: RE: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Richard Laager" writes: >No, X.509 propagates trust. The root certificates in your browser's >certificate store are there because you trust them. Nope, they're there because I don't have a choice. I *trust* that if I report an unauthorised credit card charge to my CC vendor within 30-60 days, it won't come out of my pocket. I am forced to *depend* on hardcoded CA certs in my browser because without that I can't exercise my trust in Reg.E/Reg.Z. The only thing I trust about a commercial CA-issued cert is that it proves that at some point money changed hands, to the CA's benefit (admittedly this provides at least a small amount of trust by proving that either the web site takes itself seriously enough that it's willing to burn money to make this point or that the script kiddie who r00ted it was skillful enough to get away with it unnoticed). >If you don't trust VeriSign to issue signatures, remove them from the root >certificate store. I could disable the 100+ certs in my browser (a mere 700 mouse clicks, only a day or so's work) but then I'd constantly have warning dialogs popping up and annoying me while I'm exercising my trust in Reg.E/Reg.Z. In addition disabling only the Verisign roots won't prevent Verisign certs from being accepted, because of the implicit universal cross-certification in browsers any other CA could issue Verisign certs and they'd be treated no diferently from the real thing. Peter. From owner-ietf-openpgp@mail.imc.org Sat Jan 31 00:04:30 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24417 for ; Sat, 31 Jan 2004 00:04:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V4mbIh050289; Fri, 30 Jan 2004 20:48:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V4mbb2050288; Fri, 30 Jan 2004 20:48:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail1.wiktel.com (mail1.wiktel.com [204.221.145.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V4ma2r050280 for ; Fri, 30 Jan 2004 20:48:36 -0800 (PST) (envelope-from rlaager@wiktel.com) Received: from NB1131X (unverified [209.32.118.218]) by wiktel.com (Rockliffe SMTPRA 5.3.4) with ESMTP id for ; Fri, 30 Jan 2004 22:49:24 -0600 From: "Richard Laager" To: Subject: RE: Trust Packets Date: Fri, 30 Jan 2004 22:48:29 -0600 Organization: Wikstrom Telecom Internet Message-ID: <000f01c3e7b5$78fa6b00$da7620d1@umcrookston.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200401310342.i0V3gdi14441@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Gutmann wrote: > I could disable the 100+ certs in my browser (a mere 700 > mouse clicks, only a > day or so's work) but then I'd constantly have warning > dialogs popping up and > annoying me while I'm exercising my trust in Reg.E/Reg.Z. Hmm. I just tested this with IE. Highlight the first certificate, hold shift, click the last, hit Delete. Any browser which requires you to individually delete certificates has a broken UI that's beyond the scope of this discussion. So much for your 700 mouse clicks. As for the warning dialogs: These can be disabled in IE. Again, if the browser doesn't let you disable them, that's a UI issue. Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are sites as this is the most logical example given this discussion) is NOT the same as trusting the certificate alleging to be from Reg.E/Reg.Z. Their certificates could easily have been swapped out by a MITM attack. Now, if you have a trusted out-of-band channel where you obtained the certificate or its fingerprint, then add the certificate to your browser's trusted store. Otherwise, exercising trust in the certificate is pointless because you're not sure of its origin. As I said before, in this scenario, HTTPS is effectively reduced in security to HTTP. The trust in a normal HTTPS situation flows like this: User -> Computer Vendor -> OS Vendor -> Bundled Browser (optionally - -> signed browser upgrades from [Alternate] Browser Vendor) -> Root CAs (optionally -> intermediate CAs) -> Site Operator & Site Certificate -> HTTPS Session If you add an alternate certificate that you've verified some other way: User -> Site Operator & Site Certificate -> HTTPS Session > In > addition disabling only the Verisign roots won't prevent Verisign > certs from being > accepted, because of the implicit universal > cross-certification in browsers > any other CA could issue Verisign certs and they'd be treated > no diferently > from the real thing. The only way this would work is if one of the VeriSign certificates in the certification path was signed by another CA. Furthermore, it would only work if the server sending its SSL certificate included the VeriSign intermediate certificate signed by the other root authority. Who would explicitly configure a server this way when the VeriSign certificates are in basically every product that uses SSL? And, in this example then, the certificate ceases to be a VeriSign certificate and is by definition a certificate which inherits its trust through the other root. So, if you don't trust that root, delete it. In any case, none of this is "implicit" or "universal". Stop making excuses. Commercial certification authorities and the X.509 hierarchical structure make it easy for the non-technical masses to use HTTPS. Not everyone has the desire to participate in a fragile web of trust just to order the latest gadget off a website. Due to capitalism, the CAs make money providing their service. While I share your distrust of VeriSign in some ways, especially in the CA business after the Microsoft fiasco, this is not a protocol or implementation detail. The system is designed and can be used to prevent This thread is off-topic so I will refrain from any further response. Richard Laager -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBQBszmW31OrleHxvOEQJLegCgnHZ9kcAoECb7cW+bLujLm7kjSckAn1zl u39jLDIps3NXQj9lfUFknPzU =f3+0 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Jan 31 00:34:01 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25298 for ; Sat, 31 Jan 2004 00:34:00 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V5GlGn052188; Fri, 30 Jan 2004 21:16:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V5Glnv052187; Fri, 30 Jan 2004 21:16:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V5Gh95052175 for ; Fri, 30 Jan 2004 21:16:45 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 4949A340CE; Sat, 31 Jan 2004 18:15:47 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0V5Gfe14983; Sat, 31 Jan 2004 18:16:41 +1300 Date: Sat, 31 Jan 2004 18:16:41 +1300 Message-Id: <200401310516.i0V5Gfe14983@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, rlaager@wiktel.com Subject: RE: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Richard Laager" writes: >Hmm. I just tested this with IE. Highlight the first certificate, hold shift, >click the last, hit Delete. Any browser which requires you to individually >delete certificates has a broken UI that's beyond the scope of this >discussion. So much for your 700 mouse clicks. Oh, they must have fixed it in recent versions. >Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are sites as >this is the most logical example given this discussion) is NOT the same as >trusting the certificate alleging to be from Reg.E/Reg.Z. Regulation E and Regulation Z are US consumer-protection legislation covering use of credit and ATM cards. I trust Reg.E/Reg.Z to keep me from harm. I don't trust a CA-issued to cert to do this (although it can't hurt, for reasons given in my previous post). >The only way this would work is if one of the VeriSign certificates in the >certification path was signed by another CA. Furthermore, it would only work >if the server sending its SSL certificate included the VeriSign intermediate >certificate signed by the other root authority. Yup. >Who would explicitly configure a server this way when the VeriSign >certificates are in basically every product that uses SSL? Who would explicitly configure a server to pretend to be Paypal when it isn't? The answer is the same in both cases. >In any case, none of this is "implicit" or "universal". In a browser, every CA is trusted equally, and can usurp every other CA. The technical term for this is "implicit universal cross-certification". Peter. From owner-ietf-openpgp@mail.imc.org Sat Jan 31 00:54:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24418 for ; Sat, 31 Jan 2004 00:04:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V4o9G2050416; Fri, 30 Jan 2004 20:50:09 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V4o91O050415; Fri, 30 Jan 2004 20:50:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0V4o8nl050408 for ; Fri, 30 Jan 2004 20:50:08 -0800 (PST) (envelope-from iang@systemics.com) Received: (qmail 32070 invoked from network); 31 Jan 2004 04:50:09 -0000 Received: from unknown (HELO systemics.com) (24.244.145.15) by relay.pair.com with SMTP; 31 Jan 2004 04:50:09 -0000 X-pair-Authenticated: 24.244.145.15 Message-ID: <401B331D.4090603@systemics.com> Date: Fri, 30 Jan 2004 23:46:21 -0500 From: Ian Grigg User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040113 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <002a01c3e7a3$15525a70$da7620d1@umcrookston.edu> In-Reply-To: <002a01c3e7a3$15525a70$da7620d1@umcrookston.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I hope the original poster can now see why it is that trust is not defined in the standard at least - because we can't as yet agree what it is. For whatever reason. iang From owner-ietf-openpgp@mail.imc.org Sat Jan 31 02:37:24 2004 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11632 for ; Sat, 31 Jan 2004 02:37:24 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V7CHPI081403; Fri, 30 Jan 2004 23:12:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V7CHSf081399; Fri, 30 Jan 2004 23:12:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0V7CDsi081343 for ; Fri, 30 Jan 2004 23:12:13 -0800 (PST) (envelope-from iang@systemics.com) Received: (qmail 77550 invoked from network); 31 Jan 2004 07:12:15 -0000 Received: from unknown (HELO systemics.com) (24.244.145.15) by relay.pair.com with SMTP; 31 Jan 2004 07:12:15 -0000 X-pair-Authenticated: 24.244.145.15 Message-ID: <401B546B.5080704@systemics.com> Date: Sat, 31 Jan 2004 02:08:27 -0500 From: Ian Grigg User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040113 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Laager CC: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <000f01c3e7b5$78fa6b00$da7620d1@umcrookston.edu> In-Reply-To: <000f01c3e7b5$78fa6b00$da7620d1@umcrookston.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Richard Laager wrote: > Their certificates could easily have been swapped out by > a MITM attack. Whoa, you're pushing my buttons! Curiosity strikes, have you any *empirical* evidence of this? I hold out hope that we'll see MITMs reach reality in HTTP systems before their decade is out, but others have given up. It's 2004, 10 years almost since SSL was mooted, and we are yet to see an empirical case made against the humble MITM. > Now, if you have a trusted out-of-band channel where > you obtained the certificate or its fingerprint, then add the > certificate to your browser's trusted store. Otherwise, exercising > trust in the certificate is pointless because you're not sure of its > origin. As I said before, in this scenario, HTTPS is effectively > reduced in security to HTTP. That's a stretch. It is based on logical possibilities, not real life risks. For an example, look at SSH, which happily secures a squillion sysadmin connections without any 3rd party certs. My prediction - SSH will take over SSL in the next 10 years, and so will opportunistic encryption. > The trust in a normal HTTPS situation flows like this: > User -> Computer Vendor -> OS Vendor -> Bundled Browser (optionally > - -> signed browser upgrades from [Alternate] Browser Vendor) -> Root > CAs (optionally -> intermediate CAs) -> Site Operator & Site > Certificate -> HTTPS Session The trust in a normal HTTPS-enabled scenario seems to lose thusly: scammer sends spoof email claiming things of great import -> user clicks on recommended site -> user sees standard site -> user enters details -> scammer scores details -> and raids account. Maybe it's just the fact that I lurk in places where trust is *necessary* as there be hard money but there be no Reg Alphabet Soup (I speak here of digital gold currencies). There, it's pretty much the case that the Certificate stuff is ... so far from the issue of security and trust that some DGCs don't even use them to protect their (hard) multi-kilo- gram transactions. > Stop making excuses. Commercial certification authorities and the > X.509 hierarchical structure make it easy for the non-technical > masses to use HTTPS. ADH would work just as well, and at no cost. Economically, it's a slam dunk. There is approximately zero risk of an MITM, so one should spend approximately zero dollars, or grams, to defend against. Self-signed certs would also work well, and are also compatible with the current architecture. > Due to capitalism, the CAs make money providing their service. That would be a .... very interesting thread! > This thread is off-topic so I will refrain from any further response. Dragging it back to OpenPGP - and I agree we are way off threat - OpenPGP's strength is that, to the limited extent that it does, it delivers some small basis in trust architectures. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V7CHPI081403; Fri, 30 Jan 2004 23:12:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V7CHSf081399; Fri, 30 Jan 2004 23:12:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0V7CDsi081343 for ; Fri, 30 Jan 2004 23:12:13 -0800 (PST) (envelope-from iang@systemics.com) Received: (qmail 77550 invoked from network); 31 Jan 2004 07:12:15 -0000 Received: from unknown (HELO systemics.com) (24.244.145.15) by relay.pair.com with SMTP; 31 Jan 2004 07:12:15 -0000 X-pair-Authenticated: 24.244.145.15 Message-ID: <401B546B.5080704@systemics.com> Date: Sat, 31 Jan 2004 02:08:27 -0500 From: Ian Grigg User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040113 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Richard Laager CC: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <000f01c3e7b5$78fa6b00$da7620d1@umcrookston.edu> In-Reply-To: <000f01c3e7b5$78fa6b00$da7620d1@umcrookston.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Richard Laager wrote: > Their certificates could easily have been swapped out by > a MITM attack. Whoa, you're pushing my buttons! Curiosity strikes, have you any *empirical* evidence of this? I hold out hope that we'll see MITMs reach reality in HTTP systems before their decade is out, but others have given up. It's 2004, 10 years almost since SSL was mooted, and we are yet to see an empirical case made against the humble MITM. > Now, if you have a trusted out-of-band channel where > you obtained the certificate or its fingerprint, then add the > certificate to your browser's trusted store. Otherwise, exercising > trust in the certificate is pointless because you're not sure of its > origin. As I said before, in this scenario, HTTPS is effectively > reduced in security to HTTP. That's a stretch. It is based on logical possibilities, not real life risks. For an example, look at SSH, which happily secures a squillion sysadmin connections without any 3rd party certs. My prediction - SSH will take over SSL in the next 10 years, and so will opportunistic encryption. > The trust in a normal HTTPS situation flows like this: > User -> Computer Vendor -> OS Vendor -> Bundled Browser (optionally > - -> signed browser upgrades from [Alternate] Browser Vendor) -> Root > CAs (optionally -> intermediate CAs) -> Site Operator & Site > Certificate -> HTTPS Session The trust in a normal HTTPS-enabled scenario seems to lose thusly: scammer sends spoof email claiming things of great import -> user clicks on recommended site -> user sees standard site -> user enters details -> scammer scores details -> and raids account. Maybe it's just the fact that I lurk in places where trust is *necessary* as there be hard money but there be no Reg Alphabet Soup (I speak here of digital gold currencies). There, it's pretty much the case that the Certificate stuff is ... so far from the issue of security and trust that some DGCs don't even use them to protect their (hard) multi-kilo- gram transactions. > Stop making excuses. Commercial certification authorities and the > X.509 hierarchical structure make it easy for the non-technical > masses to use HTTPS. ADH would work just as well, and at no cost. Economically, it's a slam dunk. There is approximately zero risk of an MITM, so one should spend approximately zero dollars, or grams, to defend against. Self-signed certs would also work well, and are also compatible with the current architecture. > Due to capitalism, the CAs make money providing their service. That would be a .... very interesting thread! > This thread is off-topic so I will refrain from any further response. Dragging it back to OpenPGP - and I agree we are way off threat - OpenPGP's strength is that, to the limited extent that it does, it delivers some small basis in trust architectures. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V5GlGn052188; Fri, 30 Jan 2004 21:16:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V5Glnv052187; Fri, 30 Jan 2004 21:16:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V5Gh95052175 for ; Fri, 30 Jan 2004 21:16:45 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 4949A340CE; Sat, 31 Jan 2004 18:15:47 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0V5Gfe14983; Sat, 31 Jan 2004 18:16:41 +1300 Date: Sat, 31 Jan 2004 18:16:41 +1300 Message-Id: <200401310516.i0V5Gfe14983@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, rlaager@wiktel.com Subject: RE: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Richard Laager" writes: >Hmm. I just tested this with IE. Highlight the first certificate, hold shift, >click the last, hit Delete. Any browser which requires you to individually >delete certificates has a broken UI that's beyond the scope of this >discussion. So much for your 700 mouse clicks. Oh, they must have fixed it in recent versions. >Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are sites as >this is the most logical example given this discussion) is NOT the same as >trusting the certificate alleging to be from Reg.E/Reg.Z. Regulation E and Regulation Z are US consumer-protection legislation covering use of credit and ATM cards. I trust Reg.E/Reg.Z to keep me from harm. I don't trust a CA-issued to cert to do this (although it can't hurt, for reasons given in my previous post). >The only way this would work is if one of the VeriSign certificates in the >certification path was signed by another CA. Furthermore, it would only work >if the server sending its SSL certificate included the VeriSign intermediate >certificate signed by the other root authority. Yup. >Who would explicitly configure a server this way when the VeriSign >certificates are in basically every product that uses SSL? Who would explicitly configure a server to pretend to be Paypal when it isn't? The answer is the same in both cases. >In any case, none of this is "implicit" or "universal". In a browser, every CA is trusted equally, and can usurp every other CA. The technical term for this is "implicit universal cross-certification". Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V4o9G2050416; Fri, 30 Jan 2004 20:50:09 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V4o91O050415; Fri, 30 Jan 2004 20:50:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0V4o8nl050408 for ; Fri, 30 Jan 2004 20:50:08 -0800 (PST) (envelope-from iang@systemics.com) Received: (qmail 32070 invoked from network); 31 Jan 2004 04:50:09 -0000 Received: from unknown (HELO systemics.com) (24.244.145.15) by relay.pair.com with SMTP; 31 Jan 2004 04:50:09 -0000 X-pair-Authenticated: 24.244.145.15 Message-ID: <401B331D.4090603@systemics.com> Date: Fri, 30 Jan 2004 23:46:21 -0500 From: Ian Grigg User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040113 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <002a01c3e7a3$15525a70$da7620d1@umcrookston.edu> In-Reply-To: <002a01c3e7a3$15525a70$da7620d1@umcrookston.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I hope the original poster can now see why it is that trust is not defined in the standard at least - because we can't as yet agree what it is. For whatever reason. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V4mbIh050289; Fri, 30 Jan 2004 20:48:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V4mbb2050288; Fri, 30 Jan 2004 20:48:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail1.wiktel.com (mail1.wiktel.com [204.221.145.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V4ma2r050280 for ; Fri, 30 Jan 2004 20:48:36 -0800 (PST) (envelope-from rlaager@wiktel.com) Received: from NB1131X (unverified [209.32.118.218]) by wiktel.com (Rockliffe SMTPRA 5.3.4) with ESMTP id for ; Fri, 30 Jan 2004 22:49:24 -0600 From: "Richard Laager" To: Subject: RE: Trust Packets Date: Fri, 30 Jan 2004 22:48:29 -0600 Organization: Wikstrom Telecom Internet Message-ID: <000f01c3e7b5$78fa6b00$da7620d1@umcrookston.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200401310342.i0V3gdi14441@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Gutmann wrote: > I could disable the 100+ certs in my browser (a mere 700 > mouse clicks, only a > day or so's work) but then I'd constantly have warning > dialogs popping up and > annoying me while I'm exercising my trust in Reg.E/Reg.Z. Hmm. I just tested this with IE. Highlight the first certificate, hold shift, click the last, hit Delete. Any browser which requires you to individually delete certificates has a broken UI that's beyond the scope of this discussion. So much for your 700 mouse clicks. As for the warning dialogs: These can be disabled in IE. Again, if the browser doesn't let you disable them, that's a UI issue. Exercising trust in the entity Reg.E/Reg.Z (which I'm assuming are sites as this is the most logical example given this discussion) is NOT the same as trusting the certificate alleging to be from Reg.E/Reg.Z. Their certificates could easily have been swapped out by a MITM attack. Now, if you have a trusted out-of-band channel where you obtained the certificate or its fingerprint, then add the certificate to your browser's trusted store. Otherwise, exercising trust in the certificate is pointless because you're not sure of its origin. As I said before, in this scenario, HTTPS is effectively reduced in security to HTTP. The trust in a normal HTTPS situation flows like this: User -> Computer Vendor -> OS Vendor -> Bundled Browser (optionally - -> signed browser upgrades from [Alternate] Browser Vendor) -> Root CAs (optionally -> intermediate CAs) -> Site Operator & Site Certificate -> HTTPS Session If you add an alternate certificate that you've verified some other way: User -> Site Operator & Site Certificate -> HTTPS Session > In > addition disabling only the Verisign roots won't prevent Verisign > certs from being > accepted, because of the implicit universal > cross-certification in browsers > any other CA could issue Verisign certs and they'd be treated > no diferently > from the real thing. The only way this would work is if one of the VeriSign certificates in the certification path was signed by another CA. Furthermore, it would only work if the server sending its SSL certificate included the VeriSign intermediate certificate signed by the other root authority. Who would explicitly configure a server this way when the VeriSign certificates are in basically every product that uses SSL? And, in this example then, the certificate ceases to be a VeriSign certificate and is by definition a certificate which inherits its trust through the other root. So, if you don't trust that root, delete it. In any case, none of this is "implicit" or "universal". Stop making excuses. Commercial certification authorities and the X.509 hierarchical structure make it easy for the non-technical masses to use HTTPS. Not everyone has the desire to participate in a fragile web of trust just to order the latest gadget off a website. Due to capitalism, the CAs make money providing their service. While I share your distrust of VeriSign in some ways, especially in the CA business after the Microsoft fiasco, this is not a protocol or implementation detail. The system is designed and can be used to prevent This thread is off-topic so I will refrain from any further response. Richard Laager -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBQBszmW31OrleHxvOEQJLegCgnHZ9kcAoECb7cW+bLujLm7kjSckAn1zl u39jLDIps3NXQj9lfUFknPzU =f3+0 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V3ghlK046553; Fri, 30 Jan 2004 19:42:43 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V3ghX5046552; Fri, 30 Jan 2004 19:42:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V3gg6S046542 for ; Fri, 30 Jan 2004 19:42:42 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 04E493401D; Sat, 31 Jan 2004 16:41:46 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0V3gdi14441; Sat, 31 Jan 2004 16:42:39 +1300 Date: Sat, 31 Jan 2004 16:42:39 +1300 Message-Id: <200401310342.i0V3gdi14441@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, rlaager@wiktel.com Subject: RE: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Richard Laager" writes: >No, X.509 propagates trust. The root certificates in your browser's >certificate store are there because you trust them. Nope, they're there because I don't have a choice. I *trust* that if I report an unauthorised credit card charge to my CC vendor within 30-60 days, it won't come out of my pocket. I am forced to *depend* on hardcoded CA certs in my browser because without that I can't exercise my trust in Reg.E/Reg.Z. The only thing I trust about a commercial CA-issued cert is that it proves that at some point money changed hands, to the CA's benefit (admittedly this provides at least a small amount of trust by proving that either the web site takes itself seriously enough that it's willing to burn money to make this point or that the script kiddie who r00ted it was skillful enough to get away with it unnoticed). >If you don't trust VeriSign to issue signatures, remove them from the root >certificate store. I could disable the 100+ certs in my browser (a mere 700 mouse clicks, only a day or so's work) but then I'd constantly have warning dialogs popping up and annoying me while I'm exercising my trust in Reg.E/Reg.Z. In addition disabling only the Verisign roots won't prevent Verisign certs from being accepted, because of the implicit universal cross-certification in browsers any other CA could issue Verisign certs and they'd be treated no diferently from the real thing. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2bBtf042058; Fri, 30 Jan 2004 18:37:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V2bBMn042057; Fri, 30 Jan 2004 18:37:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2b8qf042039 for ; Fri, 30 Jan 2004 18:37:10 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id A45123401D; Sat, 31 Jan 2004 15:36:11 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0V2b5u13998; Sat, 31 Jan 2004 15:37:05 +1300 Date: Sat, 31 Jan 2004 15:37:05 +1300 Message-Id: <200401310237.i0V2b5u13998@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, lutz@iks-jena.de Subject: Re: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz Donnerhacke writes: >Furthermore it's easy to implement a keyserver, because you notice how many >new keys/signatures/userid etc. pp. occured. So merging keys is very simple. Yup, and real-time status queries are also incredibly trivial, the user submits a request (e.g. via HTTP, http://......?keyID=abcd), you translate it into "SELECT COUNT(*) FROM validKeys WHERE keyID=abcd" and return the output to the user (there's an RFC draft on this floating around somehere on ietf.org). >>You forgot: >> - Maintaining 10 tables at once is entertaining for the software developer. > >Yep. Obtaining standard query strings from you local DB developer (it's fun >for him) and using them as black box is plain recovery. ;-) While we're rhapsodising about the joys of SQL keyservers, it also makes debugging incredibly easy, you just drop your favourite SQL browse tool onto the database and you can check everything that happens, arranged/filtered by whatever criteria you want. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2b58Y042047; Fri, 30 Jan 2004 18:37:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0V2b5mC042046; Fri, 30 Jan 2004 18:37:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail1.wiktel.com (mail1.wiktel.com [204.221.145.7]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0V2b1OZ042038 for ; Fri, 30 Jan 2004 18:37:04 -0800 (PST) (envelope-from rlaager@wiktel.com) Received: from NB1131X (unverified [209.32.118.218]) by wiktel.com (Rockliffe SMTPRA 5.3.4) with ESMTP id for ; Fri, 30 Jan 2004 20:37:45 -0600 From: "Richard Laager" To: Subject: RE: Trust Packets Date: Fri, 30 Jan 2004 20:36:50 -0600 Organization: Wikstrom Telecom Internet Message-ID: <002a01c3e7a3$15525a70$da7620d1@umcrookston.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Gutmann wrote: ... > For example if > I make a CC > purchase from foo.com, I don't trust them because of their > Verisign cert, but > I have no choice but to depend upon them because if I don't I > can't make my > purchase. So PGP's mechanisms propagate trust, X.509's > propagate dependency. No, X.509 propagates trust. The root certificates in your browser's certificate store are there because you trust them. I realize that the browser vendor pre-loads a bunch of certificates. This is to make things easier for the end user. If you don't trust VeriSign to issue signatures, remove them from the root certificate store. Now, once that's done, does the certificate for foo.com appear valid? No. You've revoked your trust of VeriSign, so it shouldn't. Using the site is NOT dependent on VeriSign. You can make the SSL connection without trusting the certificate. Then, it becomes the same (security-wise) as HTTP; you can't be sure you're avoiding a MITM attack. This would be exactly the same if a Linux vendor preloaded /etc/skel/.gnupg/ with default keys marked as trusted. There is no dependency introduced, just pre-loaded trust. If you didn't trust the pre-loaded keys, you could just remove them. X.509 has its flaws, but it's trust model is in fact based on trust. It's just different from PGP's Web-of-Trust. If you disagree with it because it forces you into rigid hierarchies (typically promoted by commercial interests), fine. But, the underlying technology isn't creating any sort of trust-like dependency. A good definition of "trust" in a computer security context is, "An entity which can break your security policy." (I don't know if this is attributable to the DoD or whom.) In other words, if you have VeriSign in your root certificates, they can break your security policy by issuing a bad certificate. This is not dependence. Richard Laager -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBQBsUmm31OrleHxvOEQKAmwCgz2KoZ1S8yqXWk1uSDLvYH1aVBCsAnR0i L9l/Gcrcx8eLXuDH56bAG3P+ =O1aK -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UJ1m2t013255; Fri, 30 Jan 2004 11:01:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UJ1m0s013254; Fri, 30 Jan 2004 11:01:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from dogbert.ihtfp.org (me@DOGBERT.IHTFP.ORG [204.107.200.33]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UJ1k5g013244 for ; Fri, 30 Jan 2004 11:01:47 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: (from warlord@localhost) by dogbert.ihtfp.org (8.12.9) id i0UJ1hJE013632; Fri, 30 Jan 2004 14:01:43 -0500 To: ietf-openpgp@imc.org Subject: Meeting in Seoul -- call for Agenda Items. From: Derek Atkins Date: Fri, 30 Jan 2004 14:01:43 -0500 Message-ID: User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I'd like to schedule a meeting in Seoul. Do people have specific items they would like to talk about? I know Jon can't make it but I'd like someone to present a 2440bis status (Jon, can you find someone to provide the status). I'll work on the list of open issues and mail that out early next week. We also need to update the milestones for the WG. I'll work with the document editors to flush out that proposal and present it here ASAP. Are there other orders of business for Seoul? Any other presentations to be made? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UIadZK011319; Fri, 30 Jan 2004 10:36:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UIadgg011317; Fri, 30 Jan 2004 10:36:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from slc-exch-1.forumsys.com (67.107.202.130.ptr.us.xo.net [67.107.202.130]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UIaara011302 for ; Fri, 30 Jan 2004 10:36:37 -0800 (PST) (envelope-from lutz@iks-jena.de) Received: from mail pickup service by slc-exch-1.forumsys.com with Microsoft SMTPSVC; Fri, 30 Jan 2004 11:22:01 -0700 Received: from above.proper.com ([208.184.76.39]) by slc-exch-1.forumsys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jan 2004 11:16:27 -0700 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvHFH006966; Fri, 30 Jan 2004 09:57:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHvHce006965; Fri, 30 Jan 2004 09:57:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from excalibur.iks-jena.de (root@excalibur.iks-jena.de [217.17.192.67]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvDI7006955 for ; Fri, 30 Jan 2004 09:57:15 -0800 (PST) (envelope-from lutz@iks-jena.de) Received: from taranis.iks-jena.de (taranis.iks-jena.de [217.17.192.37]) by excalibur.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UCSdD1002139 for ; Fri, 30 Jan 2004 13:28:39 +0100 Received: (from lutz@localhost) by taranis.iks-jena.de (8.12.11/8.12.1/Submit) id i0UCSd7a001167 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 13:28:39 +0100 Date: Fri, 30 Jan 2004 13:28:38 +0100 From: Lutz Donnerhacke To: ietf-openpgp@imc.org Subject: Re: Trust Packets Message-ID: <20040130122838.GF768@taranis.iks-jena.de> References: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i X-message-flag: Please send plain text messages only. Thank you. List-Archive: List-Unsubscribe: List-ID: X-OriginalArrivalTime: 30 Jan 2004 18:16:27.0802 (UTC) FILETIME=[2D82AFA0:01C3E75D] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2004 at 01:20:57AM +1300, Peter Gutmann wrote: > Lutz Donnerhacke writes: > >I distribute the keys over a bunch of tables. > > Hmm, I was afraid you were going to say that. OTOH once it's all set up you > can do some powerful stuff using the SQL query capabilities, e.g. list all > keys that are about to expire, or all keys signed by X, or whatever. Exactly. I added some stuff to automatically remove signatures from revoked keys, etc. pp. Furthermore it's easy to implement a keyserver, because you notice how many new keys/signatures/userid etc. pp. occured. So merging keys is very simple. > (In case anyone's interested, I did a paper on using relational databases as Thanx. I should publish the sql based keyserver, too. > You forgot: > - Maintaining 10 tables at once is entertaining for the software developer. Yep. Obtaining standard query strings from you local DB developer (it's fun for him) and using them as black box is plain recovery. ;-) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvHFH006966; Fri, 30 Jan 2004 09:57:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHvHce006965; Fri, 30 Jan 2004 09:57:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from excalibur.iks-jena.de (root@excalibur.iks-jena.de [217.17.192.67]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHvDI7006955 for ; Fri, 30 Jan 2004 09:57:15 -0800 (PST) (envelope-from lutz@iks-jena.de) Received: from taranis.iks-jena.de (taranis.iks-jena.de [217.17.192.37]) by excalibur.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UCSdD1002139 for ; Fri, 30 Jan 2004 13:28:39 +0100 Received: (from lutz@localhost) by taranis.iks-jena.de (8.12.11/8.12.1/Submit) id i0UCSd7a001167 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 13:28:39 +0100 Date: Fri, 30 Jan 2004 13:28:38 +0100 From: Lutz Donnerhacke To: ietf-openpgp@imc.org Subject: Re: Trust Packets Message-ID: <20040130122838.GF768@taranis.iks-jena.de> References: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> User-Agent: Mutt/1.4.1i X-message-flag: Please send plain text messages only. Thank you. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 31, 2004 at 01:20:57AM +1300, Peter Gutmann wrote: > Lutz Donnerhacke writes: > >I distribute the keys over a bunch of tables. > > Hmm, I was afraid you were going to say that. OTOH once it's all set up you > can do some powerful stuff using the SQL query capabilities, e.g. list all > keys that are about to expire, or all keys signed by X, or whatever. Exactly. I added some stuff to automatically remove signatures from revoked keys, etc. pp. Furthermore it's easy to implement a keyserver, because you notice how many new keys/signatures/userid etc. pp. occured. So merging keys is very simple. > (In case anyone's interested, I did a paper on using relational databases as Thanx. I should publish the sql based keyserver, too. > You forgot: > - Maintaining 10 tables at once is entertaining for the software developer. Yep. Obtaining standard query strings from you local DB developer (it's fun for him) and using them as black box is plain recovery. ;-) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHOUwo004082; Fri, 30 Jan 2004 09:24:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHOUvl004081; Fri, 30 Jan 2004 09:24:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHOSNZ004043 for ; Fri, 30 Jan 2004 09:24:29 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 5DC42340D7; Sat, 31 Jan 2004 01:20:06 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0UCKvg09248; Sat, 31 Jan 2004 01:20:57 +1300 Date: Sat, 31 Jan 2004 01:20:57 +1300 Message-Id: <200401301220.i0UCKvg09248@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, lutz@iks-jena.de Subject: Re: Trust Packets Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz Donnerhacke writes: >I distribute the keys over a bunch of tables. Hmm, I was afraid you were going to say that. OTOH once it's all set up you can do some powerful stuff using the SQL query capabilities, e.g. list all keys that are about to expire, or all keys signed by X, or whatever. (In case anyone's interested, I did a paper on using relational databases as key stores for ACSAC 2000, you can get it from http://www.acsac.org/2000/thu.html. A longer version is available from my home page, the ACSAC page limit was 10 pages so I had to cut some bits out). >This is very efficient compared to the alternatives: > - You search the only the part of the data associated with the query. > - Intertable links are indexed using hashs or btrees. > - Records are dense. You forgot: - Maintaining 10 tables at once is entertaining for the software developer. Peter :-). Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH50M9002220; Fri, 30 Jan 2004 09:05:00 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UH5031002219; Fri, 30 Jan 2004 09:05:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH4w5q002206 for ; Fri, 30 Jan 2004 09:04:59 -0800 (PST) (envelope-from news@branwen.iks-jena.de) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UCVGos031226 for ; Fri, 30 Jan 2004 13:31:16 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.11/8.12.1/Submit) id i0UCVGdD031225 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 13:31:16 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Trust Packets Date: Fri, 30 Jan 2004 12:31:16 +0000 (UTC) Organization: IKS GmbH Jena Lines: 5 Message-ID: References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> <87u12d667a.fsf@alberti.g10code.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1075465876 31190 217.17.192.37 (30 Jan 2004 12:31:16 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Fri, 30 Jan 2004 12:31:16 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Werner Koch wrote: > But these are the real cool things you can do with SQL. Example: Give me all keys whose trust level might be changed by updateing this keyid. So --check-trust does scale. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH1kkB001858; Fri, 30 Jan 2004 09:01:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UH1kLZ001857; Fri, 30 Jan 2004 09:01:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH1hRa001842 for ; Fri, 30 Jan 2004 09:01:43 -0800 (PST) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id DD1C345028; Fri, 30 Jan 2004 09:01:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id CC3B54802B; Fri, 30 Jan 2004 09:01:25 -0800 (PST) Date: Fri, 30 Jan 2004 09:01:25 -0800 (PST) From: Len Sassaman X-X-Sender: rabbi@thetis.deor.org To: Ian Grigg Cc: "Weins, Thorsten" , ietf-openpgp@imc.org Subject: Re: Trust Packets In-Reply-To: <40191400.9080708@systemics.com> Message-ID: References: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> <40191400.9080708@systemics.com> X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004, Ian Grigg wrote: > Some random comments. > > One of the most perceptive decisions that the early PGP > designers made was to not define trust. This was a good > decision because trust defies definition. Trust is too > much wrapped up in context of the user and her companion > users, and the programmer can't really narrow that down > usefully ahead of time. I wouldn't say that they didn't define trust. PGP has internal trust calculation algorithms, which happen not to be documented within the IETF. I have always thought this unfortunate. I agree that trust calculation should be orthogonal to the OpenPGP message format specification, but I do wish that it were documented. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGtlCB001330; Fri, 30 Jan 2004 08:55:47 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGtl3d001328; Fri, 30 Jan 2004 08:55:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fnord.ir.bbn.com (fnord.ir.bbn.com [192.1.100.210]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGtjk1001310 for ; Fri, 30 Jan 2004 08:55:46 -0800 (PST) (envelope-from gdt@ir.bbn.com) Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 0FC0422E2; Fri, 30 Jan 2004 11:02:26 -0500 (EST) To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> From: Greg Troxel Date: 30 Jan 2004 11:02:26 -0500 In-Reply-To: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> Message-ID: Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Since we're getting a bit philosphical here, I don't know if what X.509 > enforces is really "trust". PGP's web of trust is a reasonably accurate use > of the term "trust", but with X.509 you need to read "trust" as "dependency" > (in the sense of "is forced to depend upon"). For example if I make a CC > purchase from foo.com, I don't trust them because of their Verisign cert, but > I have no choice but to depend upon them because if I don't I can't make my > purchase. So PGP's mechanisms propagate trust, X.509's propagate dependency. You of course do have a choice - whether or not to make the purchase. I have declined to buy things because I don't trust people, and I'd hope everyone else is in the same boat. With pgp, you choose whether to believe a message or use a key for encryption. If you "have to" send the message, you "don't have a choice". The ultimate trust model is really no different; it's the kinds of decisions that you can make easily that get encoded into software that differ (and this is important). With foo.com, you choose 1) whether foo.com is actually reputable and you are willing to deal with them (same in PGP and x509 case) and 2) whether you believe that the key you have for foo.com really belongs to foo.com (by choosing to believe that verisign is adequately careful in issuing certs and protecting the CA key), or via some essentially equivalent operation wtih a PGP signature. The real difference is that x509 has a bunch of rules about which signatures won't be believed (due to name subordination) and the cultural (not spec) notion that 'root CAs' are inherently trustworthy, together with the notion and practice that a specific list is included by default. I agree that in practice this cultural difference is large. I think it would be a mistake for the openpgp spec to move in the direction of suggesting that some keys be preconfigured as trusted (where trusted specifically means that name/key bindings signed by those keys are believed). But I don't think anyone is suggesting that. -- Greg Troxel Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGjQAU087782; Fri, 30 Jan 2004 08:45:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGjQtk087781; Fri, 30 Jan 2004 08:45:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGjJLs087771 for ; Fri, 30 Jan 2004 08:45:20 -0800 (PST) (envelope-from ietf-ietf-openpgp@gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1AmXn3-0005d5-00 for ; Fri, 30 Jan 2004 13:30:29 +0100 Received: from h213n3c1o299.bredband.skanova.com ([217.208.174.213]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri Jan 30 12:30:29 2004 Received: from jas by h213n3c1o299.bredband.skanova.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri Jan 30 12:30:29 2004 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-openpgp@imc.org From: Simon Josefsson Subject: Re: Trust Packets Date: Fri, 30 Jan 2004 13:22:57 +0100 Lines: 60 Message-ID: References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org Gmane-NNTP-Posting-Host: h213n3c1o299.bredband.skanova.com User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3.50 (gnu/linux) Cancel-Lock: sha1:jVgWlMtaph5sjz8hOE7PQMAlzFU= Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Werner Koch writes: > >>The concept of a keyring is PGP specific, other implementations may use an >>SQL DB or use a mixed approach, where the trust information is kept separate >>from the keys. > > Just out of interest, is there anyone using an SQL DB to store PGP keys? I am, in a DNS-based OpenPGP key server. It separates key fingerprints with uid like this: create table cks_key_id_table ( key_id char(8) NOT NULL, fkey_id char(16) NOT NULL, fp varchar(40) NOT NULL, PRIMARY KEY(fp) ); create table cks_uid_table ( fkey_id varchar(16) NOT NULL, p_uid int2 NOT NULL, fp varchar(40) NOT NULL, uid varchar(6000) NOT NULL ); > I've thought about this a bit in the past (I use databases to store > other types of keys) but because of the free-form association of > different bits and pieces of keys with identifying information I > can't think of any easy way to do it unless you use a multi-level > lookup. That is, you can't do a: > > SELECT key FROM table WHERE email = foo > > because there could be an arbitrary number of email addresses attached to a > key, and there could be an arbitrary number of keys associated with an email > address. So you need something like: > > SELECT keyID FROM indexTable WHERE email = foo > SELECT key FROM sigKeyTable WHERE keyID = foo > > which isn't very efficient (multiple tables, multi-level lookups, etc etc). Have you tried this and found that performance is the most performance critical area? I am often surprised how efficient modern databases are. When I measured, the network related delays was about five times longer than the database query delay (I'm using multiple tables, two SQL queries per DNS query), even on local network. I admit most of the delays was in the Perl DNS server implementation, or in my use of it, which appear to be rather inefficient, but anyway it suggested to me that I shouldn't worry much about database performance. (The database contained the equivalent of ~2GB PGP keyrings worth of data, although the machine had enough memory to store the entire database in RAM.) Regards, Simon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UBE1VX070462; Fri, 30 Jan 2004 03:14:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UBE13d070461; Fri, 30 Jan 2004 03:14:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UBDxQn070450 for ; Fri, 30 Jan 2004 03:13:59 -0800 (PST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 1AmWbl-0001Ai-00 for ; Fri, 30 Jan 2004 12:14:45 +0100 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 1AmWZV-0003i8-00; Fri, 30 Jan 2004 12:12:25 +0100 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: Thorsten.Weins@secunet.com, ietf-openpgp@imc.org Subject: Re: Trust Packets References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 30 Jan 2004 12:12:25 +0100 In-Reply-To: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> (Peter Gutmann's message of "Fri, 30 Jan 2004 22:54:29 +1300") Message-ID: <87u12d667a.fsf@alberti.g10code.de> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 30 Jan 2004 22:54:29 +1300, Peter Gutmann said: > Just out of interest, is there anyone using an SQL DB to store PGP keys? I've I don't know. From the discussions on the GnuPG MLs I surmised that a some folks are trying to do it. > which isn't very efficient (multiple tables, multi-level lookups, etc etc). But these are the real cool things you can do with SQL. Werner Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAUZoD065449; Fri, 30 Jan 2004 02:30:35 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UAUZJS065448; Fri, 30 Jan 2004 02:30:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAUXmX065429 for ; Fri, 30 Jan 2004 02:30:34 -0800 (PST) (envelope-from news@branwen.iks-jena.de) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.11/8.12.9) with ESMTP id i0UAUSUf027360 for ; Fri, 30 Jan 2004 11:30:28 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.11/8.12.1/Submit) id i0UAUSKv027359 for ietf-openpgp@imc.org; Fri, 30 Jan 2004 11:30:28 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Trust Packets Date: Fri, 30 Jan 2004 10:30:28 +0000 (UTC) Organization: IKS GmbH Jena Lines: 40 Message-ID: References: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1075458628 22964 217.17.192.37 (30 Jan 2004 10:30:28 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Fri, 30 Jan 2004 10:30:28 +0000 (UTC) User-Agent: slrn/0.9.7.4 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Peter Gutmann wrote: > Just out of interest, is there anyone using an SQL DB to store PGP keys? Yes, here. Keyserver on DB. > I've thought about this a bit in the past (I use databases to store other > types of keys) but because of the free-form association of different bits > and pieces of keys with identifying information I can't think of any easy > way to do it unless you use a multi-level lookup. I distribute the keys over a bunch of tables. pgp=# \dt List of relations Schema | Name | Type | Owner --------+-----------------------+-------+------- public | asymmetric_algorithm | table | lutz public | compression_algorithm | table | lutz public | hash_algorithm | table | lutz public | pubkey | table | lutz public | revocation | table | lutz public | revocation_class | table | lutz public | sig | table | lutz public | sigtype | table | lutz public | symmetric_algorithm | table | lutz public | userid | table | lutz (10 rows) > SELECT keyID FROM indexTable WHERE email = foo > SELECT key FROM sigKeyTable WHERE keyID = foo Yes. > which isn't very efficient (multiple tables, multi-level lookups, etc etc). This is very efficient compared to the alternatives: - You search the only the part of the data associated with the query. - Intertable links are indexed using hashs or btrees. - Records are dense. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAA7bv061027; Fri, 30 Jan 2004 02:10:07 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UAA7LJ061025; Fri, 30 Jan 2004 02:10:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UAA4Ck060982 for ; Fri, 30 Jan 2004 02:10:05 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id CBA8634007; Fri, 30 Jan 2004 23:09:08 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0UA9xG08487; Fri, 30 Jan 2004 23:09:59 +1300 Date: Fri, 30 Jan 2004 23:09:59 +1300 Message-Id: <200401301009.i0UA9xG08487@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: iang@systemics.com, Thorsten.Weins@secunet.com Subject: Re: Trust Packets Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian Grigg writes: >An example of this is the x.509 PKI in use in HTTPS - they define trust as >being a CA-signed cert that includes, for example, some notion of what >country you are in (? from?). Since we're getting a bit philosphical here, I don't know if what X.509 enforces is really "trust". PGP's web of trust is a reasonably accurate use of the term "trust", but with X.509 you need to read "trust" as "dependency" (in the sense of "is forced to depend upon"). For example if I make a CC purchase from foo.com, I don't trust them because of their Verisign cert, but I have no choice but to depend upon them because if I don't I can't make my purchase. So PGP's mechanisms propagate trust, X.509's propagate dependency. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U9sneX055250; Fri, 30 Jan 2004 01:54:49 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0U9snC1055249; Fri, 30 Jan 2004 01:54:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U9sdCE055157 for ; Fri, 30 Jan 2004 01:54:42 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 65966340CB; Fri, 30 Jan 2004 22:53:43 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0U9sTs08395; Fri, 30 Jan 2004 22:54:29 +1300 Date: Fri, 30 Jan 2004 22:54:29 +1300 Message-Id: <200401300954.i0U9sTs08395@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Thorsten.Weins@secunet.com, wk@gnupg.org Subject: Re: Trust Packets Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: >The concept of a keyring is PGP specific, other implementations may use an >SQL DB or use a mixed approach, where the trust information is kept separate >from the keys. Just out of interest, is there anyone using an SQL DB to store PGP keys? I've thought about this a bit in the past (I use databases to store other types of keys) but because of the free-form association of different bits and pieces of keys with identifying information I can't think of any easy way to do it unless you use a multi-level lookup. That is, you can't do a: SELECT key FROM table WHERE email = foo because there could be an arbitrary number of email addresses attached to a key, and there could be an arbitrary number of keys associated with an email address. So you need something like: SELECT keyID FROM indexTable WHERE email = foo SELECT key FROM sigKeyTable WHERE keyID = foo which isn't very efficient (multiple tables, multi-level lookups, etc etc). Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TECsVH014253; Thu, 29 Jan 2004 06:12:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TECswT014252; Thu, 29 Jan 2004 06:12:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0TECrd8014246 for ; Thu, 29 Jan 2004 06:12:53 -0800 (PST) (envelope-from iang@systemics.com) Received: (qmail 8828 invoked from network); 29 Jan 2004 14:12:53 -0000 Received: from unknown (HELO systemics.com) (24.244.145.15) by relay.pair.com with SMTP; 29 Jan 2004 14:12:53 -0000 X-pair-Authenticated: 24.244.145.15 Message-ID: <40191400.9080708@systemics.com> Date: Thu, 29 Jan 2004 09:09:04 -0500 From: Ian Grigg User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6b) Gecko/20040113 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Weins, Thorsten" CC: ietf-openpgp@imc.org Subject: Re: Trust Packets References: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> In-Reply-To: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Weins, Thorsten wrote: > Hello, > > the implementation of Trust Packets is implementation specific. > Does anybody know, how these packets are implemented in PGP 7.x or > higher? > > BTW, is there a reason why they are implementation specific? If somebody > uses > different implementations (e.g. on different platforms) of PGP, he will > not be > able to use his "one and only" keyring. Some random comments. One of the most perceptive decisions that the early PGP designers made was to not define trust. This was a good decision because trust defies definition. Trust is too much wrapped up in context of the user and her companion users, and the programmer can't really narrow that down usefully ahead of time. Encouraging an implementation to more closely define trust, and standardising this across implementations, would break it. An example of this is the x.509 PKI in use in HTTPS - they define trust as being a CA-signed cert that includes, for example, some notion of what country you are in (? from?). In terms of keyrings - Werner mentioned the local issues with databases. Trust includes lots of information that will/should never be exported. By not standardising the format of the keyrings (and suggesting inter-program exports to be done by means of ascii-armoured keys) PGP votes to encourage experimenting with trust at the implementation level. This allows an implementation to add some special notes in there, or turn it into an addressbook, or build up signing networks. That's much more beneficial than some committee trying to define trust. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TD95Gw009108; Thu, 29 Jan 2004 05:09:05 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TD94r4009107; Thu, 29 Jan 2004 05:09:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TD92eo009086 for ; Thu, 29 Jan 2004 05:09:03 -0800 (PST) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 1AmBvh-0002t8-00 for ; Thu, 29 Jan 2004 14:09:57 +0100 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 1AmBue-0002IL-00; Thu, 29 Jan 2004 14:08:52 +0100 To: "Weins, Thorsten" Cc: Subject: Re: Trust Packets References: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Thu, 29 Jan 2004 14:08:52 +0100 In-Reply-To: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> (Thorsten Weins's message of "Thu, 29 Jan 2004 10:19:30 +0100") Message-ID: <87brom9a1n.fsf@alberti.g10code.de> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jan 2004 10:19:30 +0100, Weins, Thorsten said: > BTW, is there a reason why they are implementation specific? If somebody > uses > different implementations (e.g. on different platforms) of PGP, he will OpenPGP defines message and key transport formats but not how an application stores the key for its own purpose. The concept of a keyring is PGP specific, other implementations may use an SQL DB or use a mixed approach, where the trust information is kept separate from the keys. Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0T9K35m073435; Thu, 29 Jan 2004 01:20:03 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0T9K3lj073434; Thu, 29 Jan 2004 01:20:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.cubis.de (send.cubis.de [195.226.172.140]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0T9K1bO073364 for ; Thu, 29 Jan 2004 01:20:01 -0800 (PST) (envelope-from Thorsten.Weins@secunet.com) Received: from mailscan-1.tuev-mitte.de (mailscan-1.cubis.de [10.0.142.44]) by mailgate.cubis.de (Switch-2.2.9/Switch-2.2.4) with SMTP id W0T90JYK00001050 for ; Thu, 29 Jan 2004 10:19:34 +0100 Received: From mailscan-2.tuev-mitte.de ([10.0.142.43]) by mailscan-1.tuev-mitte.de (WebShield SMTP v4.5 MR1a P0803.345); id 1075367970922; Thu, 29 Jan 2004 10:19:30 +0100 Received: From snsrv003.secumail.de ([10.36.12.43]) by mailscan-2.tuev-mitte.de (WebShield SMTP v4.5 MR1a); id 1075367963571; Thu, 29 Jan 2004 10:19:23 +0100 content-class: urn:content-classes:message Subject: Trust Packets MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Jan 2004 10:19:30 +0100 Message-ID: <19858F8ED1F9434FBF54E38F8A060289681E82@snsrv003.ek.secunet.de> X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Trust Packets Thread-Index: AcPmSSiJ7HQZlv23T6Cwd78kRsSxXw== From: "Weins, Thorsten" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0T9K2bO073420 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, the implementation of Trust Packets is implementation specific. Does anybody know, how these packets are implemented in PGP 7.x or higher? BTW, is there a reason why they are implementation specific? If somebody uses different implementations (e.g. on different platforms) of PGP, he will not be able to use his "one and only" keyring. Thanks in advance, Thorsten Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SMVCBe066342; Wed, 28 Jan 2004 14:31:12 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SMVCMR066341; Wed, 28 Jan 2004 14:31:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SMVArC066330 for ; Wed, 28 Jan 2004 14:31:11 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id i0SMUwc23433 for ; Wed, 28 Jan 2004 17:31:03 -0500 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0SMT9w19348 for ietf-openpgp@imc.org; Wed, 28 Jan 2004 17:29:09 -0500 Date: Wed, 28 Jan 2004 17:29:09 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Minor MDC inconsistency in bis-09 Message-ID: <20040128222909.GA19258@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (47% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In bis-09, section 5.13 says in regards to what gets hashed into the MDC: "The input to the hash function includes the prefix data described above". The next section, 5.14, says in regards to the body of the MDC packet: "...NOT including prefix data...". (my emphasis) Given the evidence of working code, I suspect section 5.14 is incorrect. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ON0vib070346; Sat, 24 Jan 2004 15:00:57 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0ON0v51070345; Sat, 24 Jan 2004 15:00:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from [63.202.92.156] (adsl-63-202-92-156.dsl.snfc21.pacbell.net [63.202.92.156]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ON0tic070335; Sat, 24 Jan 2004 15:00:55 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Sat, 24 Jan 2004 15:00:56 -0800 To: (various IETF lists) From: Paul Hoffman / IMC Subject: New mail-ng mailing list open for sign-ups Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MMi7ib087544; Thu, 22 Jan 2004 14:44:07 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MMi7xi087541; Thu, 22 Jan 2004 14:44:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (IDENT:root@226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MMi5ib087535 for ; Thu, 22 Jan 2004 14:44:06 -0800 (PST) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id i0MMhb614460 for ietf-openpgp@imc.org; Thu, 22 Jan 2004 14:43:37 -0800 Date: Thu, 22 Jan 2004 14:43:37 -0800 From: "Hal Finney" Message-Id: <200401222243.i0MMhb614460@finney.org> To: ietf-openpgp@imc.org Subject: Reason for V4 signature postscript Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I got some email from Peter Gutmann asking why we do the bizarre "postscript" in the hashing of V4 signatures. I didn't remember, but some digging into the code shed light on it, and gradually the reasons came back. Here is the mail I sent to him, which may be useful for future software archaeologists. The general concern we had was "aliasing", meaning that a specific set of bytes which were hashed could mean different things in different contexts. Specifically, we were worried that a V3 sig could have the same bytes hashed as a V4. The problem is that V3 sigs don't hash the sig version. They hash the body of the data, which could be anything, and then they hash the sig type and then 4 bytes of sig creation time. We wanted to make certain that you couldn't conjure up a document and get someone to put a V3 sig on it, and then turn that into a V4 sig on something else. So we wanted to make sure the last 5 hashed bytes for a V4 sig could never look like the last 5 hashed bytes for a V3 sig. The oldest version of the code I could find reads like this: /* Add hash "postscript", ensure hashed data not alias anything */ postscript[0] = PGPVERSION_4; /* Hash-convention version */ postscript[1] = 0xff; /* 5th from end, != any sig type value */ postscript[2] = (PGPByte)(l >> 24); postscript[3] = (PGPByte)(l >> 16); postscript[4] = (PGPByte)(l >> 8); postscript[5] = (PGPByte)(l >> 0); PGPContinueHash (temp_hc, postscript, sizeof(postscript)); The 4 is the hash-convention version, which I guess we meant to distinguish from the signature version. The FF is there as that is never a value found in the 5th from the end (or 4th from the end if you count differently) of the data hashed for a V3 sig. This assures that no V4 and V3 sigs will ever have the same bytes hashed. I remember now why the length was there. It allows for unambiguous parsing of the fields of the signature packet, counting from the far end. Without that, there may be ambiguity about how to parse it out, because there is no way, starting from the front, to know where the signed-document's data ends and the data from the signature begins. The signed-document's data is hashed with no headers, just the content of the document, so you don't know where it ends. As long as the hashed data can be unambiguously parsed from one end or the other, there is no danger of border-shifting, where data that is supposed to be part of one field can be interpreted as being part of another. Without this length field, that is a problem. So that explains the length, and the FF. The 4 still seems a little redundant, but by the end of one of these exercises, you get sort of paranoid about both making sure no ambiguities are possible, and also leaving yourself an escape so that the next version of the software won't suffer from this. Since we were relying on parsing from the end to prevent aliasing, it felt a little safer to put a version field right near that end. That way if we ever went to a V5 signature we could do so without worry that it could be aliased with a V4 sig. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DN2Pib069886; Tue, 13 Jan 2004 15:02:25 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DN2P2V069885; Tue, 13 Jan 2004 15:02:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from slc-exch-1.forumsys.com (67.107.202.130.ptr.us.xo.net [67.107.202.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DN2Nib069879 for ; Tue, 13 Jan 2004 15:02:24 -0800 (PST) (envelope-from hmujtaba@forumsys.com) Received: from bstn-exch1.forumsys.com ([10.5.2.12]) by slc-exch-1.forumsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jan 2004 16:02:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: check for complementary keys Date: Tue, 13 Jan 2004 18:02:19 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D19023F@bstn-exch1.forumsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: check for complementary keys Thread-Index: AcPaGlOlIeq4nmG7SKyN6dVI0HOUIQADl3Bw From: "Hasnain Mujtaba" To: X-OriginalArrivalTime: 13 Jan 2004 23:02:20.0973 (UTC) FILETIME=[4C931DD0:01C3DA29] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0DN2Oib069881 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks. This will make it easier for me to read the public key from the private key and then do a match on the fingerprints of the two public keys. -----Original Message----- From: owner-ietf-openpgp@mail.imc.org [mailto:owner-ietf-openpgp@mail.imc.org] On Behalf Of David Shaw Sent: Tuesday, January 13, 2004 4:00 PM To: ietf-openpgp@imc.org Subject: Re: check for complementary keys On Tue, Jan 13, 2004 at 02:34:06PM -0500, Hasnain Mujtaba wrote: > > Hi all, > > What is a good way to check whether an openpgp public and private key > pair is complementary? One way I can think of is to do an > encrypt/decrypt test with the keypair. But is there another way to > determine this just by looking at the key material of the two keys? The OpenPGP packet format for private keys contains a complete copy of the corresponding public key. If you are not concerned about manipulation of the secret key packet, you could simply compare this embedded public key to the public key in question. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DL0qib064300; Tue, 13 Jan 2004 13:00:52 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DL0qVd064299; Tue, 13 Jan 2004 13:00:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DL0oib064294 for ; Tue, 13 Jan 2004 13:00:51 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0DL07v30175 for ietf-openpgp@imc.org; Tue, 13 Jan 2004 16:00:07 -0500 Date: Tue, 13 Jan 2004 16:00:06 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: check for complementary keys Message-ID: <20040113210006.GB29673@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <4DCE15B9C4E66F4CA967EBF64C53D64D01570F@bstn-exch1.forumsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DCE15B9C4E66F4CA967EBF64C53D64D01570F@bstn-exch1.forumsys.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (65% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jan 13, 2004 at 02:34:06PM -0500, Hasnain Mujtaba wrote: > > Hi all, > > What is a good way to check whether an openpgp public and private key > pair is complementary? One way I can think of is to do an > encrypt/decrypt test with the keypair. But is there another way to > determine this just by looking at the key material of the two keys? The OpenPGP packet format for private keys contains a complete copy of the corresponding public key. If you are not concerned about manipulation of the secret key packet, you could simply compare this embedded public key to the public key in question. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJYDib060800; Tue, 13 Jan 2004 11:34:13 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DJYDMY060799; Tue, 13 Jan 2004 11:34:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from slc-exch-1.forumsys.com (67.107.202.130.ptr.us.xo.net [67.107.202.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DJYCib060791 for ; Tue, 13 Jan 2004 11:34:12 -0800 (PST) (envelope-from hmujtaba@forumsys.com) Received: from bstn-exch1.forumsys.com ([10.5.2.12]) by slc-exch-1.forumsys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Jan 2004 12:34:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: check for complementary keys Date: Tue, 13 Jan 2004 14:34:06 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D01570F@bstn-exch1.forumsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: check for complementary keys Thread-Index: AcPaC89j3wWv/86PQim0vYrypPFbsw== From: "Hasnain Mujtaba" To: X-OriginalArrivalTime: 13 Jan 2004 19:34:08.0873 (UTC) FILETIME=[36B3ED90:01C3DA0C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0DJYDib060795 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, What is a good way to check whether an openpgp public and private key pair is complementary? One way I can think of is to do an encrypt/decrypt test with the keypair. But is there another way to determine this just by looking at the key material of the two keys? Thanks Hasnain. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DILvib056509; Tue, 13 Jan 2004 10:21:57 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0DILvut056508; Tue, 13 Jan 2004 10:21:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0DILuib056503 for ; Tue, 13 Jan 2004 10:21:57 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0DILCY28648 for ietf-openpgp@imc.org; Tue, 13 Jan 2004 13:21:12 -0500 Date: Tue, 13 Jan 2004 13:21:12 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: The last word (hopefully) on back-signatures Message-ID: <20040113182112.GA28614@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20040112195811.GB3329@jabberwocky.com> <200401130924.43953@fortytwo.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200401130924.43953@fortytwo.ch> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (73% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jan 13, 2004 at 09:24:43AM +0100, Adrian von Bidder wrote: Content-Description: signed data > On Monday 12 January 2004 20:58, David Shaw wrote: > > I have > > code for GnuPG that follows this basic design, and it works well. > > Will it be possible to convert existing subkeys? AFAICT, putting the 0x19 > signature in an unhashed packet, this should be relatively painless. (Will > keyservers properly deal with subkeys with the additional packet suddenly > appearing?) Yes, it is possible to convert existing subkeys. One of the reasons I advocated using a subpacket was for this ability. Based on a number of tests, and a conversation with the author of SKS, I don't see any problem with updating existing subkeys on the PKSD or SKS servers. I haven't looked at the LDAP server yet. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D8Onib093064; Tue, 13 Jan 2004 00:24:49 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0D8Onkj093063; Tue, 13 Jan 2004 00:24:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from zbasel.fortytwo.ch (postfix@zbasel.fortytwo.ch [212.254.206.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0D8Omib093037 for ; Tue, 13 Jan 2004 00:24:49 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: from onaras.ch (zux174-013.adsl.green.ch [80.254.174.13]) by zbasel.fortytwo.ch (Postfix) with ESMTP id 0CD12A1 for ; Tue, 13 Jan 2004 09:24:45 +0100 (CET) From: Adrian von Bidder To: ietf-openpgp@imc.org Subject: Re: The last word (hopefully) on back-signatures Date: Tue, 13 Jan 2004 09:24:43 +0100 User-Agent: KMail/1.5.4 References: <20040112195811.GB3329@jabberwocky.com> In-Reply-To: <20040112195811.GB3329@jabberwocky.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Lt6AAZ+FoIhfEfo"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401130924.43953@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_Lt6AAZ+FoIhfEfo Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Monday 12 January 2004 20:58, David Shaw wrote: > I have > code for GnuPG that follows this basic design, and it works well. Will it be possible to convert existing subkeys? AFAICT, putting the 0x19=20 signature in an unhashed packet, this should be relatively painless. (Will= =20 keyservers properly deal with subkeys with the additional packet suddenly=20 appearing?) cheers =2D- vbi =2D-=20 featured product: vim - http://vim.org --Boundary-02=_Lt6AAZ+FoIhfEfo Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAkADq0tgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6rXsAn2kHqESpZaIaNcNeU9yT3PGp KcNUAKCBhYPK3kyUu92toM3OKMg8qRbHIQ== =95v1 -----END PGP SIGNATURE----- --Boundary-02=_Lt6AAZ+FoIhfEfo-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CJx1ib003097; Mon, 12 Jan 2004 11:59:01 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0CJx1IN003096; Mon, 12 Jan 2004 11:59:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0CJwxib003090 for ; Mon, 12 Jan 2004 11:59:00 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id i0CJwBE15591 for ietf-openpgp@imc.org; Mon, 12 Jan 2004 14:58:11 -0500 Date: Mon, 12 Jan 2004 14:58:11 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: The last word (hopefully) on back-signatures Message-ID: <20040112195811.GB3329@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (76% of Full) User-Agent: Mutt/1.5.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Apologies for the delay in this. I've had a lot on my plate recently. In November, I posted two proposals for comment on the "stolen signature"/back-signatures problem. Here now is my final proposal with the various comments taken into account: First to briefly recap the purpose for this, there is a minor problem in the current subkey design where a signing subkey can be taken from an existing key, and bound to the attacker's primary key with a binding signature issued by the attacker's key. The attacker cannot use this stolen key to issue a signature of course, but can claim that an existing signature was issued by him. The proposed fix is to add an additional signature into the mix - currently we have only a binding signature issued by the primary key on the signing subkey. I suggest we add a signature (the "back-signature") issued by the subkey on the primary key. This prevents the attack as the attacker cannot issue this signature, and thus cannot claim ownership of an existing signature. The back-signature design seemed to enjoy greater approval than the other, as well as having the nice detail that it could automatically protect signatures issued before the back-signature was added. The specifics (suggestions - I'm not wedded to this particular language): 1) Define a new type of signature subpacket that consists of a regular signature contained in a subpacket. Add to section 5.2.3.1 ("Signature Subpacket Specification"): 32 = embedded signature Add a new section to 5.2.3.x: 5.2.3.26. Embedded Signature (1 signature packet body) This subpacket contains a complete signature packet body as specified in section 5.2 above. It is useful when one signature needs to refer to, or be incorporated in, another signature. 2) Define a new signature class (Hal suggested 0x19), that is defined as a subkey signature on a primary key. Add to section 5.2.1 ("Signature Types"): 0x19: Primary key Binding Signature This signature is a statement by a signing subkey, indicating that it is owned by the primary key. This signature is calculated directly on the primary key itself, and not on any User ID or other packets. 3) At (sub)key generation time (or later, for existing keys) create this 0x19 signature and store it as a subpacket on the subkey binding signature. It does not matter whether it is a hashed subpacket or not. The hashing rules for 0x19 are the same as a 0x18 signature - we hash the primary key, then the subkey, and issue a signature from the subkey over this hash. In section 5.2.1, add to the description of the 0x18 signature: Signing subkeys have an embedded signature subpacket on this signature which contains a 0x19 signature by the signing subkey on the primary key. In section 5.2.4, change the sentence: A subkey signature (type 0x18) then hashes the subkey, using the same format as the main key (also using 0x99 as the first octet). to: A subkey binding signature (type 0x18), or primary key binding signature (0x19) then hashes the subkey, using the same format as the main key (also using 0x99 as the first octet). In section 10.1, change the sentence: Each Subkey packet must be followed by one Signature packet, which should be a subkey binding signature issued by the top level key. to: Each Subkey packet must be followed by one Signature packet, which should be a subkey binding signature issued by the top level key. For subkeys that can issue signatures, the subkey binding signature must contain an embedded signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top level key. That should do it. I've tried to keep the number of changes to a minimum, so this may seem somewhat terse. I do think it is sufficient to explain the proper way to write the additional signature. I have code for GnuPG that follows this basic design, and it works well. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06HW2ib052321 for ; Tue, 6 Jan 2004 09:32:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i06HW1LH052320 for ietf-openpgp-bks; Tue, 6 Jan 2004 09:32:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06HVwib052312 for ; Tue, 6 Jan 2004 09:31:59 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 7764669A9F; Tue, 6 Jan 2004 12:31:59 -0500 (EST) Message-ID: <3FFAF072.9F35AB8E@systemics.com> Date: Tue, 06 Jan 2004 12:29:22 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 Cc: ietf-openpgp@imc.org Subject: Re: cleartext signed messages - UTF-8 - stripping the whitespace References: <3FF981B2.91E72DAF@systemics.com> <200401052057.21742@fortytwo.ch> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Adrian 'Dagurashibanipal' von Bidder wrote: > > On Monday 05 January 2004 16:24, Ian Grigg wrote: ... > > 3. What was the original deep dark motivation > > for stripping whitespace from the end of lines > > anyway? > > > > 4. Do we care if UTF-8 has some weird whitespace/ > > line endings? > > IIRC from previous discussions (I wasn't around for years when PGP was > introduced to the world...): some mailers (MUAs and MTAs) used to strip > whitespace occasionally or do other weird things. Thinking about it, I've come across editors and desktops that do something similar, they add spaces to the end of lines in arbitrary fashions, and sometimes modify newlines (take away, add) at the end of files (but newlines are adequately protected already in the draft). > Those old mailers would probably either treat all non-ASCII whitespace and > line-endings as normal characters, or not be 8-bit clean anyway and so cause > problems in any case. So the answer to (4) is probably a clear no. So, the upshot is that only the defined US-ASCII whitespace chars should be included in the canonicalisation: .... Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. In which case it might be worth adding a comment to that effect. Because of the difficulties of predicting the future here, I'd suggest the following: Also, any trailing whitespace (0x20, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Implementations MAY elect to clean line endings of whitespace in the final signed form of the document, including UTF-8 forms. Thus, when we hit upon some troublesome mailer that mangles non-english language Word-prepared UTF-8 documents, the OpenPGP plugin can pre-emptively clean it up and still be in accord with the standard. If applications start adding UTF-8 whitespace afterwards, then we have more of a problem. I guess at that point, implementations can agree to add additional characters to the "ignore" list. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05JvQib011098 for ; Mon, 5 Jan 2004 11:57:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05JvQnn011097 for ietf-openpgp-bks; Mon, 5 Jan 2004 11:57:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from gluggsi.fortytwo.ch (zux006-032-031.adsl.green.ch [81.6.32.31]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05JvOib011085 for ; Mon, 5 Jan 2004 11:57:25 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: from altfrangg.fortytwo.ch (altfrangg.fortytwo.ch [192.168.1.17]) by gluggsi.fortytwo.ch (Postfix) with ESMTP id 4869198FE1 for ; Mon, 5 Jan 2004 20:57:22 +0100 (CET) From: "Adrian 'Dagurashibanipal' von Bidder" To: ietf-openpgp@imc.org Subject: Re: cleartext signed messages - UTF-8 - stripping the whitespace Date: Mon, 5 Jan 2004 20:57:18 +0100 User-Agent: KMail/1.5.4 References: <3FF981B2.91E72DAF@systemics.com> In-Reply-To: <3FF981B2.91E72DAF@systemics.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_hGc+/fRzPla9c3B"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401052057.21742@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_hGc+/fRzPla9c3B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Monday 05 January 2004 16:24, Ian Grigg wrote: [...] > Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of > any line is ignored when the cleartext signature is calculated. > 2. Are there UTF-8 whitespace encodings that > are not in the definitions above? > > I.e., not in "spaces, and tabs, 0x09" . > > 3. What was the original deep dark motivation > for stripping whitespace from the end of lines > anyway? > > 4. Do we care if UTF-8 has some weird whitespace/ > line endings? IIRC from previous discussions (I wasn't around for years when PGP was=20 introduced to the world...): some mailers (MUAs and MTAs) used to strip=20 whitespace occasionally or do other weird things. Those old mailers would probably either treat all non-ASCII whitespace and= =20 line-endings as normal characters, or not be 8-bit clean anyway and so caus= e=20 problems in any case. So the answer to (4) is probably a clear no. cheers =2D- vbi =2D-=20 featured product: PostgreSQL - http://postgresql.org --Boundary-02=_hGc+/fRzPla9c3B Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAj/5waFgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJEIukMYvlp/fWSdkAn1Udm/e8rfsOeCFf+f+utjjE pf6zAJoD8YFkbqWtdRhBXDeorb/ye0D+mA== =iY1l -----END PGP SIGNATURE----- --Boundary-02=_hGc+/fRzPla9c3B-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05FRBib098152 for ; Mon, 5 Jan 2004 07:27:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05FRB5x098151 for ietf-openpgp-bks; Mon, 5 Jan 2004 07:27:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05FRAib098146 for ; Mon, 5 Jan 2004 07:27:10 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 8644069A80; Mon, 5 Jan 2004 10:27:11 -0500 (EST) Message-ID: <3FF981B2.91E72DAF@systemics.com> Date: Mon, 05 Jan 2004 10:24:34 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: cleartext signed messages - UTF-8 - stripping the whitespace Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm working on some code that deals with cleartext signed messages over UTF-8 [1]. In debugging the treatment of UTF-8, I looked at the definition of mods that OpenPGP does to the cleartext (paras 3,5) for signature treatment [2]: As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical line endings. The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. .... Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. Here are the questions: 1. In UTF-8, are there such things as line endings that are not of and/or form? 2. Are there UTF-8 whitespace encodings that are not in the definitions above? I.e., not in "spaces, and tabs, 0x09" . 3. What was the original deep dark motivation for stripping whitespace from the end of lines anyway? 4. Do we care if UTF-8 has some weird whitespace/ line endings? 5. Are we explicitly ignoring these? Hence the question 3, perhaps the answer can guide us.... It seems the easiest thing is to say that we explicitly do not include any UTF-8 characters in the above discussion. And add a clarifying comment to that effect. Perhaps also something to the effect of: Implementations MAY strip whitespace (including any UTF-8 whitespace that is recognised) from line endings before signing, so that the resultant cleartext signed message will not include any complex lines. (That's essentially what I try and do in my code, but I recognise that this goes beyond the standard....) Alternatively, if someone can nail what UTF-8 does in whitespace, it might be possible to put in more consideration. iang [1] Code is based on Edwin Woudt's OpenPGP in Java as found at http://www.cryptix.org/products/openpgp/index.html The application is Ricardian Contracts in Spanish. [2] Looking at at section 7.1, Dash-Escaped Text, of the current draft: draft-ietf-openpgp-rfc2440bis-09.txt http://carmen.cselt.it/internet-drafts/draft-ietf-openpgp-rfc2440bis-09.txt Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EwVib097109 for ; Mon, 5 Jan 2004 06:58:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05EwVjB097108 for ietf-openpgp-bks; Mon, 5 Jan 2004 06:58:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EwRib097102 for ; Mon, 5 Jan 2004 06:58:28 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id A799569A80; Mon, 5 Jan 2004 09:58:22 -0500 (EST) Message-ID: <3FF97AF0.A32F3D24@systemics.com> Date: Mon, 05 Jan 2004 09:55:44 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: cleartext signatures - consistent naming Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Searching on the draft 2440bis-09.txt, I find several variations of the cleartext signature naming: signatures following clearsigned messages. p48 particularly important when computing a cleartext signature This is used only in clear-signed messages. p49 7. cleartext signature framework another way to clear sign messages ... The cleartext signed message consists of: ... It seems that the word "cleartext" is the dominant form, followed by signing in some appropriate verb form. It would be nice if the parts outside section 7 (lines 1,3 above) also used that convention, to make searching easier. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EAWib094068 for ; Mon, 5 Jan 2004 06:10:32 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05EAVuT094067 for ietf-openpgp-bks; Mon, 5 Jan 2004 06:10:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05EASib094060 for ; Mon, 5 Jan 2004 06:10:28 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 9B89910E59D; Mon, 5 Jan 2004 06:10:28 -0800 (PST) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id i05EASKs055906; Mon, 5 Jan 2004 06:10:28 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id i05EASOX055905; Mon, 5 Jan 2004 06:10:28 -0800 (PST) Message-Id: <200401051410.i05EASOX055905@mailserver2.hushmail.com> Date: Mon, 5 Jan 2004 06:10:28 -0800 To: ietf-openpgp@imc.org, gnupg-users@gnupg.org Cc: Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 05 Jan 2004 05:06:54 -0800 Ralf Hauser wrote: > >To my understanding, > >If I send a message with attachments, the attachment filename is >visible >without cryptanalysis. >Would it be hard to give the encrypted file a random name and only >upon >decryption, give it back its real name? there is a simple workaround you might be interested in: armor the attachment (without encryption) and include the armored attachment as part of the plaintext of the message, and then encrypt the entire message not only the filename, but even the fact that you are sending an attachment, will not be apparent (although it may be guessed at by the size of the message) vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05Desib092958 for ; Mon, 5 Jan 2004 05:40:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05DesnV092957 for ietf-openpgp-bks; Mon, 5 Jan 2004 05:40:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ethos.braverock.com (IDENT:G8oh9If5RDETGXsm7dHrgW7BApljLOqq@dsl092-142-180.chi1.dsl.speakeasy.net [66.92.142.180]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05Derib092952 for ; Mon, 5 Jan 2004 05:40:53 -0800 (PST) (envelope-from brian@braverock.com) Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by ethos.braverock.com (8.12.8/8.12.5) with ESMTP id i05DeoTl030326; Mon, 5 Jan 2004 07:40:50 -0600 Received: (from apache@localhost) by ethos.braverock.com (8.12.8/8.12.5/Submit) id i05DenAX030324; Mon, 5 Jan 2004 07:40:49 -0600 Received: from 38.115.154.129 (SquirrelMail authenticated user brian); by mail.braverock.com with HTTP; Mon, 5 Jan 2004 07:40:49 -0600 (CST) Message-ID: <62000.38.115.154.129.1073310049.squirrel@38.115.154.129> In-Reply-To: References: Date: Mon, 5 Jan 2004 07:40:49 -0600 (CST) Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide? From: "Brian G. Peterson" To: hauser@acm.org Cc: ietf-openpgp@imc.org, gnupg-users@gnupg.org User-Agent: SquirrelMail/1.4.3 [CVS] X-Mailer: SquirrelMail/1.4.3 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ralf Hauser said: > > To my understanding, > > If I send a message with attachments, the attachment filename is visible > without cryptanalysis. > Would it be hard to give the encrypted file a random name and only upon > decryption, give it back its real name? > > http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this > issue. > > Isn't that kind of giving away information that could be easily protected > - > or did I miss something? > > Rgds > Ralf Ralf, This is totally an implementation detail. Many mail programs that integrate PGP or GnuPG already *do* obfuscate the filename, calling it encrypted.dat.asc or data.asc or somerandomstring.asc. If the asc file has an embedded filename, any OpenPGP compatible client should be able to retrieve the file name upon decryption. There are times when knowing the filenmae may be more important than obfuscating it for security reasons. The reverse is most certainly true as well. In my opinion, it should probably be left as an implementation detail for each OpenPGP compatible mail client to decide on. Regards, - Brian Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05DVuib092704 for ; Mon, 5 Jan 2004 05:31:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05DVu3n092703 for ietf-openpgp-bks; Mon, 5 Jan 2004 05:31:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from zbasel.fortytwo.ch (postfix@zbasel.fortytwo.ch [212.254.206.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05DVtib092698 for ; Mon, 5 Jan 2004 05:31:55 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: from onaras.ch (zux174-013.adsl.green.ch [80.254.174.13]) by zbasel.fortytwo.ch (Postfix) with ESMTP id 91C3F103; Mon, 5 Jan 2004 14:31:51 +0100 (CET) From: Adrian von Bidder To: , Subject: Re: filenames of encrypted attachments visible ? How hard would it be to hide? Date: Mon, 5 Jan 2004 14:31:50 +0100 User-Agent: KMail/1.5.4 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_GdW+/lK0Ha2Hbm9"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401051431.50915@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_GdW+/lK0Ha2Hbm9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline [sorry. ralf, of course I meant to answer to the lists] On Monday 05 January 2004 14:06, Ralf Hauser wrote: > To my understanding, > > If I send a message with attachments, the attachment filename is visible > without cryptanalysis. > Would it be hard to give the encrypted file a random name and only upon > decryption, give it back its real name? > > http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this > issue. > > Isn't that kind of giving away information that could be easily protected= - > or did I miss something? Hi, You did miss rfc3156 (PGP/MIME). The structure of these (encrypted) emails = is: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =46rom: whatever To: whatever Subject: whatever Date: whatever Content-Type: multipart/encrypted; protocol=3D"application/pgp-encrypted"; boundary=3D"Boundary-02=3D_5Plx/pJ9Yq8C9E0" =2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0 Content-Type: application/pgp-encrypted Version: 1 =2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0 Content-Type: application/octet-stream =2D----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.3 (GNU/Linux) hQEOAzLIxTMIwnnYEAP.... =2E... AFWzv4cn5IDmQ5A93JaApgQg6g=3D=3D =3DpVu5 =2D----END PGP MESSAGE----- =2D-Boundary-02=3D_5Plx/pJ9Yq8C9E0-- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D And the encrypted part is again a full MIME message, with attachments and a= ll.=20 So the only relevant bits that go over the wire unencrypted are From/To=20 (unavoidable to the extent of the email addresses) and the Subject (I have = a=20 proposal that could address this cooking slowly, I think I posted it in som= e=20 places a few months ago). Greetings =2D- vbi =2D-=20 joeyh now has a terminal at the couch? That guy is wired, I swear =3D3D> Knghtbrd: laptop and I don't mean the cats. --Boundary-02=_GdW+/lK0Ha2Hbm9 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAj/5Z0ZgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6+swAn0FQMt82dPEXK1qy7bMqhNtm whPDAJ4wcQcQqaRF/6xP9kvqrwofqtlHBA== =ahv8 -----END PGP SIGNATURE----- --Boundary-02=_GdW+/lK0Ha2Hbm9-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i05D5Nib091759 for ; Mon, 5 Jan 2004 05:05:23 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i05D5Nwk091758 for ietf-openpgp-bks; Mon, 5 Jan 2004 05:05:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.10/8.12.8) with SMTP id i05D5Hib091744 for ; Mon, 5 Jan 2004 05:05:18 -0800 (PST) (envelope-from ralfhauser@gmx.ch) Received: (qmail 7943 invoked by uid 65534); 5 Jan 2004 13:05:11 -0000 Received: from adsl-62-167-79-128.adslplus.ch (EHLO rhauserPCGF590K) (62.167.79.128) by mail.gmx.net (mp014) with SMTP; 05 Jan 2004 14:05:11 +0100 X-Authenticated: #14555992 Reply-To: From: "Ralf Hauser" To: , Subject: filenames of encrypted attachments visible ? How hard would it be to hide? Date: Mon, 5 Jan 2004 14:06:54 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To my understanding, If I send a message with attachments, the attachment filename is visible without cryptanalysis. Would it be hard to give the encrypted file a random name and only upon decryption, give it back its real name? http://www.ietf.org/rfc/rfc2440.txt doesn't appear state anything on this issue. Isn't that kind of giving away information that could be easily protected - or did I miss something? Rgds Ralf Sample use case: Some investment banker uses PGP and sends around an attachment with the name "UnfriendlyTakeoverOfListedCorpXYZ.doc.asc" - isn't that kind of an invitation to insiders? Sure, it wouldn't be hard to rename the file before sending, but this kind of negligence is happening all over... and I hope applications like gpg/pgp could eventually become fool-proof/fail-safe to this level?