From owner-ietf-openpgp@mail.imc.org Mon Dec 1 10:13:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13862 for ; Mon, 1 Dec 2003 10:12:59 -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 hB1EjFib085732 for ; Mon, 1 Dec 2003 06:45:15 -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 hB1EjFiN085731 for ietf-openpgp-bks; Mon, 1 Dec 2003 06:45:15 -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.10/8.12.8) with ESMTP id hB1EjDib085720 for ; Mon, 1 Dec 2003 06:45:13 -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.10/8.12.9) with ESMTP id hB1Ej806006040 for ; Mon, 1 Dec 2003 15:45:08 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.10/8.12.1/Submit) id hB1Ej8Qi006039 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 15:45:08 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Removing Elgamal signatures Date: Mon, 1 Dec 2003 14:45:08 +0000 (UTC) Organization: IKS GmbH Jena Lines: 19 Message-ID: References: <873cc7uxjz.fsf@alberti.g10code.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1070289908 4051 217.17.192.37 (1 Dec 2003 14:45:08 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 1 Dec 2003 14:45:08 +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: > In the light of the recent GnuPG bug, where I accidently used the same > small sized k for signature creation as it is used for encrypting, I'd > very much like to drop the ElGamal signing ability all together from > OpenPGP. AFAIK, GnuPG is the only implementation with support for > these keys and by now the about 1100 known primary and subkeys should > have been revoked. Thus there won't be any interoperability problem > anymore. I'd like to oppose. ElGamal signatures are still useful, despite there is a charge of signatures with some algorithmic errors. I'd prefer a paragraph describing the problem and advicing to not use keys of this charge. > If we can't agree on that, I'd suggest to declare type 20 keys to be > Elgamal sign only - this way a new problem with this algorithm will > at least not affect the encryption use. It's only the parameter k, right? Type 20 keys are not limited to the small parameter. From owner-ietf-openpgp@mail.imc.org Mon Dec 1 12:14:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18240 for ; Mon, 1 Dec 2003 12:14:57 -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 hB1GlUib095887 for ; Mon, 1 Dec 2003 08:47:30 -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 hB1GlUmD095886 for ietf-openpgp-bks; Mon, 1 Dec 2003 08:47:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1GlTib095878 for ; Mon, 1 Dec 2003 08:47:29 -0800 (PST) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id hB1GkP808727 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 08:46:25 -0800 Date: Mon, 1 Dec 2003 08:46:25 -0800 From: "Hal Finney" Message-Id: <200312011646.hB1GkP808727@finney.org> To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to see some technical details about the attack, if they can be made available. The ElGamal signature formulas are: r = g^k mod p s = (H-rx)/k mod q The latter comes from rx+sk=H mod q. I gather from what Werner has said that choosing small x and k in this formula is unsafe. This looks similar to a lattice problem where there are relatively efficient articles for finding "small" vectors. But I am not that familiar with the mathematics. Incidentally, in trying to research this I found that the attack by Bleichenberger on poorly-chosen random numbers in DSA signatures had never been published. I'm not sure if that was a lattice based attack or not. It would be good to see these results made available because they might turn out to be applicable to other types of keys that we might consider in the future. Hal Finney From owner-ietf-openpgp@mail.imc.org Mon Dec 1 12:30:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18915 for ; Mon, 1 Dec 2003 12:30:04 -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 hB1GwEib096468 for ; Mon, 1 Dec 2003 08:58:14 -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 hB1GwEu6096460 for ietf-openpgp-bks; Mon, 1 Dec 2003 08:58:14 -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 hB1GwCib096442 for ; Mon, 1 Dec 2003 08:58:12 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hB1GwC304212 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 11:58:12 -0500 Date: Mon, 1 Dec 2003 11:58:12 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031201165812.GB3184@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <873cc7uxjz.fsf@alberti.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873cc7uxjz.fsf@alberti.g10code.de> 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 Gibbous (59% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Nov 29, 2003 at 02:14:08PM +0100, Werner Koch wrote: > In the light of the recent GnuPG bug, where I accidently used the same > small sized k for signature creation as it is used for encrypting, I'd > very much like to drop the ElGamal signing ability all together from > OpenPGP. AFAIK, GnuPG is the only implementation with support for > these keys and by now the about 1100 known primary and subkeys should > have been revoked. Thus there won't be any interoperability problem > anymore. I agree with this. Not too long ago, we removed a handful of unused hash algorithms from the standard using the "less is more" rationale. I see this as a similar case. David From owner-ietf-openpgp@mail.imc.org Mon Dec 1 12:54:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19933 for ; Mon, 1 Dec 2003 12:54:54 -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 hB1HVBib097900 for ; Mon, 1 Dec 2003 09:31: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 hB1HVBMe097899 for ietf-openpgp-bks; Mon, 1 Dec 2003 09:31:11 -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 hB1HVAib097894 for ; Mon, 1 Dec 2003 09:31:10 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hB1HVBl04480 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 12:31:11 -0500 Date: Mon, 1 Dec 2003 12:31:11 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031201173111.GA4304@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200312011646.hB1GkP808727@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312011646.hB1GkP808727@finney.org> 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 Gibbous (60% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Dec 01, 2003 at 08:46:25AM -0800, Hal Finney wrote: > It would be good to see these results made available because they might > turn out to be applicable to other types of keys that we might consider > in the future. The paper is as yet unpublished, but the author's web page with contact info is http://www.di.ens.fr/~pnguyen/ David From owner-ietf-openpgp@mail.imc.org Mon Dec 1 15:18:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26423 for ; Mon, 1 Dec 2003 15:18:10 -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 hB1JpEib004462 for ; Mon, 1 Dec 2003 11:51:14 -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 hB1JpEUB004461 for ietf-openpgp-bks; Mon, 1 Dec 2003 11:51:14 -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 hB1JpCib004455 for ; Mon, 1 Dec 2003 11:51:13 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id EA0CA69A94; Mon, 1 Dec 2003 14:51:13 -0500 (EST) Message-ID: <3FCB9B01.4967C080@systemics.com> Date: Mon, 01 Dec 2003 14:48:17 -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: Re: Removing Elgamal signatures References: <873cc7uxjz.fsf@alberti.g10code.de> 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 Lutz Donnerhacke wrote: > > * Werner Koch wrote: > > In the light of the recent GnuPG bug, where I accidently used the same > > small sized k for signature creation as it is used for encrypting, I'd > > very much like to drop the ElGamal signing ability all together from > > OpenPGP. AFAIK, GnuPG is the only implementation with support for > > these keys and by now the about 1100 known primary and subkeys should > > have been revoked. Thus there won't be any interoperability problem > > anymore. > > I'd like to oppose. ElGamal signatures are still useful, despite there is a > charge of signatures with some algorithmic errors. I'd prefer a paragraph > describing the problem and advicing to not use keys of this charge. Thinking about the case for removing ElGamal from the standard, here are the pluses that I see: a. The purpose of the standard is to document the greater good set of common and useful algorithms to which most implementation should try and implement. If there are O(1000) users of the ElGamal signature algorithm, I'd say at first glance this does not qualify as a major usage. Also, if GnuPG is the *only* implementation of this, then that would seem to go against the spirit of the "two implementations" rule. (Although, not breached in practice, as it is only a small part, I would guess.) b. Removing it from the standard would only mean that other implementations could then totally ignore it, instead of choosing to ignore it. Also, removing it from the standard does not mean it can't be used - it just means that it is then a private algorithm. If it later on proves to be of great use and other implementations adopt it, it can always be added back into a future version, or written into a informational draft. c. Some change has to be made, because there is a bug. So it might simply be a balance between removing it - easy? - and writing in the bug-fixed-text - not so easy? d. Less is much better. OpenPGP is already way too big and complex, which slows its implementation and thus slows its use, and its long term success. Against the removal: A. This is supposed to be very late in the game for the production of the standard. There should be very minor changes, if any. On balance, there seems to be a good case for removing it entirely! ( I speak here without any knowledge of the technical aspects of the algorithm, of course! Standard Dilbert comments apply... ) One thing I am not sure of - what is it useful for? In the sense, does it do something that is highly prized and wanted? That would perhaps be key in determining if removal is to be warranted at this late stage... iang From owner-ietf-openpgp@mail.imc.org Mon Dec 1 15:47:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28606 for ; Mon, 1 Dec 2003 15:47:31 -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 hB1KPdib005837 for ; Mon, 1 Dec 2003 12:25:39 -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 hB1KPdFH005836 for ietf-openpgp-bks; Mon, 1 Dec 2003 12:25:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com ([129.33.1.37]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KPbib005831 for ; Mon, 1 Dec 2003 12:25:38 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id PAA10782 for ; Mon, 1 Dec 2003 15:25:25 -0500 (EST) Message-ID: <3FCBA308.3090706@the-youngs.org> Date: Mon, 01 Dec 2003 15:22:32 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures References: <200312011646.hB1GkP808727@finney.org> In-Reply-To: <200312011646.hB1GkP808727@finney.org> 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 Hal Finney wrote: > It would be good to see these results made available because > they might turn out to be applicable to other types of keys > that we might consider in the future. While we're at it, I'd like the specification to include references to the research that was the rationalization for using a small "k" for encryption. Given that a full-width "k" is impractical (for cost reasons) and every implementation will be inclined to use a small "k", it's important that we make note of the security limitations. This is particularly true when they're based on the *relative* performance of known methods, which can change over time. [As I recall, the published PGP6 source code contained a comment with a reference. I don't have that handy, but perhaps someone here does.] From owner-ietf-openpgp@mail.imc.org Mon Dec 1 17:04:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04331 for ; Mon, 1 Dec 2003 17:04:00 -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 hB1Lcmib008264 for ; Mon, 1 Dec 2003 13:38:48 -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 hB1LcmZw008263 for ietf-openpgp-bks; Mon, 1 Dec 2003 13:38:48 -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 hB1Lclib008257 for ; Mon, 1 Dec 2003 13:38:47 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hB1LcmV06419 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 16:38:48 -0500 Date: Mon, 1 Dec 2003 16:38:48 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031201213848.GB4618@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <873cc7uxjz.fsf@alberti.g10code.de> <3FCB9B01.4967C080@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FCB9B01.4967C080@systemics.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 Waxing Gibbous (60% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Dec 01, 2003 at 02:48:17PM -0500, Ian Grigg wrote: > If there are O(1000) users of the ElGamal signature > algorithm, I'd say at first glance this does not qualify > as a major usage. > > Also, if GnuPG is the *only* implementation of this, > then that would seem to go against the spirit of the > "two implementations" rule. (Although, not breached > in practice, as it is only a small part, I would guess.) With regards to this point - very shortly, GnuPG will not be an implementation of this. The upcoming GnuPG (1.2.4) does not allow users to do anything with Elgamal sign+encrypt keys except revoke them. It will not encrypt to them, it will not sign with them. The next large release (1.4) will not implement Elgamal sign+encrypt at all. > One thing I am not sure of - what is it useful for? In the > sense, does it do something that is highly prized and wanted? In the past it was a patent-free signing algorithm that wasn't limited to a 1024 bit key and a 160 bit hash. Given that the RSA patent has expired, I see little benefit to Elgamal signatures that RSA signatures do not provide, and at the same time there are some significant advantages to RSA (like speed.) David From owner-ietf-openpgp@mail.imc.org Mon Dec 1 17:13:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05145 for ; Mon, 1 Dec 2003 17:13:28 -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 hB1Lv1ib008950 for ; Mon, 1 Dec 2003 13:57: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 hB1Lv1N2008949 for ietf-openpgp-bks; Mon, 1 Dec 2003 13:57: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 hB1Luxib008941 for ; Mon, 1 Dec 2003 13:57:00 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 04C3B69B29; Mon, 1 Dec 2003 16:57:01 -0500 (EST) Message-ID: <3FCBB87C.98B6371B@systemics.com> Date: Mon, 01 Dec 2003 16:54:04 -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: Re: Removing Elgamal signatures References: <873cc7uxjz.fsf@alberti.g10code.de> <3FCB9B01.4967C080@systemics.com> 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 Ian Grigg wrote: > > c. Some change has to be made, because there is a bug. Correction supplied by Micheal Young: > The bug is in the GnuPG implementation, not the specification. Thanks! Delete c. then. > [I'm neutral on whether to keep ElGamal signatures in the > specification, but I wouldn't consider this a compelling factor.] iang From owner-ietf-openpgp@mail.imc.org Tue Dec 2 00:28:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20957 for ; Tue, 2 Dec 2003 00:28:10 -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 hB255Iib027648 for ; Mon, 1 Dec 2003 21:05:18 -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 hB255IoT027647 for ietf-openpgp-bks; Mon, 1 Dec 2003 21:05:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB255Hib027642 for ; Mon, 1 Dec 2003 21:05:17 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 1 Dec 2003 21:05:15 -0800 Received: from callas.org ([63.73.97.181]) by bletchley.merrymeet.com (PGP Universal service); Mon, 01 Dec 2003 21:05:18 -0800 Date: Mon, 1 Dec 2003 21:05:28 -0800 Subject: Re: Removing Elgamal signatures Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Jon Callas To: OpenPGP Content-Transfer-Encoding: 7bit In-Reply-To: <873cc7uxjz.fsf@alberti.g10code.de> Message-Id: <256D894E-2485-11D8-8FA1-000A9568596C@callas.org> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm happy to remove it, if there's rough consensus that it be removed, myself. I just want to make sure that there is that consensus. Elgamal sigs have been controversial from the start. The main reason for them is to have a discrete-log public key system that parallels RSA in being able to both encrypt and sign. We've always known that Elgamal signatures were tetchy, and 2440 has finger-wagging in that direction, anyway. In 1998, there was more reason to have a discrete-log encrypt+sign key than there is in 2004. There's very little reason to have them today. Lutz has stated a preference for them remaining, but with exactly zero implementers of it, that sounds like something resembling rough consensus to remove them. If we *don't* remove them, then they are part of the standard, but an interesting part of the folklore. If a brand new implemented came to me and asked about them, I'd reply something like the following: "I don't see why you should implement them. They're a MAY, which means you don't have do. All signature algorithms are tetchy in that if you don't do them right, bad things can happen, but Elgamal sigs are even tetchier. The only people who did implement them removed them after some exasperating bugs showed up. If you implement them, then you have to make sure you don't put in some weird bug. If you do, people will say, 'I told you so.' If you do, anyone with a different implementation can't verify a signature -- you're the only one who does. I see a lot of bother for you and not much benefit. There are much better things for you to spend your time on." I then hear in my head, "So why didn't you remove them from 2440+ when you had the chance? If they're such a pain that no one does them, why are they there at all?" I don't have a good answer to that question. I say remove them, myself. Jon From owner-ietf-openpgp@mail.imc.org Thu Dec 4 18:14:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24446 for ; Thu, 4 Dec 2003 18:14:11 -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 hB4Mpbib030161 for ; Thu, 4 Dec 2003 14:51:37 -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 hB4Mpa72030160 for ietf-openpgp-bks; Thu, 4 Dec 2003 14:51:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4MpYib030143 for ; Thu, 4 Dec 2003 14:51:35 -0800 (PST) (envelope-from fw@deneb.enyo.de) Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp (Exim 4.24) id 1AS2K0-000116-TT; Thu, 04 Dec 2003 23:51:45 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.24) id 1AS2Jr-0001zd-BI; Thu, 04 Dec 2003 23:51:35 +0100 Date: Thu, 4 Dec 2003 23:51:35 +0100 To: Lutz Donnerhacke Cc: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031204225135.GA7248@deneb.enyo.de> References: <873cc7uxjz.fsf@alberti.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Florian Weimer Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz Donnerhacke wrote: > I'd like to oppose. ElGamal signatures are still useful, Useful for what? In the past, your primary argument seems to have been the avoidance of DSA (not because of patent problems, but because of rather theoretical objections to its design process), but this is no longer a convincing justification since we now have RSA at our disposal. > despite there is a charge of signatures with some algorithmic errors. > I'd prefer a paragraph describing the problem and advicing to not use > keys of this charge. Are you confident that no additional implementation traps will discovered? With RSA, I have some confidence that the most important things are properly documented, but ElGamal signatures appear to be much more problematic. Please keep in mind that this is the second case of such an implementation trap for the ElGamal signature scheme. From owner-ietf-openpgp@mail.imc.org Fri Dec 5 07:07:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02079 for ; Fri, 5 Dec 2003 07:07:36 -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 hB5Bngib035340 for ; Fri, 5 Dec 2003 03:49:42 -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 hB5Bng7J035339 for ietf-openpgp-bks; Fri, 5 Dec 2003 03:49:42 -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.10/8.12.8) with ESMTP id hB5Bndib035331 for ; Fri, 5 Dec 2003 03:49:40 -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.10/8.12.9) with ESMTP id hB5BnY5C008634 for ; Fri, 5 Dec 2003 12:49:34 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.10/8.12.1/Submit) id hB5BnY0x008633 for ietf-openpgp@imc.org; Fri, 5 Dec 2003 12:49:34 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Removing Elgamal signatures Date: Fri, 5 Dec 2003 11:49:34 +0000 (UTC) Organization: IKS GmbH Jena Lines: 21 Message-ID: References: <20031204225135.GA7248@deneb.enyo.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1070624974 7896 217.17.192.37 (5 Dec 2003 11:49:34 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Fri, 5 Dec 2003 11:49:34 +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: * Florian Weimer wrote: > Lutz Donnerhacke wrote: >> I'd like to oppose. ElGamal signatures are still useful, > > Useful for what? I prefer more than one algorithm for a given task. That's all. My personal opinion is not relevant to the removal of this packet type. > objections to its design process), but this is no longer a convincing > justification since we now have RSA at our disposal. Do we use RSA right? Requiring SSP? > Are you confident that no additional implementation traps will > discovered? With RSA, I have some confidence that the most important > things are properly documented, but ElGamal signatures appear to be much > more problematic. Please keep in mind that this is the second case of > such an implementation trap for the ElGamal signature scheme. There are a lot of listed RSA attacks, too. From owner-ietf-openpgp@mail.imc.org Tue Dec 9 14:00:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07841 for ; Tue, 9 Dec 2003 14:00:13 -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 hB9Ie0ib014882 for ; Tue, 9 Dec 2003 10:40:00 -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 hB9Ie06e014881 for ietf-openpgp-bks; Tue, 9 Dec 2003 10:40:00 -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 hB9Iduib014869 for ; Tue, 9 Dec 2003 10:39:57 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id AACC469B2C; Tue, 9 Dec 2003 13:39:52 -0500 (EST) Message-ID: <3FD6164C.BD573813@systemics.com> Date: Tue, 09 Dec 2003 13:37:00 -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: armour pierced with PGP 8 arrow 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 It appears that PGP 8 is breaking the spirit and intent of the ascii armouring format, if not the "letter of the law." What it is doing is in essence putting in a Version that is too long for some mailers' line slicing paramaters. The result is that people receive this: -----BEGIN PGP MESSAGE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm ... -----END PGP MESSAGE----- Now, reading from the 28th October 2003 draft, it appears that there is no comment on line length - but there are comments on the line sanctity and on UTF-8 in the Comment field that are apropos. To cut the gordian knot, I propose: 1. changing the comment at the end of p49 to include a warning on line length: ... The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text following them on the same line (BEWARE OF USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS). (addition in caps...) (as a suggestion only). 2. moving the "Comment" comment out of that section and/or expanding it to include a comment about long lines. Something like: Armor Header contents are not strictly defined, so may include UTF-8 strings and long lines. However, the point of Armoring is to provide a clean textual representation that survives transport over pernickety systems such as email. Consequently, if an Armor Header includes such things as characters outside the range of US-ASCII or too many characters, the Armored message may not survive transport. (At the bottom of page 50.) (because it seems to apply equally to all armoured headers). 3. It also seemed plausible to put in "rule of thumb" that the line length of headers should be no longer than the ascii armoured body line length. I'm not wedded to any of those, just thinking out aloud some thoughts on improving the ID so it best serves. iang PS: To compound this, it appears that GPG (1.2.2) is also rejecting these messages out of hand. It would appear that GPG is in the right here, as there is this strict rule: "OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. ..." (top of page 50). From owner-ietf-openpgp@mail.imc.org Tue Dec 9 20:37:25 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27957 for ; Tue, 9 Dec 2003 20:37:25 -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 hBA14uib031217 for ; Tue, 9 Dec 2003 17:04: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 hBA14uDi031216 for ietf-openpgp-bks; Tue, 9 Dec 2003 17:04:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cyphers.net (rc6.cyphers.net [64.220.173.136]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA14sib031205 for ; Tue, 9 Dec 2003 17:04:54 -0800 (PST) (envelope-from wprice@cyphers.net) Received: from keys.cyphers.net (account wprice [64.220.173.170] verified) by cyphers.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1393744 for ietf-openpgp@imc.org; Tue, 09 Dec 2003 17:04:57 -0800 Received: from cypher.pgp.com ([63.251.255.202]) by keys.cyphers.net (PGP Universal service); Tue, 09 Dec 2003 17:04:56 -0800 Received: from [63.251.255.202] by cypher.pgp.com (PGP Universal service); Tue, 09 Dec 2003 17:04:56 -0800 X-PGP-Universal: processed Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FD6164C.BD573813@systemics.com> References: <3FD6164C.BD573813@systemics.com> Message-Id: From: Will Price Subject: Re: armour pierced with PGP 8 arrow Date: Tue, 9 Dec 2003 17:04:48 -0800 To: ietf-openpgp@imc.org X-Mailer: Apple Mail (2.606) Content-Type: text/plain; format=flowed; 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see no problem here and no need for any change to the draft or a product. 66 columns is at least 10 columns shorter than any conventional recommended line length. If your mailer wrapped that line, it would be almost equally likely to wrap the ASCII armor itself (65 columns -- 11 less than the OpenPGP limit). In addition, your claims are patently contrary to the exact words and spirit of the draft. Please see section 6.3 where it says: "The encoded output stream must be represented in lines of no more than 76 characters each." Thus, whatever the problem you are seeing is, and based on observing the line length used in your own message on this topic, it appears to be related specifically to a low limit somewhere in your configuration, it is not a fault of PGP nor the OpenPGP draft. - - Will On Dec 9, 2003, at 10:37 AM, Ian Grigg wrote: > It appears that PGP 8 is breaking the spirit and intent > of the ascii armouring format, if not the "letter of the > law." > > What it is doing is in essence putting in a Version that > is too long for some mailers' line slicing paramaters. > The result is that people receive this: > > > > > -----BEGIN PGP MESSAGE----- > Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com > > qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm > ... > -----END PGP MESSAGE----- > > > > Now, reading from the 28th October 2003 draft, it appears > that there is no comment on line length - but there are > comments on the line sanctity and on UTF-8 in the Comment > field that are apropos. > > To cut the gordian knot, I propose: > > > 1. changing the comment at the end of p49 to > include a warning on line length: > > ... The > header lines, therefore, MUST start at the beginning of a line, and > MUST NOT have text following them on the same line (BEWARE OF > USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS). > > (addition in caps...) (as a suggestion only). > > > 2. moving the "Comment" comment out of that > section and/or expanding it to include a > comment about long lines. Something like: > > > Armor Header contents are not strictly defined, so may > include UTF-8 strings and long lines. > > However, the point of Armoring is to provide a clean > textual representation that survives transport over > pernickety systems such as email. Consequently, if an > Armor Header includes such things as characters outside > the range of US-ASCII or too many characters, the Armored > message may not survive transport. > > > (At the bottom of page 50.) (because it seems > to apply equally to all armoured headers). > > > 3. It also seemed plausible to put in > "rule of thumb" that the line length > of headers should be no longer than > the ascii armoured body line length. > > > I'm not wedded to any of those, just > thinking out aloud some thoughts on > improving the ID so it best serves. > > iang > > > PS: To compound this, it appears that GPG > (1.2.2) is also rejecting these messages > out of hand. It would appear that GPG is > in the right here, as there is this strict > rule: > > "OpenPGP should consider improperly formatted Armor Headers to be > corruption of the ASCII Armor. ..." > > (top of page 50). > - -- Will Price, VP Engineering PGP Corporation -----BEGIN PGP SIGNATURE----- Version: PGP Universal Satellite 1.1.0 (Build 411) iQA/AwUBP9ZxOKy7FkvPc+xMEQLL6wCg32HE6JlNzuvWscDLSWB6uFiY2IgAn2Bz QKDr+Pe9H5LUQTrGbbkHpzvf =aof8 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Dec 9 22:20:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00078 for ; Tue, 9 Dec 2003 22:20:10 -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 hBA2lvib034671 for ; Tue, 9 Dec 2003 18:47: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 hBA2lvKZ034670 for ietf-openpgp-bks; Tue, 9 Dec 2003 18:47:57 -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 hBA2luib034665 for ; Tue, 9 Dec 2003 18:47:57 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 0DF4B69A7C; Tue, 9 Dec 2003 21:47:59 -0500 (EST) Message-ID: <3FD688B2.77248B40@systemics.com> Date: Tue, 09 Dec 2003 21:45:06 -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: Will Price Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <3FD6164C.BD573813@systemics.com> 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 Will Price wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I see no problem here and no need for any change to the draft or a > product. 66 columns is at least 10 columns shorter than any > conventional recommended line length. If your mailer wrapped that line, > it would be almost equally likely to wrap the ASCII armor itself (65 > columns -- 11 less than the OpenPGP limit). I've observed this problem many times, myself, but it didn't occur in this recent case. > In addition, your claims are patently contrary to the exact words and > spirit of the draft. Please see section 6.3 where it says: "The encoded > output stream must be represented in lines of no more than 76 > characters each." You are correct, I did not see that part, so it would appear that PGP 8 is within the letter of the draft. > Thus, whatever the problem you are seeing is, and based on observing > the line length used in your own message on this topic, it appears to > be related specifically to a low limit somewhere in your configuration, > it is not a fault of PGP nor the OpenPGP draft. This behaviour was observed with ordinary people out there with ordinary mailers, not my own (which is set to not slice lines at all). That is, users failed to communicate because their mailers sliced the lines. I make no comment on whether any particular product should change, rather, I was suggesting that there be attention brought to the line length issue within the draft. As line length in mailers is a moving target, one can only be general and flexible. As an aside, in the ascii armoured messages that my company produces, we used to use the same or a similar number as various other products (I guess that would be about 65), but dropped it down to 48 about 2 years back because of continual problem with mailers. That's just an old observation, to match the new one I've just seen in users' setups - if nobody else has seen those problems then there isn't an issue. I don't imagine that two data points are representative. iang From owner-ietf-openpgp@mail.imc.org Wed Dec 10 02:08:11 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12572 for ; Wed, 10 Dec 2003 02:08:11 -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 hBA6lEib061851 for ; Tue, 9 Dec 2003 22:47:14 -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 hBA6lEdR061850 for ietf-openpgp-bks; Tue, 9 Dec 2003 22:47:14 -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.10/8.12.8) with ESMTP id hBA6l8ib061786 for ; Tue, 9 Dec 2003 22:47:13 -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 9698334015; Wed, 10 Dec 2003 19:46:39 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBA6lAE28729; Wed, 10 Dec 2003 19:47:10 +1300 Date: Wed, 10 Dec 2003 19:47:10 +1300 Message-Id: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: iang@systemics.com Subject: Re: armour pierced with PGP 8 arrow Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian Grigg writes: >It appears that PGP 8 is breaking the spirit and intent of the ascii >armouring format, if not the "letter of the law." > >What it is doing is in essence putting in a Version that is too long for some >mailers' line slicing paramaters. The result is that people receive this: > >Version: PGP 8.0.2 - not licensed for commercial use: >www.pgp.com Is it really a line-length issue, or something else like the presence of the second colon in the line for something that's scanning for :? For a mailer to be unable to handle a 66-char line sounds pretty... broken. Peter. From owner-ietf-openpgp@mail.imc.org Wed Dec 10 14:06:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20170 for ; Wed, 10 Dec 2003 12:34:58 -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 hBAH9Uib049534 for ; Wed, 10 Dec 2003 09:09:30 -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 hBAH9UFW049533 for ietf-openpgp-bks; Wed, 10 Dec 2003 09:09:30 -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 hBAH9Sib049527 for ; Wed, 10 Dec 2003 09:09:29 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id B1CCB69A84; Wed, 10 Dec 2003 12:09:29 -0500 (EST) Message-ID: <3FD7529D.B2EEAF25@systemics.com> Date: Wed, 10 Dec 2003 12:06:37 -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: Peter Gutmann Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> 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 Peter Gutmann wrote: > > Ian Grigg writes: > > >It appears that PGP 8 is breaking the spirit and intent of the ascii > >armouring format, if not the "letter of the law." > > > >What it is doing is in essence putting in a Version that is too long for some > >mailers' line slicing paramaters. The result is that people receive this: > > > >Version: PGP 8.0.2 - not licensed for commercial use: > >www.pgp.com > > Is it really a line-length issue, or something else like the presence of the > second colon in the line for something that's scanning for :? Well, the slicing that is occuring is in the transmission process, in this case, so I am theorising that this is a line length issue. (I haven't been able to check this, because the person sending the dodgy email doesn't understand what I am asking... That's the way it is in userland.) But you raise a point I hadn't seen, the line above is badly formatted in a second way, in that it includes two ": " separators. Examination of the para in section 6.2, page 50: The format of an Armor Header is that of a key-value pair. A colon (':' 0x38) and a single space (0x20) separate the key and value. OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but OpenPGP should continue to process the message. indicates that this is not explicitly ruled against, but I'd say it is implicit stated that only one separator is permitted. Or, in the alternate, if two separators are permitted, then the text should be clarified, as different parsing strategies will result in confusion. Should there be only one ": " or are additionals permitted in the value and thereafter ignored? As the ID says "OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor," I suggest this be explicitly clarified to improve interworkability. > For a mailer to be unable to handle a 66-char line sounds pretty... broken. My view is that when it comes to lines, all mailers seem broken. But what do I know? Mostly, this seems to occur when going from one distinct community to another. Within a particular flavour of mailers, they all understand each other, but across distinct communities, the mailers have different ways of dealing with things. I did a quick straw poll today, and found 76,72,76,58,72,56,72,72 A few points: * In communities where they always reply with full interpolation, and full (audit) chains of replies, sometimes people set the width to be very narrow, because they end up with scores (i.e., 20) series of replies, which scan across to the right hand columns. * from the *same* email, 50-72! Which makes me think that this guy had his mailer set up for proportional text. Another couple of emails I wasn't able to work out what was going on, but inserted lines seemed to be part of the bug set. * I've just noticed another thing about the community stuff - Macs tend to interpret a trailing space as a continuation character, and that sometimes works and sometimes doesn't (I suppose it always works on Macs). * If you look at my original mail, you will see that the sliced line I presented was broken, but in Will Price's reply, it had been repaired, presumably by his mailer, so in his view, there was apparently nothing wrong! iang From owner-ietf-openpgp@mail.imc.org Thu Dec 11 12:40:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11582 for ; Thu, 11 Dec 2003 12:40:57 -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 hBBHKEib085668 for ; Thu, 11 Dec 2003 09:20:14 -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 hBBHKEca085667 for ietf-openpgp-bks; Thu, 11 Dec 2003 09:20:14 -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 hBBHKBib085659 for ; Thu, 11 Dec 2003 09:20:11 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id C3F3269B2D; Thu, 11 Dec 2003 12:20:11 -0500 (EST) Message-ID: <3FD8A6A0.B609DDEB@systemics.com> Date: Thu, 11 Dec 2003 12:17:20 -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: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> 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 Ian Grigg wrote: > > Peter Gutmann wrote: > > Is it really a line-length issue, or something else like the presence of the > > second colon in the line for something that's scanning for :? Peter brought up the issue of the additional ": " separators and I opined that the draft should be clearer on this issue. On reflection, I think it should not be permitted. The reason for this is that when you combine it with the line slicing behaviour, then some games are possible: Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial Could result in an embarressing split. Now, that's a superficial and ignorable result, and only presented for the sake of showing what might happen. I can see no good reason to leave multiple separators as permitted in the ID, so I'd suggest adding a simple restriction such as "Only one separator is permitted." As another observation, the use of the term "Armour Headers" appears overloaded. Could this be clarified by changing the current usage into: Armour Headers: -----.*PGP.*----- Optional Headers: Version: //// Or even Comment Headers, or Optional Armour Headers, or Optional Comments? iang From owner-ietf-openpgp@mail.imc.org Thu Dec 11 13:31:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13245 for ; Thu, 11 Dec 2003 13:31:31 -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 hBBI5oib087543 for ; Thu, 11 Dec 2003 10:05:50 -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 hBBI5nRa087542 for ietf-openpgp-bks; Thu, 11 Dec 2003 10:05:49 -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 hBBI5mib087530 for ; Thu, 11 Dec 2003 10:05:48 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hBBI42a16928 for ietf-openpgp@imc.org; Thu, 11 Dec 2003 13:04:02 -0500 Date: Thu, 11 Dec 2003 13:04:02 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow Message-ID: <20031211180402.GA16475@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FD8A6A0.B609DDEB@systemics.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 (93% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Dec 11, 2003 at 12:17:20PM -0500, Ian Grigg wrote: > > Ian Grigg wrote: > > > > Peter Gutmann wrote: > > > > Is it really a line-length issue, or something else like the > > > presence of the second colon in the line for something that's > > > scanning for :? > > Peter brought up the issue of the additional > ": " separators and I opined that the draft > should be clearer on this issue. > > On reflection, I think it should not be permitted. > > The reason for this is that when you combine > it with the line slicing behaviour, then some > games are possible: > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > > Could result in an embarressing split. Now, that's a superficial > and ignorable result, and only presented for the sake of showing > what might happen. > > I can see no good reason to leave multiple separators as permitted > in the ID, so I'd suggest adding a simple restriction such as "Only > one separator is permitted." I disagree we need to change anything here. There is already only one separator permitted. Using your example: Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial The second instance of colon-space is NOT a separator. It's just part of the value. This isn't very complicated. I'd be quite surprised to hear of any parser that didn't do: a) Find the leftmost colon-space. b) The string to the left is the key. c) The string to the right is the value. That's how email works (note the subject line of this message has two colons!), how news works, and how OpenPGP works. David From owner-ietf-openpgp@mail.imc.org Thu Dec 11 14:37:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16652 for ; Thu, 11 Dec 2003 14:37:33 -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 hBBJ4Lib089716 for ; Thu, 11 Dec 2003 11:04:21 -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 hBBJ4LS9089715 for ietf-openpgp-bks; Thu, 11 Dec 2003 11:04:21 -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 hBBJ4Kib089710 for ; Thu, 11 Dec 2003 11:04:20 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 6E8CE69B35; Thu, 11 Dec 2003 14:04:21 -0500 (EST) Message-ID: <3FD8BF09.551E6238@systemics.com> Date: Thu, 11 Dec 2003 14:01:29 -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: David Shaw Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> 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 David Shaw wrote: ... Sorry, I should have spelt this out: > > On reflection, I think it should not be permitted. > > > > The reason for this is that when you combine > > it with the line slicing behaviour, then some > > games are possible: > > > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > > > > > Could result in an embarressing split. Such as: Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial When the line slicing behaviour is set to (about) column 42. > This isn't very complicated. I'd be quite surprised to hear of any > parser that didn't do: > > a) Find the leftmost colon-space. > b) The string to the left is the key. > c) The string to the right is the value. How do parsers handle the above case? Not that it's important. The thing to realise here is that the additional separator's presence, coupled with the ability of line slicing by mailers, introduces an exceptional case that's simply better off made illegal. The spirit of ascii armouring is to get the message through in the face of aggressive and unpredictable actions of many users' mailers. In this case, I think this spirit is preserved by making the optional Armor Headings as simple as possible, and encouraging strict legality. iang PS: actually, the above case is "legal". If there was no separator in the second split line, then the armouring is broken ("OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor."), and the message should not be accepted. But that's hardly a reliable strategy. From owner-ietf-openpgp@mail.imc.org Fri Dec 12 00:18:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12134 for ; Fri, 12 Dec 2003 00:18:28 -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 hBC4uLib010319 for ; Thu, 11 Dec 2003 20:56:21 -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 hBC4uLrb010318 for ietf-openpgp-bks; Thu, 11 Dec 2003 20:56:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from crustytoothpaste.ath.cx (cs2416783-242.houston.rr.com [24.167.83.242]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4uKib010312 for ; Thu, 11 Dec 2003 20:56:20 -0800 (PST) (envelope-from karlsson@hal-pc.org) Received: from stonewall (unknown [192.168.2.2]) by crustytoothpaste.ath.cx (Postfix) with SMTP id 9B3F17BC29; Fri, 12 Dec 2003 04:56:22 +0000 (UTC) Received: by stonewall (sSMTP sendmail emulation); Fri, 12 Dec 2003 04:56:22 +0000 Date: Fri, 12 Dec 2003 04:56:22 +0000 From: karlsson@hal-pc.org To: Ian Grigg Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow Message-ID: <20031212045622.GU15000@stonewall> References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> <3FD8BF09.551E6238@systemics.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="YG0IFkGWIt6MbjRk" Content-Disposition: inline In-Reply-To: <3FD8BF09.551E6238@systemics.com> X-Operating-System: Linux stonewall.crustytoothpaste.ath.cx 2.6.0-test7-1-386 Content-Conversion: prohibited X-Request-PGP: finger://bmc@crustytoothpaste.ath.cx User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --YG0IFkGWIt6MbjRk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote: >=20 > Such as: >=20 > Version: 1.0.0 non-commercial, upgrade to > Version: 2.0.0-commercial >=20 > When the line slicing behaviour is set to (about) column 42. If I have to set my line width to 42, your mail system is so broken that I don't need to talk to it. 72 is reasonable, and and one should=20 expect lines exceeding 80 characters to be wrapped. Anything under 68 is unreasonably small. I, for example, am using 72 character lines in my editor (vim). > > This isn't very complicated. I'd be quite surprised to hear of any > > parser that didn't do: > >=20 > > a) Find the leftmost colon-space. > > b) The string to the left is the key. > > c) The string to the right is the value. >=20 >=20 > How do parsers handle the above case? Not that it's Do a) with strchr(3) or memchr(3) by finding a colon and then check that the next character is a space. If it's not, abort the message. The code is: if (!(ptr=3D(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=3D' ') exit(1); > important. --=20 Brian M. Carlson 0x560553e7 --YG0IFkGWIt6MbjRk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Ubi libertas, ibi patria. iQEVAwUBP9lKduWR/8lWBVPnAQOEpAf+JDlWsc87iZgzpngGQmrtaMr4+u4ihudz zAP2TK5mf0jTk2lCnoh9EoFgRJJwgIOTx9JpZEbudwx/2wZtFM8Y/WyAOehU3LNo TnXlHS+I4Tv/88dEaVm8gyhhpeeVHe6Rq6AV1mD7IXtnKsOw1eFh7mQ8RVUUu0Vl YgYWzKSw+5KM6H35ifxbXV5GvkeSrlzB6c7ZlfcZTQWt47K22mNRgXeTGMeVURWg srab8zkin8qWWXeVL/vCM27zR0KJWY5jZ0UTerctw70qFDp+5WZ+hLWPA694Fico m8eU5RgQomKaszh1YbSCVG/GwVC77PJMNItQb0EV1unhZIyBTdpo2Q== =yJWd -----END PGP SIGNATURE----- --YG0IFkGWIt6MbjRk-- From owner-ietf-openpgp@mail.imc.org Fri Dec 12 11:20:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14777 for ; Fri, 12 Dec 2003 11:20:47 -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 hBCFkcib011192 for ; Fri, 12 Dec 2003 07:46:38 -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 hBCFkcQU011191 for ietf-openpgp-bks; Fri, 12 Dec 2003 07:46:38 -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 hBCFkaib011182 for ; Fri, 12 Dec 2003 07:46:36 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 2C0C969B42; Fri, 12 Dec 2003 10:46:37 -0500 (EST) Message-ID: <3FD9E232.3FF8215A@systemics.com> Date: Fri, 12 Dec 2003 10:43:46 -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: karlsson@hal-pc.org Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> <3FD8BF09.551E6238@systemics.com> <20031212045622.GU15000@stonewall> 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 karlsson@hal-pc.org wrote: > > On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote: > > > > Such as: > > > > Version: 1.0.0 non-commercial, upgrade to > > Version: 2.0.0-commercial > > > > When the line slicing behaviour is set to (about) column 42. > > If I have to set my line width to 42, your mail system is so broken > that I don't need to talk to it. 72 is reasonable, and and one should > expect lines exceeding 80 characters to be wrapped. Anything under 68 is > unreasonably small. I, for example, am using 72 character lines in my > editor (vim). It does appear to be the consensus that there is no need or desire to change the ID on this issue. However, I'm not seeing a lot of real consideration of the real points here. So I'm unclear here whether to keep kicking this dying horse, or perhaps Derik could rule on closing it? ? I disagree with the above logic on the following grounds: OpenPGP is not only used for mail, and in fact takes great care to be more universally useful (scan the ID for the word "mail", I just did!). We here should also strive to move from the particular to the general, when looking at examples, and back again. Security standards are not built on such considerations of "yours is broken because I don't like your numbers." Bad software is certainly built with those sorts of criteria, but bad software is not what we are about here. This is about security, so detail is important. The offending number chosen was related to the example; the point remains with an example of a different number. You pick. Notwithstanding many peoples' desires to impose their views of how mail works on the rest of the world, there are other mail considerations in the future: PDAs and phones have smaller screens, for example. Web mailers and hush-style mailers can be very unkind to formatters. Chat is replacing email.... the list goes on - if OpenPGP is to be based on the email view of the past, then, we should all stop work on it right now. The greatest success comes when multiple competing implementations communicate with ease, and without games. Here we have a case where it is apparently easy to legally create a correct message that gets turned into a recipient message of indeterminate legality by transport. Fixing this costs nobody much at all [1]. > if (!(ptr=(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=' ') > exit(1); Please make sure you read the entire example. That doesn't decide which line of the two lines in the previous text, post-slicing, goes on to become the dominating one. The game to play in security programming is to see if a) we can confuse the other party, and b) we can create a security breach out of a confusion. We've shown a). I grant b) is a little harder, as optional headers aren't supposed to be "used" for such things. But, who knows what adventurous souls have in their minds for the future... [2] iang [1] I just thought late last night how to breach b)... Imagine you are a company selling a device that filters on the headers. Imagine that you make commercial decisions on the basis of those headers. (Because that's all you can read.) Then, an enterprising young chap realises that all he has to do is to slice the headers, and they are still human-readable, but they bypass the filtering of the proxy that handles incoming messages. marketing reference: NY AG v. WS == 1.3 bn. [2] the guys over at PGP Inc might want to rewrite their comment to be a bit shorter than the ASCII- Armoured data lines - rule of thumb - and to change the extra ": " to some other symbol. If they haven't already done these steps, I'd be very surprised! Also, they should reject sliced headers, or suggest we change the ID on that point. But, no real cost. GPG might want to detect and warn that the headers appear corrupted and can be fixed easily with an editor, rather than silently bailing on ID strictness. From owner-ietf-openpgp@mail.imc.org Fri Dec 12 13:05:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18438 for ; Fri, 12 Dec 2003 13:05:14 -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 hBCHinib016477 for ; Fri, 12 Dec 2003 09:44: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 hBCHinOw016476 for ietf-openpgp-bks; Fri, 12 Dec 2003 09:44:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHimib016471 for ; Fri, 12 Dec 2003 09:44:48 -0800 (PST) (envelope-from konrad@silmor.de) Received: from fwd01.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1AUrLM-0002Oe-03; Fri, 12 Dec 2003 18:44:48 +0100 Received: from arthur.local (VToPSqZd8edUziKuz2XyPAS7HLDQs758b4S4w8-NgSOvfmFa+V5G4M@[217.235.57.62]) by fmrl01.sul.t-online.com with esmtp id 1AUrL4-14hjZA0; Fri, 12 Dec 2003 18:44:30 +0100 Received: from zaphod.local ([192.168.1.5]) by arthur.local with esmtp (Exim 3.35 #1 (Debian)) id 1AUrL4-0001dn-00 for ; Fri, 12 Dec 2003 18:44:30 +0100 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow Date: Fri, 12 Dec 2003 18:44:26 +0100 User-Agent: KMail/1.5.4 References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> In-Reply-To: <20031211180402.GA16475@jabberwocky.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_95f2/hnr1WRFCZF"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200312121844.29829.konrad@silmor.de> X-Seen: false X-ID: VToPSqZd8edUziKuz2XyPAS7HLDQs758b4S4w8-NgSOvfmFa+V5G4M@t-dialin.net Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_95f2/hnr1WRFCZF Content-Type: text/plain; charset="iso-8859-1" Content-Description: signed data Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thursday 11 December 2003 19:04, David Shaw wrote: > I disagree we need to change anything here. There is already only one > separator permitted. Using your example: > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > The second instance of colon-space is NOT a separator. It's just part > of the value. As long as the line is not split, you are correct. > This isn't very complicated. I'd be quite surprised to hear of any > parser that didn't do: > > a) Find the leftmost colon-space. > b) The string to the left is the key. > c) The string to the right is the value. > > That's how email works (note the subject line of this message has two > colons!), how news works, and how OpenPGP works. With one notable difference: in the case any MTA splits headerlines, it wil= l=20 add space(s) in front of the next line, which is defined to continue the li= ne=20 in RFC822. When a MUA or MTA splits body lines it will not add anything=20 (maybe except for some ">" characters). So the receiving system will not be= =20 able to tell the difference between a new header line an a continuation. I'm a newbie to implementing OpenPGP - so please forgive me, if my question= is=20 stupid: why consider the additional headers at all? They seem to me to only= =20 have any value to human readers and none at all to OpenPGP itself, since al= l=20 important information is already encoded into the binary message blocks (on= ce=20 you got them out of their armor). Is there any technical reason for the RFC= =20 not saying "Implementations shall ignore header lines."? Konrad --Boundary-02=_95f2/hnr1WRFCZF Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD4DBQA/2f59m6pO7A9GSMQRAn46AJdZXsgMN2AAI71IBy2fik8jxiffAKC/nH2L hL0qpnCPKTeRIqblk5Mh8A== =Uy1j -----END PGP SIGNATURE----- --Boundary-02=_95f2/hnr1WRFCZF-- From owner-ietf-openpgp@mail.imc.org Fri Dec 12 16:01:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26397 for ; Fri, 12 Dec 2003 16:01:25 -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 hBCKfiib022612 for ; Fri, 12 Dec 2003 12:41:44 -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 hBCKfikL022611 for ietf-openpgp-bks; Fri, 12 Dec 2003 12:41:44 -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 hBCKfhib022605 for ; Fri, 12 Dec 2003 12:41:43 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 8DC7C69A85; Fri, 12 Dec 2003 15:41:44 -0500 (EST) Message-ID: <3FDA275D.5478DEB2@systemics.com> Date: Fri, 12 Dec 2003 15:38:53 -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: Konrad Rosenbaum Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> <200312121844.29829.konrad@silmor.de> 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 Konrad Rosenbaum wrote: > > On Thursday 11 December 2003 19:04, David Shaw wrote: > > I disagree we need to change anything here. There is already only one > > separator permitted. Using your example: > > > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > > > The second instance of colon-space is NOT a separator. It's just part > > of the value. > > As long as the line is not split, you are correct. Knowing how coders make different assumptions, and have different scanning tools available to them, even this could cause some surprises. For e.g., in list based languages, popping is more natural than parsing left-to-right. Here's some perl: perl -e ' $x = "Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial"; @a = (split(": ", $x)); $_ = shift(@a); print "$_\n"; /Version/ && print pop(@a), "\n"; ' ... > I'm a newbie to implementing OpenPGP - so please forgive me, if my question is > stupid: why consider the additional headers at all? They seem to me to only > have any value to human readers and none at all to OpenPGP itself, since all > important information is already encoded into the binary message blocks (once > you got them out of their armor). Is there any technical reason for the RFC > not saying "Implementations shall ignore header lines."? This is meta-part of the issue. Currently, the ID says: "OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor." I wonder whether that is too strong. It seems reasonable to say that implementations may attempt to parse beyond and ignore improperly formatted headers. Perhaps with warnings. As we have not gone to any great extent to define why the optional ascii armour headers are important, it seems odd to treat them as if they are important enough to be capable of breaking the armoured message. iang From owner-ietf-openpgp@mail.imc.org Mon Dec 22 06:03:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10825 for ; Mon, 22 Dec 2003 06:03: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 hBMAcbib045055 for ; Mon, 22 Dec 2003 02:38:37 -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 hBMAcbUD045054 for ietf-openpgp-bks; Mon, 22 Dec 2003 02:38:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMAcXib045046 for ; Mon, 22 Dec 2003 02:38:36 -0800 (PST) (envelope-from aboietf@redtenbacher.de) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AYNSJ-0003W3-00 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 11:38:31 +0100 Received: from [62.134.100.38] (helo=62.134.100.38) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AYNSH-0005q8-00 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 11:38:30 +0100 Subject: Valid OpenPGP keys without self-signature? To: ietf-openpgp@imc.org From: aboietf@redtenbacher.de Message-Id: Date: Mon, 22 Dec 2003 11:38:30 +0100 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e384712ef1f129ade61e87b26279bda6 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: During OpenPGP interoperability tests, I have recently come across an unusual situation: The German company "Robert Bosch GmbH" introduced a PKI on the basis of a product called "Secure e-mail iT_SEC_outlook". This product uses old-style V3 RSA keys that are created by the "trust center" of the company for every user and are signed on creation by the trust center key. The unusual aspect now is that only the "trust center key" has a self-signature. All normal user keys have no self-signature but only the trust center signature on them. (I have added the trust center key and one user key at the end of this message to show what I mean.) My questions now are: (1) Are such keys a security problem? (A key without any signature on it would be open to manipulation, of course, but the company claims that their trust center signature protects the exact same key contents that a self-signature would protect. And according to RFC 2440, this really seems to be the case.) (2) Is such a key conforming to the OpenPGP spec (or at least interoperable with a conforming OpenPGP product)? (I re-read the spec yesterday and could not find any obvious violation although such a key loses lots of features because aspects like "Key expiration time", "Preferred symmectric algorithms", "Preferred hash algorithms", "Preferred compression algorithms", "Key server preferences" and the "Primary user id" flag all reside in the self-signature that is missing here.) (3) Which OpenPGP products support such unusual public keys? (In my tests, PGP 5.x imported the user key without any error message, whereas GnuPG 1.2.x refused to import the key even in "--expert" mode. And a PGP 8.02 user reported to me that PGP 8.02 also refuses to import any keys without self-signature.) As I either have to find a solution to this interoperability problem or have to prove to the company that their setup is insecure, I would be very happy about any answers to the above questions. - Wolfgang Redtenbacher --------------------------------------------------------------------- Redtenbacher Software Tel.: +49 7159 17046 Roemerstr. 11/1 Fax: +49 7159 17047 D-71272 Renningen e-mail: wolfgang@redtenbacher.de --------------------------------------------------------------------- The following is the trust center key of the company: Rb.Trustcenter@bosch.com Rb.Trustcenter@de.bosch.com Rb.Trustcenter@pcm.bosch.de -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Secure e-mail iT_SEC_outlook V2.0.2 Comment: mI8DNTPcYAqAAQQApTiBHFV+5Y0MAOeO/brDX86hcZKkrKsOURPLR0sjI8tSeYML pTkq8W+U9qPkVXQW39vXxLH7ztMDYL2MXfmAFeMbVxLg72ibpyy/YRB7tjRRR5vp aJZILLM2p35eqESt7TeLNrECCbH4NywYBR2EeEMLyJ0K7Rkatt/sC4Spl30AEQEA AbQ0VHJ1c3RjZW50ZXIgUkIgKFNUL1ZTQzMyKSA8UmIuVHJ1c3RjZW50ZXJAYm9z Y2guY29tPoiVAwUQP+AhV7bf7AuEqZd9AQFhGQP/Qk/P4KewVRGtUASplhbEiIr8 C6v26vToWQcnNPryINr4T3vhd9knjXoydBB4DAUgE/LcwGHI0pFR6kY/wvqWRdgY mI7UCVuOOz3xftQjJGAR9mw9Bh/1icUB48ayjrYSqUPxH+5DuWdfIXnCjBheRSlK yJ8S630SoARgiUkx+Oa0N1RydXN0Y2VudGVyIFJCIChTVC9WU0MzMikgPFJiLlRy dXN0Y2VudGVyQGRlLmJvc2NoLmNvbT6IlQMFED/gIVe23+wLhKmXfQEB8zoD/RQn qp7pGsx8LIm2DMxTazkpJ/+bKOmn78Yw/I0YaBjpZHdrRDQ0YGIem4vQDcdRnzXo +z1kXh9F3uGtvtZMbSDHCkY8GQ5hZzJhY2F7xIo4Xyh/+KNyOAPTmr6b4Zrnj5JJ MBqTeXWfjvYaG56NI5fBXMILeIl71SJfK0KgspAWtDdUcnVzdGNlbnRlciBSQiAo U1QvVlNDMzIpIDxSYi5UcnVzdGNlbnRlckBwY20uYm9zY2guZGU+iJUDBRA/4CFX tt/sC4Spl30BAQK9BACj0XSNwhwHSagmHOLBm53akou3+zxYiFcFG+pUF7pd7Vzu askkbcLXOH1SzQbeTkGupPE2quWOjL91/UnsAzwiUIPhZoFRtfNC3Znd9qlpfHnd BIHoWOLAenXQVPvfXoHMMAO+8PgSvPpLtjhqUQ/n4JCwep4kAuJ3xwe9E+Op5A== =J70u -----END PGP PUBLIC KEY BLOCK----- The following is a user key without self-signature, but with the trust center signature on it: Uwe.Wetzel@bosch.com Uwe.Wetzel@de.bosch.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Secure e-mail iT_SEC_outlook V2.0.2 Comment: mI8DNe2/4AgOAQQAo34NbrHSKioPn7ZuZm32zQTPlWPKovnwmgR1oz2KkrFaS1Gc S+9ZUxGVP3spATw3onoDUv75zegjRAeSiq5rYKFqJedCVY47BcH86oGkgz7hIEXw zfSd49mCthqhrHOOo88t4yqWT/OiLxE8rgndwI3xCCsNos+SdguEAyMmuj0AEQEA AbQrV2V0emVsIFV3ZSAoUUkvSU5GNCkgPFV3ZS5XZXR6ZWxAYm9zY2guY29tPoiV AwUQP+At/bbf7AuEqZd9AQEjMgQAkjjL766MZtMAkpXrdRxTutpgG4vIaFd7Mlsv Yi3B67cYshMvezyrYBtaLFHICCgoj4mhSDuy6A6ZEZktOOIt8gYgi946r0wexypn w2v4MSzkZ5Yz+N3/c6148+FAz2/ZUjwxlfS374BKk/fMGQe7dmg9DPSGq3Ki+Hur YKd6FwO0LldldHplbCBVd2UgKFFJL0lORjQpIDxVd2UuV2V0emVsQGRlLmJvc2No LmNvbT6IlQMFED/gLf223+wLhKmXfQEBux4EAIV3d3iZL7BJVTMBDhjQkvRkiAQo 3SqzMcOdBnsGIArNE3gMgoe6K4GYOzkY6+s/Cb62ILOMzf49zfrA1RX9UIOKypv9 kQZY+UsUpzTh46zSgV9AXsFDEjGAwjjvhkIhA5pO/p/rVyF71Zu3NXyAV2buBqgI MJozJliYlBgRgI58 =+NiC -----END PGP PUBLIC KEY BLOCK----- From owner-ietf-openpgp@mail.imc.org Mon Dec 22 07:52:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13138 for ; Mon, 22 Dec 2003 07:51:59 -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 hBMBa6ib048021 for ; Mon, 22 Dec 2003 03:36:06 -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 hBMBa6Hf048020 for ietf-openpgp-bks; Mon, 22 Dec 2003 03:36:06 -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.10/8.12.8) with ESMTP id hBMBa4ib048012 for ; Mon, 22 Dec 2003 03:36:05 -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.10/8.12.9) with ESMTP id hBMBZxuG011082 for ; Mon, 22 Dec 2003 12:35:59 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.10/8.12.1/Submit) id hBMBZxOB011081 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 12:35:59 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Valid OpenPGP keys without self-signature? Date: Mon, 22 Dec 2003 11:35:59 +0000 (UTC) Organization: IKS GmbH Jena Lines: 15 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1072092959 10038 217.17.192.37 (22 Dec 2003 11:35:59 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 22 Dec 2003 11:35:59 +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: * aboietf@redtenbacher.de wrote: > (1) Are such keys a security problem? In general: Yes. In this particular case: No. > (2) Is such a key conforming to the OpenPGP spec (or at least > interoperable with a conforming OpenPGP product)? There are 2.6.x versions of PGP generating keys without a self signature. So they are introduced and common, despite considered obsolet. > (3) Which OpenPGP products support such unusual public keys? There is a strong movement to require the self signature. This is currently work in progress on the whole key space. From owner-ietf-openpgp@mail.imc.org Mon Dec 22 09:38:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18395 for ; Mon, 22 Dec 2003 09:38: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 hBMEHoib055704 for ; Mon, 22 Dec 2003 06:17:50 -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 hBMEHoTa055703 for ietf-openpgp-bks; Mon, 22 Dec 2003 06:17:50 -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 hBMEHmib055698 for ; Mon, 22 Dec 2003 06:17:48 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.45]) by smtp3.hushmail.com (Postfix) with ESMTP id 73F1F10E671 for ; Mon, 22 Dec 2003 06:17:48 -0800 (PST) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.8p1/8.12.8/Submit) id hBMEGUJu054805 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 06:16:30 -0800 (PST) Message-Id: <200312221416.hBMEGUJu054805@mailserver3.hushmail.com> Date: Mon, 22 Dec 2003 06:16:30 -0800 To: ietf-openpgp@imc.org Subject: Re: Valid OpenPGP keys without self-signature? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Dec 2003 02:38:30 -0800 aboietf@redtenbacher.de wrote: > >> >During OpenPGP interoperability tests, I have recently come across >an >unusual situation: [...] > (In my tests, PGP 5.x imported the user key without any error > message, whereas GnuPG 1.2.x refused to import the key even >in > "--expert" mode. And a PGP 8.02 user reported to me that PGP >8.02 > also refuses to import any keys without self-signature.) > >As I either have to find a solution to this interoperability problem [...] can't each user simply just self-sign the key as soon as it is received, and this should then allow it to be imported into gnupg 1.2.x / pgp 8.x ? 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 Mon Dec 22 12:23:27 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25878 for ; Mon, 22 Dec 2003 12:23: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 hBMH2Oib062947 for ; Mon, 22 Dec 2003 09:02:24 -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 hBMH2OPn062946 for ietf-openpgp-bks; Mon, 22 Dec 2003 09:02:24 -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 hBMH2Lib062924 for ; Mon, 22 Dec 2003 09:02:22 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id C9D8469A9A; Mon, 22 Dec 2003 12:02:21 -0500 (EST) Message-ID: <3FE722F8.D1FAFFEE@systemics.com> Date: Mon, 22 Dec 2003 11:59:36 -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: aboietf@redtenbacher.de Cc: ietf-openpgp@imc.org Subject: Re: Valid OpenPGP keys without self-signature? References: 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 aboietf@redtenbacher.de wrote: > As I either have to find a solution to this interoperability problem > or have to prove to the company that their setup is insecure, I would > be very happy about any answers to the above questions. Wolfgang, I'm afraid you are on the pointy end of a sharp stick. You are right that it is not strictly illegal, but as Lutz says, it will become illegal at some hopefully near stage. To all intents and purposes, it is already illegal structure, de facto, and you can expect no current or future OpenPGP product to accept it. The reason for this is complexity: OpenPGP's key structure is a bit of a mess. There is way too much freedom, in all the options and subpackets and arrays of packets and what have you. At a data level, this is fine, wonderful, uplifting, even. But at the level of security coding, this is a nightmare. In practice, in a secure program, every little execption adds to every other little exception to create the potential for a security failure. Either we have to as a community deal with the interrelated exceptions - all of them, in every body of code - or we have to remove the exceptions. The latter course is compelling, and in this particular case, the group debated the self-signed issue a year or so back, and came to the conclusion to deprecate un-self- signed keys. For your company - it is a matter of explaining that they are technically secure, but they will not inter- operate. Their keys have been "declared unsafe". That doesn't mean it is insecure. Consider it like taking the Mercedes in for the registration check and being told the brake lines need to be replaced. You know the lines are good for another 5 years, but once the standard is in place, that's it. Out they go. If they don't want to interoperate, then that's fine. But, if they want to interoperate, they have to do it on both the basis of security *and* the standard. iang PS: it would seem that a much bigger problem for them, if they *do* want to interoperate, is that they want to move over to V4 keys at some stage. So maybe the way to approach this is to leave the V3 keys in place, and start issuing V4 keys in the future? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUM8Nib081729 for ; Tue, 30 Dec 2003 14:08: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 hBUM8Nnx081728 for ietf-openpgp-bks; Tue, 30 Dec 2003 14:08:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBUM8Mib081723 for ; Tue, 30 Dec 2003 14:08:22 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Tue, 30 Dec 2003 14:08:19 -0800 Received: from [192.168.2.235] ([63.251.255.25]) by bletchley.merrymeet.com (PGP Universal service); Tue, 30 Dec 2003 14:08:23 -0800 Mime-Version: 1.0 (Apple Message framework v609) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Valid OpenPGP keys without self-signature? Date: Tue, 30 Dec 2003 14:08:27 -0800 To: OpenPGP X-Mailer: Apple Mail (2.609) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I want to add in a few comments. I think that self-signatures are good. However, I think it is a bad thing to be draconian about them. If a User ID (or attribute ID) is signed by me, then it should be valid, whether it's got a self-signature on it or not. I'd love to be able to add user names to other people's keys so that software I use can find them. Many people don't have every possible mail address on their keys, and it's damned annoying. Far too many people don't have the right user names on their keys. A user id on a key that is signed by me can be thought of as a SDSI name. Using the web of trust, I could even trust other names. I might, for example, consider valid an unsigned name if it is signed by someone I trust. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBULqHib081047 for ; Tue, 30 Dec 2003 13:52:17 -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 hBULqH9u081044 for ietf-openpgp-bks; Tue, 30 Dec 2003 13:52:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBULqFib081017 for ; Tue, 30 Dec 2003 13:52:15 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Tue, 30 Dec 2003 13:52:11 -0800 Received: from [192.168.2.235] ([63.251.255.25]) by bletchley.merrymeet.com (PGP Universal service); Tue, 30 Dec 2003 13:52:16 -0800 In-Reply-To: <20031223005502.GB576@jabberwocky.com> References: <20031223005502.GB576@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6A2EC2FE-3B12-11D8-AB4C-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org From: Jon Callas Subject: Re: "Other" compression algorithms Date: Tue, 30 Dec 2003 13:52:08 -0800 To: David Shaw X-Mailer: Apple Mail (2.609) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Then section 9.3 says "Implementations MAY implement ZLIB." That text > was written before BZip2 was added to the draft, and should probably > read "Implementations MAY implement any other algorithm." like the > other two sections. > Done. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBULpHib080851 for ; Tue, 30 Dec 2003 13:51:17 -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 hBULpHdZ080850 for ietf-openpgp-bks; Tue, 30 Dec 2003 13:51:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBULpGib080845 for ; Tue, 30 Dec 2003 13:51:16 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Tue, 30 Dec 2003 13:51:11 -0800 Received: from [192.168.2.235] ([63.251.255.25]) by bletchley.merrymeet.com (PGP Universal service); Tue, 30 Dec 2003 13:51:15 -0800 In-Reply-To: <20031223005156.GA576@jabberwocky.com> References: <20031223005156.GA576@jabberwocky.com> Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48429343-3B12-11D8-AB4C-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit Cc: ietf-openpgp@imc.org From: Jon Callas Subject: Re: From-plus-a-space Date: Tue, 30 Dec 2003 13:51:11 -0800 To: David Shaw X-Mailer: Apple Mail (2.609) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Dec 22, 2003, at 4:51 PM, David Shaw wrote: > However, in the draft, the mention of "From " is broken over two > lines as: > > "From > " > I changed it to: "...SHOULD dash escape lines commencing "From" followed by a space..." Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTJx0ib007594 for ; Mon, 29 Dec 2003 11:59:00 -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 hBTJx0Iv007593 for ietf-openpgp-bks; Mon, 29 Dec 2003 11:59:00 -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 hBTJwxib007586 for ; Mon, 29 Dec 2003 11:58:59 -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); Mon, 29 Dec 2003 12:58:56 -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: Compression and partial length chunks Date: Mon, 29 Dec 2003 14:58:54 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D01570E@bstn-exch1.forumsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compression and partial length chunks Thread-Index: AcPOPxJc+DW5A6eoQKaoXg57wrcEkAABM2/w From: "Hasnain Mujtaba" To: "Hal Finney" , X-OriginalArrivalTime: 29 Dec 2003 19:58:56.0217 (UTC) FILETIME=[31085C90:01C3CE46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBTJx0ib007588 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal, I appreciate your clarification. I can see that the real challenge will be to deal with the 3 levels of PBLs. When I detect that the EncryptedDataPacket is using PBLs, can I safely assume that the enclosed compressed data and literal data packets have been put into PBLs also? It is possible for a sender to prepare the literal and compressed data packets as a whole without using PBLs and then to send the encrypted data out in PBLs, even though it doesn't make sense and defeats the purpose of employing PBLs. I'm not sure if the specification prevents them from doing this sort of PBL encoding at the outer layer only. Regards Hasnain -----Original Message----- From: Hal Finney [mailto:hal@finney.org] Sent: Monday, December 29, 2003 6:36 AM To: hal@finney.org; Hasnain Mujtaba; ietf-openpgp@imc.org Subject: RE: Compression and partial length chunks Hasnain - > If I must have hold the whole source data in memory before I can > compress and then encrypt it, then I would always know before-hand the > lengths of the resulting packets (literal, compressed, and encrypted). > So when exactly does the need arise to use PBLs? Even when I am > streaming data, I cannot avoid the basic constraint that the entire > source data must be in memory before it can be processed. It is not the > case, as you pointed out, that I am feeding chunks of the source data to > the compression and encryption routines and then sending them out as > PBLs. I'm afraid I misled you in my earlier comments. Nothing in the OpenPGP algorithms or formats requires you to hold the entire document in memory. The compression and encryption algorithms can operate on chunks at a time, as long as they are in order: first chunk, second chunk, third chunk, etc. You asked earlier whether you could process the chunk "independently of the chunks already received" and my answer was no. What I meant was that you have to have processed those other chunks already, in order, and retained state information from those chunks. The widely used zlib decompression library provides this functionality, for example, as do most decryption libraries which provide the CFB chaining mode used by PGP. > I am new to the interesting world of PGP. I think it would be useful, if > at all possible, to be able to deal with the chunks independently so as > to avoid physical memory limitations. I hope my clarification above will show that it is possible to do this, but that state must be retained from chunk to chunk in the decompression and decryption modules. 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 hBTJ7uib004556 for ; Mon, 29 Dec 2003 11:07: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 hBTJ7u4F004555 for ietf-openpgp-bks; Mon, 29 Dec 2003 11:07:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBTJ7tib004550 for ; Mon, 29 Dec 2003 11:07:55 -0800 (PST) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id hBTBZiW16622; Mon, 29 Dec 2003 03:35:44 -0800 Date: Mon, 29 Dec 2003 03:35:44 -0800 From: "Hal Finney" Message-Id: <200312291135.hBTBZiW16622@finney.org> To: hal@finney.org, hmujtaba@forumsys.com, ietf-openpgp@imc.org Subject: RE: Compression and partial length chunks Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hasnain - > If I must have hold the whole source data in memory before I can > compress and then encrypt it, then I would always know before-hand the > lengths of the resulting packets (literal, compressed, and encrypted). > So when exactly does the need arise to use PBLs? Even when I am > streaming data, I cannot avoid the basic constraint that the entire > source data must be in memory before it can be processed. It is not the > case, as you pointed out, that I am feeding chunks of the source data to > the compression and encryption routines and then sending them out as > PBLs. I'm afraid I misled you in my earlier comments. Nothing in the OpenPGP algorithms or formats requires you to hold the entire document in memory. The compression and encryption algorithms can operate on chunks at a time, as long as they are in order: first chunk, second chunk, third chunk, etc. You asked earlier whether you could process the chunk "independently of the chunks already received" and my answer was no. What I meant was that you have to have processed those other chunks already, in order, and retained state information from those chunks. The widely used zlib decompression library provides this functionality, for example, as do most decryption libraries which provide the CFB chaining mode used by PGP. > I am new to the interesting world of PGP. I think it would be useful, if > at all possible, to be able to deal with the chunks independently so as > to avoid physical memory limitations. I hope my clarification above will show that it is possible to do this, but that state must be retained from chunk to chunk in the decompression and decryption modules. 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 hBTIuTib003781 for ; Mon, 29 Dec 2003 10:56:30 -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 hBTIuTPq003780 for ietf-openpgp-bks; Mon, 29 Dec 2003 10:56:29 -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 hBTIuSib003774 for ; Mon, 29 Dec 2003 10:56:29 -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); Mon, 29 Dec 2003 11:56:24 -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: Compression and partial length chunks Date: Mon, 29 Dec 2003 13:56:23 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D01570B@bstn-exch1.forumsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compression and partial length chunks Thread-Index: AcPOPR0WEzIWIwsBR8C2IHNaW+7T9g== From: "Hasnain Mujtaba" To: "Hal Finney" , X-OriginalArrivalTime: 29 Dec 2003 18:56:24.0989 (UTC) FILETIME=[752064D0:01C3CE3D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBTIuTib003776 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal, Thank you for your feedback, it has clarified a lot of confusion. I have a couple of follow up comments: If I must have hold the whole source data in memory before I can compress and then encrypt it, then I would always know before-hand the lengths of the resulting packets (literal, compressed, and encrypted). So when exactly does the need arise to use PBLs? Even when I am streaming data, I cannot avoid the basic constraint that the entire source data must be in memory before it can be processed. It is not the case, as you pointed out, that I am feeding chunks of the source data to the compression and encryption routines and then sending them out as PBLs. My basic problem is that I cannot simultaneously hold both the encrypted and decrypted data in memory because I will be dealing with large documents up to 10GB. So, if an encrypted document comes in and it uses PBLs, I still need to coallesce the chunks before I decrypt and decompress them. In other words, I need to hold the entire encrypted/compressed data in memory as well as the decrypted/decompressed data. I am new to the interesting world of PGP. I think it would be useful, if at all possible, to be able to deal with the chunks independently so as to avoid physical memory limitations. If you can provide additional feedback, I would be most grateful. Regards Hasnain. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBO6Axib084979 for ; Tue, 23 Dec 2003 22:10:59 -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 hBO6AxKG084978 for ietf-openpgp-bks; Tue, 23 Dec 2003 22:10:59 -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 hBO6Auib084972 for ; Tue, 23 Dec 2003 22:10:58 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hBO67fL25144 for ietf-openpgp@imc.org; Wed, 24 Dec 2003 01:07:41 -0500 Date: Wed, 24 Dec 2003 01:07:41 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Partial length chunks and 5-byte lengths Message-ID: <20031224060741.GC1182@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 (1% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 4.2.2.4. ("Partial Body Lengths") of bis-09 specifies that after the initial partial body length chunk: Another length header (of one of the three types -- one octet, two-octet, or partial) follows that portion. It explicitly says "one of three types", and mentions only the one octet, two octet, and partial length encodings. Some bias against the 5-octet length encoding ? ;) Unless that was intentional (was it?) I suggest that the text be changed to say one of the *four* types, etc, or just drop the parenthetical comment altogether. Also, it looks like part of the partial body length definition is in section 4.2.3 ("Packet Length Examples"), but should be in section 4.2.2.4 along with the rest of the definition: An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNMrmib064101 for ; Tue, 23 Dec 2003 14:53:48 -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 hBNMrm3m064100 for ietf-openpgp-bks; Tue, 23 Dec 2003 14:53:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNMrlib064095 for ; Tue, 23 Dec 2003 14:53:47 -0800 (PST) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id hBNNM1C21472; Tue, 23 Dec 2003 15:22:01 -0800 Date: Tue, 23 Dec 2003 15:22:01 -0800 From: "Hal Finney" Message-Id: <200312232322.hBNNM1C21472@finney.org> To: hmujtaba@forumsys.com, ietf-openpgp@imc.org Subject: Re: Compression and partial length chunks Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hasnain Mujtaba writes: > I was wondering if someone could help clarify some issues for me. It is > not clear to me from the RFC2440 how compression works when using > partial body length headers. > ... > Are the chunks independent in that can they be decrypted and > decompressed by the receiver without buffering them with other chunks? > E.g, if a 8192 bytes chunk is received enclosed within a partial body > length header, can the receiver take the chunk's payload and decrypt it > and then decompress it independently of the chunks already received and > those coming in? No. The partial body length headers have no implications for the data stream into which they are inserted. Their only purpose is to tell you (eventually) when you get to the end of the data. So your decompression must be done on the data stream taken as a whole, without regard to the presence of any partial body length headers. Two other points. First, within the encrypted packet is a compression packet, as you said; but within the compression packet is typically a literal data packet. Three layers of packets typically exist for this usage, not two. Second, each packet (encryption, compression, literal) needs some kind of length specification associated with it. You can put the full packet length in the header, if you know it in advance (which will not be the case if you are streaming). You can use partial body length. Or You can use the indefinite length type, which means that the packet goes all the way to the end of the data. The point is that this has to be done at each of the three layers. If you are using partial body lengths (PBLs), this must be done at each level. The literal packet will use PBLs; then this data is compressed, and the output of the compression gets PBLs inserted; and then the data is encrypted, and the output of the encryption gets PBLs inserted. There is no logical connection between the packetizing at the different levels. They could use different size partial body packets and insert their PBLs at different points. The PBLs are logically separate from the data stream in which they are inserted. 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 hBNMTvib063020 for ; Tue, 23 Dec 2003 14:29: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 hBNMTvpC063019 for ietf-openpgp-bks; Tue, 23 Dec 2003 14:29:57 -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 hBNMTuib062980 for ; Tue, 23 Dec 2003 14:29:56 -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, 23 Dec 2003 15:29:53 -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: Compression and partial length chunks Date: Tue, 23 Dec 2003 17:29:51 -0500 Message-ID: <4DCE15B9C4E66F4CA967EBF64C53D64D015708@bstn-exch1.forumsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Compression and partial length chunks Thread-Index: AcPJo/kMBRph5hE2S+SGNqAvlx/zRg== From: "Hasnain Mujtaba" To: X-OriginalArrivalTime: 23 Dec 2003 22:29:53.0691 (UTC) FILETIME=[493AB6B0:01C3C9A4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hBNMTvib063013 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi all, I was wondering if someone could help clarify some issues for me. It is not clear to me from the RFC2440 how compression works when using partial body length headers. I am working on an application that will support both inbound and outbound streaming. Encrypted packets will be coming in over FTP and the application will have to decrypt and decompress the chunks on the fly so they can be written to a file or sent out over the network. Similary, the application will encrypt an incoming plain text file using partial length encoding. In both cases, the size of the incoming file (encrypted one and the plain text is not known). As I understand it, first the Sym. Encrypted & Integrity Protected header is sent out by the sender, then only one CompressedDataPacket header is encrypted and sent out in the first chunk, the subsequent chunks are compressed and then encrypted and enclosed in the partial body length header and then sent out. The receiving side (i.e my application) receives the Sym. Encrypted & Integrity Protected header. It starts decryting the subsequent chunks. In doing so, the receiver finds the CompressedDataPacket header. Therefore, the receiver can start decompressing the subsequent chunks after decrypting them. Are the chunks independent in that can they be decrypted and decompressed by the receiver without buffering them with other chunks? E.g, if a 8192 bytes chunk is received enclosed within a partial body length header, can the receiver take the chunk's payload and decrypt it and then decompress it independently of the chunks already received and those coming in? I guess, if I understood the procedure for creating an encrypted/compressed chunk, it would make it easier to understand the decryption procedure. Any help would be greatly appreciated! Regards Hasnain. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNMGpib062309 for ; Tue, 23 Dec 2003 14:16:51 -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 hBNMGpUb062306 for ietf-openpgp-bks; Tue, 23 Dec 2003 14:16:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBNMGmib062292 for ; Tue, 23 Dec 2003 14:16:51 -0800 (PST) (envelope-from aboietf@redtenbacher.de) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AYupd-0003G3-00 for ietf-openpgp@imc.org; Tue, 23 Dec 2003 23:16:49 +0100 Received: from [217.185.62.234] (helo=217.185.62.234) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AYupd-0002oE-00 for ietf-openpgp@imc.org; Tue, 23 Dec 2003 23:16:49 +0100 Subject: Re: Valid OpenPGP keys without self-signature? To: ietf-openpgp@imc.org From: aboietf@redtenbacher.de Message-Id: Date: Tue, 23 Dec 2003 23:16:49 +0100 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e384712ef1f129ade61e87b26279bda6 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: You guys are great! Within 24 hours, I received complete answers to all of my questions. So I now know that: (1) the PKI setup of "Robert Bosch GmbH" uses obsolete key types, but does _not_ contain a (known) major security flaw. This means that they will have to change their product at some time in the future but are not going to do any emergency product switch within the next few weeks. (As a result of this, I will have to find a solution that interoperates with their current setup.) (2) it should be possible to interoperate to their PKI with OpenPGP products (maybe after some fiddling); (3) I can import their keys without self-signature not only into older PGP versions, but also into an up-to-date GnuPG version. Thanks a lot to all who helped! (Lars, Lutz, Vedaal, Ian and Konrad) - Wolfgang Redtenbacher --------------------------------------------------------------------- Redtenbacher Software Tel.: +49 7159 17046 Roemerstr. 11/1 Fax: +49 7159 17047 D-71272 Renningen e-mail: wolfgang@redtenbacher.de --------------------------------------------------------------------- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBN3PFib087323 for ; Mon, 22 Dec 2003 19:25:15 -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 hBN3PFA0087322 for ietf-openpgp-bks; Mon, 22 Dec 2003 19:25:15 -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 hBN3PEib087317 for ; Mon, 22 Dec 2003 19:25:14 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hBN3M7X01787 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 22:22:07 -0500 Date: Mon, 22 Dec 2003 22:22:06 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: The signer's user ID subpacket and attribute IDs Message-ID: <20031223032206.GA329@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 New User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The current draft specifies the "Signer's User ID" subpacket as the user ID that is "responsible for the signing". When I documented the existing attribute ID design, I was concerned that someone might try and make a Signer's User ID for an attribute packet which raises a problem since there is no way for the verifier of the signature to know if a given Signer's User ID should be parsed as a text or attribute user ID. Because of this (and a slight worry about massive signatures that contain embedded JPEGs), I asked Jon Callas to put in "This subpacket is not appropriate to use to refer to a User Attribute packet." This has always bothered me, since I feel that an attribute user ID should be as useful as a regular text user ID. Here are two different proposals to fix this. I'm not strongly wedded to either solution in particular. I just want to address the limitation. 1) Change the definition of the Signer's User ID to be the SHA-1 hash of the contents of the User ID (whether textual or attribute) in question. The usual user ID hashing rules apply (0xd1/0xb4 + len + contents). This eliminates the problem by making all Signer's User ID subpackets parsable in the same way. Impact from this change should be minimal as nobody (so far as I know) has implemented Signer's User ID yet. or 2) Add a new signature subpacket, which is an attribute user ID counterpart to the Signer's User ID subpacket, defined identically to the current Signer's User ID subpacket, but used for attribute user IDs. This eliminates the problem by making it clear how the subpacket needs to be parsed (text or attribute). Note that #1 has the detail that a signature containing a Signer's User ID subpacket of a user ID that the verifier does not have on his local copy of the key does not "give away" the contents of that user ID. I can see this as an advantage or a disadvantage, depending on what the signer is trying to accomplish. #2 has the detail that a signature could conceivably contain an embedded attribute ID, and thus (for example) contain the photograph of the signer. Like #1, I can see this as an advantage or disadvantage, depending on what the signer is trying to accomplish. (It also can lead to really large signatures). As I said before, I'm not wedded to either solution. I would like to address the limitation though. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBN0wAib081715 for ; Mon, 22 Dec 2003 16:58:10 -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 hBN0wALe081714 for ietf-openpgp-bks; Mon, 22 Dec 2003 16:58:10 -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 hBN0w9ib081709 for ; Mon, 22 Dec 2003 16:58:10 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hBN0t2D00665 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 19:55:02 -0500 Date: Mon, 22 Dec 2003 19:55:02 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: "Other" compression algorithms Message-ID: <20031223005502.GB576@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 New User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In bis-09: Section 9.1 says "Implementations MAY implement any other algorithm." Section 9.2 also says "Implementations MAY implement any other algorithm." Then section 9.3 says "Implementations MAY implement ZLIB." That text was written before BZip2 was added to the draft, and should probably read "Implementations MAY implement any other algorithm." like the other two sections. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBN0t5ib081614 for ; Mon, 22 Dec 2003 16:55:05 -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 hBN0t5lF081613 for ietf-openpgp-bks; Mon, 22 Dec 2003 16:55:05 -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 hBN0t3ib081608 for ; Mon, 22 Dec 2003 16:55:04 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hBN0puj00641 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 19:51:56 -0500 Date: Mon, 22 Dec 2003 19:51:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: From-plus-a-space Message-ID: <20031223005156.GA576@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 New User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In bis-09, section 7.1 ("Dash-Escaped Text") says "An implementation MAY dash escape any line, SHOULD dash escape lines commencing "From " (note the space), and MUST dash escape any line commencing in a dash." However, in the draft, the mention of "From " is broken over two lines as: "From " This makes the text a little unclear, despite the parenthetical "note the space". Also, once this draft becomes an RFC, people will be HTMLizing it, and printing it with various non-monospaced fonts, and so on. I suggest changing the "(note the space)" to "(the string 'From' followed by a space)". David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMNrgib079752 for ; Mon, 22 Dec 2003 15:53:44 -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 hBMNrgm9079751 for ietf-openpgp-bks; Mon, 22 Dec 2003 15:53:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMNreib079745 for ; Mon, 22 Dec 2003 15:53:41 -0800 (PST) (envelope-from konrad@silmor.de) Received: from fwd10.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1AYVRz-0007mZ-00; Mon, 22 Dec 2003 20:10:43 +0100 Received: from arthur.local (TnuLCqZdYe065H7ZTneY-qgmoiyqu1bLxFTTYt0WVu43NBmtr2Z-oS@[217.225.240.76]) by fmrl10.sul.t-online.com with esmtp id 1AYUOr-0icK0W0; Mon, 22 Dec 2003 19:03:25 +0100 Received: from zaphod.local ([192.168.1.5]) by arthur.local with esmtp (Exim 3.35 #1 (Debian)) id 1AYUOq-0007ev-00 for ; Mon, 22 Dec 2003 19:03:24 +0100 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: Valid OpenPGP keys without self-signature? Date: Mon, 22 Dec 2003 19:03:21 +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=_sHz5/QbZMAzT63f"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200312221903.24516.konrad@silmor.de> X-Seen: false X-ID: TnuLCqZdYe065H7ZTneY-qgmoiyqu1bLxFTTYt0WVu43NBmtr2Z-oS@t-dialin.net Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_sHz5/QbZMAzT63f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Monday 22 December 2003 11:38, aboietf@redtenbacher.de wrote: > The German company "Robert Bosch GmbH" introduced a PKI on the basis > of a product called "Secure e-mail iT_SEC_outlook". This product uses > old-style V3 RSA keys that are created by the "trust center" of > the company for every user and are signed on creation by the trust > center key. The unusual aspect now is that only the "trust center key" > has a self-signature. All normal user keys have no self-signature but > only the trust center signature on them. [...] > (1) Are such keys a security problem? The key material in itself should be pretty secure. The signature also shou= ld=20 be ok, as long as it stays valid. I personally would not use V3-keys for another reason: you can change the=20 creation date of the key without changing the keyID and fingerprint. This=20 means you can easily invalidate the signature without changing the main=20 identifiers of the key (key material, keyID, fingerprint). It can be very=20 annoying to try to verify a key that seemingly is the correct one, but has= =20 been altered enough to make the signature invalid(*). V4 keys change their = ID=20 and fingerprint whenever you change ANY bit in the public part of the key. (*)Assuming that PGP2.x does verify the creation date of the key versus the= =20 creation date of the signature. This is the only part that invalidates the= =20 signature. Konrad --Boundary-02=_sHz5/QbZMAzT63f Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQA/5zHsm6pO7A9GSMQRApKSAJ96zub53mwUs2YoalSsHOWFOxsUCACeId0T 4Vx8ZMLEZuFgncVPQIE6A9U= =+3Ed -----END PGP SIGNATURE----- --Boundary-02=_sHz5/QbZMAzT63f-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMH2Oib062947 for ; Mon, 22 Dec 2003 09:02:24 -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 hBMH2OPn062946 for ietf-openpgp-bks; Mon, 22 Dec 2003 09:02:24 -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 hBMH2Lib062924 for ; Mon, 22 Dec 2003 09:02:22 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id C9D8469A9A; Mon, 22 Dec 2003 12:02:21 -0500 (EST) Message-ID: <3FE722F8.D1FAFFEE@systemics.com> Date: Mon, 22 Dec 2003 11:59:36 -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: aboietf@redtenbacher.de Cc: ietf-openpgp@imc.org Subject: Re: Valid OpenPGP keys without self-signature? References: 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: aboietf@redtenbacher.de wrote: > As I either have to find a solution to this interoperability problem > or have to prove to the company that their setup is insecure, I would > be very happy about any answers to the above questions. Wolfgang, I'm afraid you are on the pointy end of a sharp stick. You are right that it is not strictly illegal, but as Lutz says, it will become illegal at some hopefully near stage. To all intents and purposes, it is already illegal structure, de facto, and you can expect no current or future OpenPGP product to accept it. The reason for this is complexity: OpenPGP's key structure is a bit of a mess. There is way too much freedom, in all the options and subpackets and arrays of packets and what have you. At a data level, this is fine, wonderful, uplifting, even. But at the level of security coding, this is a nightmare. In practice, in a secure program, every little execption adds to every other little exception to create the potential for a security failure. Either we have to as a community deal with the interrelated exceptions - all of them, in every body of code - or we have to remove the exceptions. The latter course is compelling, and in this particular case, the group debated the self-signed issue a year or so back, and came to the conclusion to deprecate un-self- signed keys. For your company - it is a matter of explaining that they are technically secure, but they will not inter- operate. Their keys have been "declared unsafe". That doesn't mean it is insecure. Consider it like taking the Mercedes in for the registration check and being told the brake lines need to be replaced. You know the lines are good for another 5 years, but once the standard is in place, that's it. Out they go. If they don't want to interoperate, then that's fine. But, if they want to interoperate, they have to do it on both the basis of security *and* the standard. iang PS: it would seem that a much bigger problem for them, if they *do* want to interoperate, is that they want to move over to V4 keys at some stage. So maybe the way to approach this is to leave the V3 keys in place, and start issuing V4 keys in the future? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMEHoib055704 for ; Mon, 22 Dec 2003 06:17:50 -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 hBMEHoTa055703 for ietf-openpgp-bks; Mon, 22 Dec 2003 06:17:50 -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 hBMEHmib055698 for ; Mon, 22 Dec 2003 06:17:48 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.45]) by smtp3.hushmail.com (Postfix) with ESMTP id 73F1F10E671 for ; Mon, 22 Dec 2003 06:17:48 -0800 (PST) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.8p1/8.12.8/Submit) id hBMEGUJu054805 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 06:16:30 -0800 (PST) Message-Id: <200312221416.hBMEGUJu054805@mailserver3.hushmail.com> Date: Mon, 22 Dec 2003 06:16:30 -0800 To: ietf-openpgp@imc.org Cc: Subject: Re: Valid OpenPGP keys without self-signature? From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 Dec 2003 02:38:30 -0800 aboietf@redtenbacher.de wrote: > >> >During OpenPGP interoperability tests, I have recently come across >an >unusual situation: [...] > (In my tests, PGP 5.x imported the user key without any error > message, whereas GnuPG 1.2.x refused to import the key even >in > "--expert" mode. And a PGP 8.02 user reported to me that PGP >8.02 > also refuses to import any keys without self-signature.) > >As I either have to find a solution to this interoperability problem [...] can't each user simply just self-sign the key as soon as it is received, and this should then allow it to be imported into gnupg 1.2.x / pgp 8.x ? 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 hBMBa6ib048021 for ; Mon, 22 Dec 2003 03:36:06 -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 hBMBa6Hf048020 for ietf-openpgp-bks; Mon, 22 Dec 2003 03:36:06 -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.10/8.12.8) with ESMTP id hBMBa4ib048012 for ; Mon, 22 Dec 2003 03:36:05 -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.10/8.12.9) with ESMTP id hBMBZxuG011082 for ; Mon, 22 Dec 2003 12:35:59 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.10/8.12.1/Submit) id hBMBZxOB011081 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 12:35:59 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Valid OpenPGP keys without self-signature? Date: Mon, 22 Dec 2003 11:35:59 +0000 (UTC) Organization: IKS GmbH Jena Lines: 15 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1072092959 10038 217.17.192.37 (22 Dec 2003 11:35:59 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 22 Dec 2003 11:35:59 +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: * aboietf@redtenbacher.de wrote: > (1) Are such keys a security problem? In general: Yes. In this particular case: No. > (2) Is such a key conforming to the OpenPGP spec (or at least > interoperable with a conforming OpenPGP product)? There are 2.6.x versions of PGP generating keys without a self signature. So they are introduced and common, despite considered obsolet. > (3) Which OpenPGP products support such unusual public keys? There is a strong movement to require the self signature. This is currently work in progress on the whole key space. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMAcbib045055 for ; Mon, 22 Dec 2003 02:38:37 -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 hBMAcbUD045054 for ietf-openpgp-bks; Mon, 22 Dec 2003 02:38:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBMAcXib045046 for ; Mon, 22 Dec 2003 02:38:36 -0800 (PST) (envelope-from aboietf@redtenbacher.de) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AYNSJ-0003W3-00 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 11:38:31 +0100 Received: from [62.134.100.38] (helo=62.134.100.38) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1AYNSH-0005q8-00 for ietf-openpgp@imc.org; Mon, 22 Dec 2003 11:38:30 +0100 Subject: Valid OpenPGP keys without self-signature? To: ietf-openpgp@imc.org From: aboietf@redtenbacher.de Message-Id: Date: Mon, 22 Dec 2003 11:38:30 +0100 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:e384712ef1f129ade61e87b26279bda6 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: During OpenPGP interoperability tests, I have recently come across an unusual situation: The German company "Robert Bosch GmbH" introduced a PKI on the basis of a product called "Secure e-mail iT_SEC_outlook". This product uses old-style V3 RSA keys that are created by the "trust center" of the company for every user and are signed on creation by the trust center key. The unusual aspect now is that only the "trust center key" has a self-signature. All normal user keys have no self-signature but only the trust center signature on them. (I have added the trust center key and one user key at the end of this message to show what I mean.) My questions now are: (1) Are such keys a security problem? (A key without any signature on it would be open to manipulation, of course, but the company claims that their trust center signature protects the exact same key contents that a self-signature would protect. And according to RFC 2440, this really seems to be the case.) (2) Is such a key conforming to the OpenPGP spec (or at least interoperable with a conforming OpenPGP product)? (I re-read the spec yesterday and could not find any obvious violation although such a key loses lots of features because aspects like "Key expiration time", "Preferred symmectric algorithms", "Preferred hash algorithms", "Preferred compression algorithms", "Key server preferences" and the "Primary user id" flag all reside in the self-signature that is missing here.) (3) Which OpenPGP products support such unusual public keys? (In my tests, PGP 5.x imported the user key without any error message, whereas GnuPG 1.2.x refused to import the key even in "--expert" mode. And a PGP 8.02 user reported to me that PGP 8.02 also refuses to import any keys without self-signature.) As I either have to find a solution to this interoperability problem or have to prove to the company that their setup is insecure, I would be very happy about any answers to the above questions. - Wolfgang Redtenbacher --------------------------------------------------------------------- Redtenbacher Software Tel.: +49 7159 17046 Roemerstr. 11/1 Fax: +49 7159 17047 D-71272 Renningen e-mail: wolfgang@redtenbacher.de --------------------------------------------------------------------- The following is the trust center key of the company: Rb.Trustcenter@bosch.com Rb.Trustcenter@de.bosch.com Rb.Trustcenter@pcm.bosch.de -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Secure e-mail iT_SEC_outlook V2.0.2 Comment: mI8DNTPcYAqAAQQApTiBHFV+5Y0MAOeO/brDX86hcZKkrKsOURPLR0sjI8tSeYML pTkq8W+U9qPkVXQW39vXxLH7ztMDYL2MXfmAFeMbVxLg72ibpyy/YRB7tjRRR5vp aJZILLM2p35eqESt7TeLNrECCbH4NywYBR2EeEMLyJ0K7Rkatt/sC4Spl30AEQEA AbQ0VHJ1c3RjZW50ZXIgUkIgKFNUL1ZTQzMyKSA8UmIuVHJ1c3RjZW50ZXJAYm9z Y2guY29tPoiVAwUQP+AhV7bf7AuEqZd9AQFhGQP/Qk/P4KewVRGtUASplhbEiIr8 C6v26vToWQcnNPryINr4T3vhd9knjXoydBB4DAUgE/LcwGHI0pFR6kY/wvqWRdgY mI7UCVuOOz3xftQjJGAR9mw9Bh/1icUB48ayjrYSqUPxH+5DuWdfIXnCjBheRSlK yJ8S630SoARgiUkx+Oa0N1RydXN0Y2VudGVyIFJCIChTVC9WU0MzMikgPFJiLlRy dXN0Y2VudGVyQGRlLmJvc2NoLmNvbT6IlQMFED/gIVe23+wLhKmXfQEB8zoD/RQn qp7pGsx8LIm2DMxTazkpJ/+bKOmn78Yw/I0YaBjpZHdrRDQ0YGIem4vQDcdRnzXo +z1kXh9F3uGtvtZMbSDHCkY8GQ5hZzJhY2F7xIo4Xyh/+KNyOAPTmr6b4Zrnj5JJ MBqTeXWfjvYaG56NI5fBXMILeIl71SJfK0KgspAWtDdUcnVzdGNlbnRlciBSQiAo U1QvVlNDMzIpIDxSYi5UcnVzdGNlbnRlckBwY20uYm9zY2guZGU+iJUDBRA/4CFX tt/sC4Spl30BAQK9BACj0XSNwhwHSagmHOLBm53akou3+zxYiFcFG+pUF7pd7Vzu askkbcLXOH1SzQbeTkGupPE2quWOjL91/UnsAzwiUIPhZoFRtfNC3Znd9qlpfHnd BIHoWOLAenXQVPvfXoHMMAO+8PgSvPpLtjhqUQ/n4JCwep4kAuJ3xwe9E+Op5A== =J70u -----END PGP PUBLIC KEY BLOCK----- The following is a user key without self-signature, but with the trust center signature on it: Uwe.Wetzel@bosch.com Uwe.Wetzel@de.bosch.com -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Secure e-mail iT_SEC_outlook V2.0.2 Comment: mI8DNe2/4AgOAQQAo34NbrHSKioPn7ZuZm32zQTPlWPKovnwmgR1oz2KkrFaS1Gc S+9ZUxGVP3spATw3onoDUv75zegjRAeSiq5rYKFqJedCVY47BcH86oGkgz7hIEXw zfSd49mCthqhrHOOo88t4yqWT/OiLxE8rgndwI3xCCsNos+SdguEAyMmuj0AEQEA AbQrV2V0emVsIFV3ZSAoUUkvSU5GNCkgPFV3ZS5XZXR6ZWxAYm9zY2guY29tPoiV AwUQP+At/bbf7AuEqZd9AQEjMgQAkjjL766MZtMAkpXrdRxTutpgG4vIaFd7Mlsv Yi3B67cYshMvezyrYBtaLFHICCgoj4mhSDuy6A6ZEZktOOIt8gYgi946r0wexypn w2v4MSzkZ5Yz+N3/c6148+FAz2/ZUjwxlfS374BKk/fMGQe7dmg9DPSGq3Ki+Hur YKd6FwO0LldldHplbCBVd2UgKFFJL0lORjQpIDxVd2UuV2V0emVsQGRlLmJvc2No LmNvbT6IlQMFED/gLf223+wLhKmXfQEBux4EAIV3d3iZL7BJVTMBDhjQkvRkiAQo 3SqzMcOdBnsGIArNE3gMgoe6K4GYOzkY6+s/Cb62ILOMzf49zfrA1RX9UIOKypv9 kQZY+UsUpzTh46zSgV9AXsFDEjGAwjjvhkIhA5pO/p/rVyF71Zu3NXyAV2buBqgI MJozJliYlBgRgI58 =+NiC -----END PGP PUBLIC KEY BLOCK----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCKfiib022612 for ; Fri, 12 Dec 2003 12:41:44 -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 hBCKfikL022611 for ietf-openpgp-bks; Fri, 12 Dec 2003 12:41:44 -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 hBCKfhib022605 for ; Fri, 12 Dec 2003 12:41:43 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 8DC7C69A85; Fri, 12 Dec 2003 15:41:44 -0500 (EST) Message-ID: <3FDA275D.5478DEB2@systemics.com> Date: Fri, 12 Dec 2003 15:38:53 -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: Konrad Rosenbaum Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> <200312121844.29829.konrad@silmor.de> 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: Konrad Rosenbaum wrote: > > On Thursday 11 December 2003 19:04, David Shaw wrote: > > I disagree we need to change anything here. There is already only one > > separator permitted. Using your example: > > > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > > > The second instance of colon-space is NOT a separator. It's just part > > of the value. > > As long as the line is not split, you are correct. Knowing how coders make different assumptions, and have different scanning tools available to them, even this could cause some surprises. For e.g., in list based languages, popping is more natural than parsing left-to-right. Here's some perl: perl -e ' $x = "Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial"; @a = (split(": ", $x)); $_ = shift(@a); print "$_\n"; /Version/ && print pop(@a), "\n"; ' ... > I'm a newbie to implementing OpenPGP - so please forgive me, if my question is > stupid: why consider the additional headers at all? They seem to me to only > have any value to human readers and none at all to OpenPGP itself, since all > important information is already encoded into the binary message blocks (once > you got them out of their armor). Is there any technical reason for the RFC > not saying "Implementations shall ignore header lines."? This is meta-part of the issue. Currently, the ID says: "OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor." I wonder whether that is too strong. It seems reasonable to say that implementations may attempt to parse beyond and ignore improperly formatted headers. Perhaps with warnings. As we have not gone to any great extent to define why the optional ascii armour headers are important, it seems odd to treat them as if they are important enough to be capable of breaking the armoured message. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHinib016477 for ; Fri, 12 Dec 2003 09:44: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 hBCHinOw016476 for ietf-openpgp-bks; Fri, 12 Dec 2003 09:44:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCHimib016471 for ; Fri, 12 Dec 2003 09:44:48 -0800 (PST) (envelope-from konrad@silmor.de) Received: from fwd01.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1AUrLM-0002Oe-03; Fri, 12 Dec 2003 18:44:48 +0100 Received: from arthur.local (VToPSqZd8edUziKuz2XyPAS7HLDQs758b4S4w8-NgSOvfmFa+V5G4M@[217.235.57.62]) by fmrl01.sul.t-online.com with esmtp id 1AUrL4-14hjZA0; Fri, 12 Dec 2003 18:44:30 +0100 Received: from zaphod.local ([192.168.1.5]) by arthur.local with esmtp (Exim 3.35 #1 (Debian)) id 1AUrL4-0001dn-00 for ; Fri, 12 Dec 2003 18:44:30 +0100 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow Date: Fri, 12 Dec 2003 18:44:26 +0100 User-Agent: KMail/1.5.4 References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> In-Reply-To: <20031211180402.GA16475@jabberwocky.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_95f2/hnr1WRFCZF"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200312121844.29829.konrad@silmor.de> X-Seen: false X-ID: VToPSqZd8edUziKuz2XyPAS7HLDQs758b4S4w8-NgSOvfmFa+V5G4M@t-dialin.net Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_95f2/hnr1WRFCZF Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Thursday 11 December 2003 19:04, David Shaw wrote: > I disagree we need to change anything here. There is already only one > separator permitted. Using your example: > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > The second instance of colon-space is NOT a separator. It's just part > of the value. As long as the line is not split, you are correct. > This isn't very complicated. I'd be quite surprised to hear of any > parser that didn't do: > > a) Find the leftmost colon-space. > b) The string to the left is the key. > c) The string to the right is the value. > > That's how email works (note the subject line of this message has two > colons!), how news works, and how OpenPGP works. With one notable difference: in the case any MTA splits headerlines, it wil= l=20 add space(s) in front of the next line, which is defined to continue the li= ne=20 in RFC822. When a MUA or MTA splits body lines it will not add anything=20 (maybe except for some ">" characters). So the receiving system will not be= =20 able to tell the difference between a new header line an a continuation. I'm a newbie to implementing OpenPGP - so please forgive me, if my question= is=20 stupid: why consider the additional headers at all? They seem to me to only= =20 have any value to human readers and none at all to OpenPGP itself, since al= l=20 important information is already encoded into the binary message blocks (on= ce=20 you got them out of their armor). Is there any technical reason for the RFC= =20 not saying "Implementations shall ignore header lines."? Konrad --Boundary-02=_95f2/hnr1WRFCZF Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD4DBQA/2f59m6pO7A9GSMQRAn46AJdZXsgMN2AAI71IBy2fik8jxiffAKC/nH2L hL0qpnCPKTeRIqblk5Mh8A== =Uy1j -----END PGP SIGNATURE----- --Boundary-02=_95f2/hnr1WRFCZF-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBCFkcib011192 for ; Fri, 12 Dec 2003 07:46:38 -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 hBCFkcQU011191 for ietf-openpgp-bks; Fri, 12 Dec 2003 07:46:38 -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 hBCFkaib011182 for ; Fri, 12 Dec 2003 07:46:36 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 2C0C969B42; Fri, 12 Dec 2003 10:46:37 -0500 (EST) Message-ID: <3FD9E232.3FF8215A@systemics.com> Date: Fri, 12 Dec 2003 10:43:46 -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: karlsson@hal-pc.org Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> <3FD8BF09.551E6238@systemics.com> <20031212045622.GU15000@stonewall> 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: karlsson@hal-pc.org wrote: > > On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote: > > > > Such as: > > > > Version: 1.0.0 non-commercial, upgrade to > > Version: 2.0.0-commercial > > > > When the line slicing behaviour is set to (about) column 42. > > If I have to set my line width to 42, your mail system is so broken > that I don't need to talk to it. 72 is reasonable, and and one should > expect lines exceeding 80 characters to be wrapped. Anything under 68 is > unreasonably small. I, for example, am using 72 character lines in my > editor (vim). It does appear to be the consensus that there is no need or desire to change the ID on this issue. However, I'm not seeing a lot of real consideration of the real points here. So I'm unclear here whether to keep kicking this dying horse, or perhaps Derik could rule on closing it? ? I disagree with the above logic on the following grounds: OpenPGP is not only used for mail, and in fact takes great care to be more universally useful (scan the ID for the word "mail", I just did!). We here should also strive to move from the particular to the general, when looking at examples, and back again. Security standards are not built on such considerations of "yours is broken because I don't like your numbers." Bad software is certainly built with those sorts of criteria, but bad software is not what we are about here. This is about security, so detail is important. The offending number chosen was related to the example; the point remains with an example of a different number. You pick. Notwithstanding many peoples' desires to impose their views of how mail works on the rest of the world, there are other mail considerations in the future: PDAs and phones have smaller screens, for example. Web mailers and hush-style mailers can be very unkind to formatters. Chat is replacing email.... the list goes on - if OpenPGP is to be based on the email view of the past, then, we should all stop work on it right now. The greatest success comes when multiple competing implementations communicate with ease, and without games. Here we have a case where it is apparently easy to legally create a correct message that gets turned into a recipient message of indeterminate legality by transport. Fixing this costs nobody much at all [1]. > if (!(ptr=(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=' ') > exit(1); Please make sure you read the entire example. That doesn't decide which line of the two lines in the previous text, post-slicing, goes on to become the dominating one. The game to play in security programming is to see if a) we can confuse the other party, and b) we can create a security breach out of a confusion. We've shown a). I grant b) is a little harder, as optional headers aren't supposed to be "used" for such things. But, who knows what adventurous souls have in their minds for the future... [2] iang [1] I just thought late last night how to breach b)... Imagine you are a company selling a device that filters on the headers. Imagine that you make commercial decisions on the basis of those headers. (Because that's all you can read.) Then, an enterprising young chap realises that all he has to do is to slice the headers, and they are still human-readable, but they bypass the filtering of the proxy that handles incoming messages. marketing reference: NY AG v. WS == 1.3 bn. [2] the guys over at PGP Inc might want to rewrite their comment to be a bit shorter than the ASCII- Armoured data lines - rule of thumb - and to change the extra ": " to some other symbol. If they haven't already done these steps, I'd be very surprised! Also, they should reject sliced headers, or suggest we change the ID on that point. But, no real cost. GPG might want to detect and warn that the headers appear corrupted and can be fixed easily with an editor, rather than silently bailing on ID strictness. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4uLib010319 for ; Thu, 11 Dec 2003 20:56:21 -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 hBC4uLrb010318 for ietf-openpgp-bks; Thu, 11 Dec 2003 20:56:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from crustytoothpaste.ath.cx (cs2416783-242.houston.rr.com [24.167.83.242]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBC4uKib010312 for ; Thu, 11 Dec 2003 20:56:20 -0800 (PST) (envelope-from karlsson@hal-pc.org) Received: from stonewall (unknown [192.168.2.2]) by crustytoothpaste.ath.cx (Postfix) with SMTP id 9B3F17BC29; Fri, 12 Dec 2003 04:56:22 +0000 (UTC) Received: by stonewall (sSMTP sendmail emulation); Fri, 12 Dec 2003 04:56:22 +0000 Date: Fri, 12 Dec 2003 04:56:22 +0000 From: karlsson@hal-pc.org To: Ian Grigg Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow Message-ID: <20031212045622.GU15000@stonewall> References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> <3FD8BF09.551E6238@systemics.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="YG0IFkGWIt6MbjRk" Content-Disposition: inline In-Reply-To: <3FD8BF09.551E6238@systemics.com> X-Operating-System: Linux stonewall.crustytoothpaste.ath.cx 2.6.0-test7-1-386 Content-Conversion: prohibited X-Request-PGP: finger://bmc@crustytoothpaste.ath.cx User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --YG0IFkGWIt6MbjRk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 11, 2003 at 02:01:29PM -0500, Ian Grigg wrote: >=20 > Such as: >=20 > Version: 1.0.0 non-commercial, upgrade to > Version: 2.0.0-commercial >=20 > When the line slicing behaviour is set to (about) column 42. If I have to set my line width to 42, your mail system is so broken that I don't need to talk to it. 72 is reasonable, and and one should=20 expect lines exceeding 80 characters to be wrapped. Anything under 68 is unreasonably small. I, for example, am using 72 character lines in my editor (vim). > > This isn't very complicated. I'd be quite surprised to hear of any > > parser that didn't do: > >=20 > > a) Find the leftmost colon-space. > > b) The string to the left is the key. > > c) The string to the right is the value. >=20 >=20 > How do parsers handle the above case? Not that it's Do a) with strchr(3) or memchr(3) by finding a colon and then check that the next character is a space. If it's not, abort the message. The code is: if (!(ptr=3D(uint8_t *)memchr(line, ':', sizeof(line))) || ptr[1]!=3D' ') exit(1); > important. --=20 Brian M. Carlson 0x560553e7 --YG0IFkGWIt6MbjRk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Ubi libertas, ibi patria. iQEVAwUBP9lKduWR/8lWBVPnAQOEpAf+JDlWsc87iZgzpngGQmrtaMr4+u4ihudz zAP2TK5mf0jTk2lCnoh9EoFgRJJwgIOTx9JpZEbudwx/2wZtFM8Y/WyAOehU3LNo TnXlHS+I4Tv/88dEaVm8gyhhpeeVHe6Rq6AV1mD7IXtnKsOw1eFh7mQ8RVUUu0Vl YgYWzKSw+5KM6H35ifxbXV5GvkeSrlzB6c7ZlfcZTQWt47K22mNRgXeTGMeVURWg srab8zkin8qWWXeVL/vCM27zR0KJWY5jZ0UTerctw70qFDp+5WZ+hLWPA694Fico m8eU5RgQomKaszh1YbSCVG/GwVC77PJMNItQb0EV1unhZIyBTdpo2Q== =yJWd -----END PGP SIGNATURE----- --YG0IFkGWIt6MbjRk-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBJ4Lib089716 for ; Thu, 11 Dec 2003 11:04:21 -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 hBBJ4LS9089715 for ietf-openpgp-bks; Thu, 11 Dec 2003 11:04:21 -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 hBBJ4Kib089710 for ; Thu, 11 Dec 2003 11:04:20 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 6E8CE69B35; Thu, 11 Dec 2003 14:04:21 -0500 (EST) Message-ID: <3FD8BF09.551E6238@systemics.com> Date: Thu, 11 Dec 2003 14:01:29 -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: David Shaw Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> <20031211180402.GA16475@jabberwocky.com> 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: David Shaw wrote: ... Sorry, I should have spelt this out: > > On reflection, I think it should not be permitted. > > > > The reason for this is that when you combine > > it with the line slicing behaviour, then some > > games are possible: > > > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > > > > > Could result in an embarressing split. Such as: Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial When the line slicing behaviour is set to (about) column 42. > This isn't very complicated. I'd be quite surprised to hear of any > parser that didn't do: > > a) Find the leftmost colon-space. > b) The string to the left is the key. > c) The string to the right is the value. How do parsers handle the above case? Not that it's important. The thing to realise here is that the additional separator's presence, coupled with the ability of line slicing by mailers, introduces an exceptional case that's simply better off made illegal. The spirit of ascii armouring is to get the message through in the face of aggressive and unpredictable actions of many users' mailers. In this case, I think this spirit is preserved by making the optional Armor Headings as simple as possible, and encouraging strict legality. iang PS: actually, the above case is "legal". If there was no separator in the second split line, then the armouring is broken ("OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor."), and the message should not be accepted. But that's hardly a reliable strategy. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBI5oib087543 for ; Thu, 11 Dec 2003 10:05:50 -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 hBBI5nRa087542 for ietf-openpgp-bks; Thu, 11 Dec 2003 10:05:49 -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 hBBI5mib087530 for ; Thu, 11 Dec 2003 10:05:48 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hBBI42a16928 for ietf-openpgp@imc.org; Thu, 11 Dec 2003 13:04:02 -0500 Date: Thu, 11 Dec 2003 13:04:02 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow Message-ID: <20031211180402.GA16475@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> <3FD8A6A0.B609DDEB@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FD8A6A0.B609DDEB@systemics.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 (93% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Dec 11, 2003 at 12:17:20PM -0500, Ian Grigg wrote: > > Ian Grigg wrote: > > > > Peter Gutmann wrote: > > > > Is it really a line-length issue, or something else like the > > > presence of the second colon in the line for something that's > > > scanning for :? > > Peter brought up the issue of the additional > ": " separators and I opined that the draft > should be clearer on this issue. > > On reflection, I think it should not be permitted. > > The reason for this is that when you combine > it with the line slicing behaviour, then some > games are possible: > > Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial > > > Could result in an embarressing split. Now, that's a superficial > and ignorable result, and only presented for the sake of showing > what might happen. > > I can see no good reason to leave multiple separators as permitted > in the ID, so I'd suggest adding a simple restriction such as "Only > one separator is permitted." I disagree we need to change anything here. There is already only one separator permitted. Using your example: Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial The second instance of colon-space is NOT a separator. It's just part of the value. This isn't very complicated. I'd be quite surprised to hear of any parser that didn't do: a) Find the leftmost colon-space. b) The string to the left is the key. c) The string to the right is the value. That's how email works (note the subject line of this message has two colons!), how news works, and how OpenPGP works. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBBHKEib085668 for ; Thu, 11 Dec 2003 09:20:14 -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 hBBHKEca085667 for ietf-openpgp-bks; Thu, 11 Dec 2003 09:20:14 -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 hBBHKBib085659 for ; Thu, 11 Dec 2003 09:20:11 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id C3F3269B2D; Thu, 11 Dec 2003 12:20:11 -0500 (EST) Message-ID: <3FD8A6A0.B609DDEB@systemics.com> Date: Thu, 11 Dec 2003 12:17:20 -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: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> <3FD7529D.B2EEAF25@systemics.com> 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: Ian Grigg wrote: > > Peter Gutmann wrote: > > Is it really a line-length issue, or something else like the presence of the > > second colon in the line for something that's scanning for :? Peter brought up the issue of the additional ": " separators and I opined that the draft should be clearer on this issue. On reflection, I think it should not be permitted. The reason for this is that when you combine it with the line slicing behaviour, then some games are possible: Version: 1.0.0 non-commercial, upgrade to Version: 2.0.0-commercial Could result in an embarressing split. Now, that's a superficial and ignorable result, and only presented for the sake of showing what might happen. I can see no good reason to leave multiple separators as permitted in the ID, so I'd suggest adding a simple restriction such as "Only one separator is permitted." As another observation, the use of the term "Armour Headers" appears overloaded. Could this be clarified by changing the current usage into: Armour Headers: -----.*PGP.*----- Optional Headers: Version: //// Or even Comment Headers, or Optional Armour Headers, or Optional Comments? iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBAH9Uib049534 for ; Wed, 10 Dec 2003 09:09:30 -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 hBAH9UFW049533 for ietf-openpgp-bks; Wed, 10 Dec 2003 09:09:30 -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 hBAH9Sib049527 for ; Wed, 10 Dec 2003 09:09:29 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id B1CCB69A84; Wed, 10 Dec 2003 12:09:29 -0500 (EST) Message-ID: <3FD7529D.B2EEAF25@systemics.com> Date: Wed, 10 Dec 2003 12:06:37 -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: Peter Gutmann Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> 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: Peter Gutmann wrote: > > Ian Grigg writes: > > >It appears that PGP 8 is breaking the spirit and intent of the ascii > >armouring format, if not the "letter of the law." > > > >What it is doing is in essence putting in a Version that is too long for some > >mailers' line slicing paramaters. The result is that people receive this: > > > >Version: PGP 8.0.2 - not licensed for commercial use: > >www.pgp.com > > Is it really a line-length issue, or something else like the presence of the > second colon in the line for something that's scanning for :? Well, the slicing that is occuring is in the transmission process, in this case, so I am theorising that this is a line length issue. (I haven't been able to check this, because the person sending the dodgy email doesn't understand what I am asking... That's the way it is in userland.) But you raise a point I hadn't seen, the line above is badly formatted in a second way, in that it includes two ": " separators. Examination of the para in section 6.2, page 50: The format of an Armor Header is that of a key-value pair. A colon (':' 0x38) and a single space (0x20) separate the key and value. OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. Unknown keys should be reported to the user, but OpenPGP should continue to process the message. indicates that this is not explicitly ruled against, but I'd say it is implicit stated that only one separator is permitted. Or, in the alternate, if two separators are permitted, then the text should be clarified, as different parsing strategies will result in confusion. Should there be only one ": " or are additionals permitted in the value and thereafter ignored? As the ID says "OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor," I suggest this be explicitly clarified to improve interworkability. > For a mailer to be unable to handle a 66-char line sounds pretty... broken. My view is that when it comes to lines, all mailers seem broken. But what do I know? Mostly, this seems to occur when going from one distinct community to another. Within a particular flavour of mailers, they all understand each other, but across distinct communities, the mailers have different ways of dealing with things. I did a quick straw poll today, and found 76,72,76,58,72,56,72,72 A few points: * In communities where they always reply with full interpolation, and full (audit) chains of replies, sometimes people set the width to be very narrow, because they end up with scores (i.e., 20) series of replies, which scan across to the right hand columns. * from the *same* email, 50-72! Which makes me think that this guy had his mailer set up for proportional text. Another couple of emails I wasn't able to work out what was going on, but inserted lines seemed to be part of the bug set. * I've just noticed another thing about the community stuff - Macs tend to interpret a trailing space as a continuation character, and that sometimes works and sometimes doesn't (I suppose it always works on Macs). * If you look at my original mail, you will see that the sliced line I presented was broken, but in Will Price's reply, it had been repaired, presumably by his mailer, so in his view, there was apparently nothing wrong! iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA6lEib061851 for ; Tue, 9 Dec 2003 22:47:14 -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 hBA6lEdR061850 for ietf-openpgp-bks; Tue, 9 Dec 2003 22:47:14 -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.10/8.12.8) with ESMTP id hBA6l8ib061786 for ; Tue, 9 Dec 2003 22:47:13 -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 9698334015; Wed, 10 Dec 2003 19:46:39 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hBA6lAE28729; Wed, 10 Dec 2003 19:47:10 +1300 Date: Wed, 10 Dec 2003 19:47:10 +1300 Message-Id: <200312100647.hBA6lAE28729@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: iang@systemics.com Subject: Re: armour pierced with PGP 8 arrow Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian Grigg writes: >It appears that PGP 8 is breaking the spirit and intent of the ascii >armouring format, if not the "letter of the law." > >What it is doing is in essence putting in a Version that is too long for some >mailers' line slicing paramaters. The result is that people receive this: > >Version: PGP 8.0.2 - not licensed for commercial use: >www.pgp.com Is it really a line-length issue, or something else like the presence of the second colon in the line for something that's scanning for :? For a mailer to be unable to handle a 66-char line sounds pretty... broken. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA2lvib034671 for ; Tue, 9 Dec 2003 18:47: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 hBA2lvKZ034670 for ietf-openpgp-bks; Tue, 9 Dec 2003 18:47:57 -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 hBA2luib034665 for ; Tue, 9 Dec 2003 18:47:57 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 0DF4B69A7C; Tue, 9 Dec 2003 21:47:59 -0500 (EST) Message-ID: <3FD688B2.77248B40@systemics.com> Date: Tue, 09 Dec 2003 21:45:06 -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: Will Price Cc: ietf-openpgp@imc.org Subject: Re: armour pierced with PGP 8 arrow References: <3FD6164C.BD573813@systemics.com> 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: Will Price wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I see no problem here and no need for any change to the draft or a > product. 66 columns is at least 10 columns shorter than any > conventional recommended line length. If your mailer wrapped that line, > it would be almost equally likely to wrap the ASCII armor itself (65 > columns -- 11 less than the OpenPGP limit). I've observed this problem many times, myself, but it didn't occur in this recent case. > In addition, your claims are patently contrary to the exact words and > spirit of the draft. Please see section 6.3 where it says: "The encoded > output stream must be represented in lines of no more than 76 > characters each." You are correct, I did not see that part, so it would appear that PGP 8 is within the letter of the draft. > Thus, whatever the problem you are seeing is, and based on observing > the line length used in your own message on this topic, it appears to > be related specifically to a low limit somewhere in your configuration, > it is not a fault of PGP nor the OpenPGP draft. This behaviour was observed with ordinary people out there with ordinary mailers, not my own (which is set to not slice lines at all). That is, users failed to communicate because their mailers sliced the lines. I make no comment on whether any particular product should change, rather, I was suggesting that there be attention brought to the line length issue within the draft. As line length in mailers is a moving target, one can only be general and flexible. As an aside, in the ascii armoured messages that my company produces, we used to use the same or a similar number as various other products (I guess that would be about 65), but dropped it down to 48 about 2 years back because of continual problem with mailers. That's just an old observation, to match the new one I've just seen in users' setups - if nobody else has seen those problems then there isn't an issue. I don't imagine that two data points are representative. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA14uib031217 for ; Tue, 9 Dec 2003 17:04: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 hBA14uDi031216 for ietf-openpgp-bks; Tue, 9 Dec 2003 17:04:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cyphers.net (rc6.cyphers.net [64.220.173.136]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hBA14sib031205 for ; Tue, 9 Dec 2003 17:04:54 -0800 (PST) (envelope-from wprice@cyphers.net) Received: from keys.cyphers.net (account wprice [64.220.173.170] verified) by cyphers.net (CommuniGate Pro SMTP 4.1.8) with ESMTP id 1393744 for ietf-openpgp@imc.org; Tue, 09 Dec 2003 17:04:57 -0800 Received: from cypher.pgp.com ([63.251.255.202]) by keys.cyphers.net (PGP Universal service); Tue, 09 Dec 2003 17:04:56 -0800 Received: from [63.251.255.202] by cypher.pgp.com (PGP Universal service); Tue, 09 Dec 2003 17:04:56 -0800 X-PGP-Universal: processed Mime-Version: 1.0 (Apple Message framework v606) In-Reply-To: <3FD6164C.BD573813@systemics.com> References: <3FD6164C.BD573813@systemics.com> Message-Id: From: Will Price Subject: Re: armour pierced with PGP 8 arrow Date: Tue, 9 Dec 2003 17:04:48 -0800 To: ietf-openpgp@imc.org X-Mailer: Apple Mail (2.606) Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see no problem here and no need for any change to the draft or a product. 66 columns is at least 10 columns shorter than any conventional recommended line length. If your mailer wrapped that line, it would be almost equally likely to wrap the ASCII armor itself (65 columns -- 11 less than the OpenPGP limit). In addition, your claims are patently contrary to the exact words and spirit of the draft. Please see section 6.3 where it says: "The encoded output stream must be represented in lines of no more than 76 characters each." Thus, whatever the problem you are seeing is, and based on observing the line length used in your own message on this topic, it appears to be related specifically to a low limit somewhere in your configuration, it is not a fault of PGP nor the OpenPGP draft. - - Will On Dec 9, 2003, at 10:37 AM, Ian Grigg wrote: > It appears that PGP 8 is breaking the spirit and intent > of the ascii armouring format, if not the "letter of the > law." > > What it is doing is in essence putting in a Version that > is too long for some mailers' line slicing paramaters. > The result is that people receive this: > > > > > -----BEGIN PGP MESSAGE----- > Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com > > qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm > ... > -----END PGP MESSAGE----- > > > > Now, reading from the 28th October 2003 draft, it appears > that there is no comment on line length - but there are > comments on the line sanctity and on UTF-8 in the Comment > field that are apropos. > > To cut the gordian knot, I propose: > > > 1. changing the comment at the end of p49 to > include a warning on line length: > > ... The > header lines, therefore, MUST start at the beginning of a line, and > MUST NOT have text following them on the same line (BEWARE OF > USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS). > > (addition in caps...) (as a suggestion only). > > > 2. moving the "Comment" comment out of that > section and/or expanding it to include a > comment about long lines. Something like: > > > Armor Header contents are not strictly defined, so may > include UTF-8 strings and long lines. > > However, the point of Armoring is to provide a clean > textual representation that survives transport over > pernickety systems such as email. Consequently, if an > Armor Header includes such things as characters outside > the range of US-ASCII or too many characters, the Armored > message may not survive transport. > > > (At the bottom of page 50.) (because it seems > to apply equally to all armoured headers). > > > 3. It also seemed plausible to put in > "rule of thumb" that the line length > of headers should be no longer than > the ascii armoured body line length. > > > I'm not wedded to any of those, just > thinking out aloud some thoughts on > improving the ID so it best serves. > > iang > > > PS: To compound this, it appears that GPG > (1.2.2) is also rejecting these messages > out of hand. It would appear that GPG is > in the right here, as there is this strict > rule: > > "OpenPGP should consider improperly formatted Armor Headers to be > corruption of the ASCII Armor. ..." > > (top of page 50). > - -- Will Price, VP Engineering PGP Corporation -----BEGIN PGP SIGNATURE----- Version: PGP Universal Satellite 1.1.0 (Build 411) iQA/AwUBP9ZxOKy7FkvPc+xMEQLL6wCg32HE6JlNzuvWscDLSWB6uFiY2IgAn2Bz QKDr+Pe9H5LUQTrGbbkHpzvf =aof8 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB9Ie0ib014882 for ; Tue, 9 Dec 2003 10:40:00 -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 hB9Ie06e014881 for ietf-openpgp-bks; Tue, 9 Dec 2003 10:40:00 -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 hB9Iduib014869 for ; Tue, 9 Dec 2003 10:39:57 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id AACC469B2C; Tue, 9 Dec 2003 13:39:52 -0500 (EST) Message-ID: <3FD6164C.BD573813@systemics.com> Date: Tue, 09 Dec 2003 13:37:00 -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: armour pierced with PGP 8 arrow 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: It appears that PGP 8 is breaking the spirit and intent of the ascii armouring format, if not the "letter of the law." What it is doing is in essence putting in a Version that is too long for some mailers' line slicing paramaters. The result is that people receive this: -----BEGIN PGP MESSAGE----- Version: PGP 8.0.2 - not licensed for commercial use: www.pgp.com qANQR1DBw04Dxrpn2akpjMkQD/457fxRygbnZG7jAssMb4JuMeXqZdXmMhcGetrm ... -----END PGP MESSAGE----- Now, reading from the 28th October 2003 draft, it appears that there is no comment on line length - but there are comments on the line sanctity and on UTF-8 in the Comment field that are apropos. To cut the gordian knot, I propose: 1. changing the comment at the end of p49 to include a warning on line length: ... The header lines, therefore, MUST start at the beginning of a line, and MUST NOT have text following them on the same line (BEWARE OF USING LINES THAT ARE LONG ENOUGH TO BE SLICED BY MAILERS). (addition in caps...) (as a suggestion only). 2. moving the "Comment" comment out of that section and/or expanding it to include a comment about long lines. Something like: Armor Header contents are not strictly defined, so may include UTF-8 strings and long lines. However, the point of Armoring is to provide a clean textual representation that survives transport over pernickety systems such as email. Consequently, if an Armor Header includes such things as characters outside the range of US-ASCII or too many characters, the Armored message may not survive transport. (At the bottom of page 50.) (because it seems to apply equally to all armoured headers). 3. It also seemed plausible to put in "rule of thumb" that the line length of headers should be no longer than the ascii armoured body line length. I'm not wedded to any of those, just thinking out aloud some thoughts on improving the ID so it best serves. iang PS: To compound this, it appears that GPG (1.2.2) is also rejecting these messages out of hand. It would appear that GPG is in the right here, as there is this strict rule: "OpenPGP should consider improperly formatted Armor Headers to be corruption of the ASCII Armor. ..." (top of page 50). Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB5Bngib035340 for ; Fri, 5 Dec 2003 03:49:42 -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 hB5Bng7J035339 for ietf-openpgp-bks; Fri, 5 Dec 2003 03:49:42 -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.10/8.12.8) with ESMTP id hB5Bndib035331 for ; Fri, 5 Dec 2003 03:49:40 -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.10/8.12.9) with ESMTP id hB5BnY5C008634 for ; Fri, 5 Dec 2003 12:49:34 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.10/8.12.1/Submit) id hB5BnY0x008633 for ietf-openpgp@imc.org; Fri, 5 Dec 2003 12:49:34 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Removing Elgamal signatures Date: Fri, 5 Dec 2003 11:49:34 +0000 (UTC) Organization: IKS GmbH Jena Lines: 21 Message-ID: References: <20031204225135.GA7248@deneb.enyo.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1070624974 7896 217.17.192.37 (5 Dec 2003 11:49:34 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Fri, 5 Dec 2003 11:49:34 +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: * Florian Weimer wrote: > Lutz Donnerhacke wrote: >> I'd like to oppose. ElGamal signatures are still useful, > > Useful for what? I prefer more than one algorithm for a given task. That's all. My personal opinion is not relevant to the removal of this packet type. > objections to its design process), but this is no longer a convincing > justification since we now have RSA at our disposal. Do we use RSA right? Requiring SSP? > Are you confident that no additional implementation traps will > discovered? With RSA, I have some confidence that the most important > things are properly documented, but ElGamal signatures appear to be much > more problematic. Please keep in mind that this is the second case of > such an implementation trap for the ElGamal signature scheme. There are a lot of listed RSA attacks, too. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4Mpbib030161 for ; Thu, 4 Dec 2003 14:51:37 -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 hB4Mpa72030160 for ietf-openpgp-bks; Thu, 4 Dec 2003 14:51:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.enyo.de (mail.enyo.de [212.9.189.167]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB4MpYib030143 for ; Thu, 4 Dec 2003 14:51:35 -0800 (PST) (envelope-from fw@deneb.enyo.de) Received: from deneb.enyo.de ([212.9.189.171]) by mail.enyo.de with esmtp (Exim 4.24) id 1AS2K0-000116-TT; Thu, 04 Dec 2003 23:51:45 +0100 Received: from fw by deneb.enyo.de with local (Exim 4.24) id 1AS2Jr-0001zd-BI; Thu, 04 Dec 2003 23:51:35 +0100 Date: Thu, 4 Dec 2003 23:51:35 +0100 To: Lutz Donnerhacke Cc: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031204225135.GA7248@deneb.enyo.de> References: <873cc7uxjz.fsf@alberti.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i From: Florian Weimer Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz Donnerhacke wrote: > I'd like to oppose. ElGamal signatures are still useful, Useful for what? In the past, your primary argument seems to have been the avoidance of DSA (not because of patent problems, but because of rather theoretical objections to its design process), but this is no longer a convincing justification since we now have RSA at our disposal. > despite there is a charge of signatures with some algorithmic errors. > I'd prefer a paragraph describing the problem and advicing to not use > keys of this charge. Are you confident that no additional implementation traps will discovered? With RSA, I have some confidence that the most important things are properly documented, but ElGamal signatures appear to be much more problematic. Please keep in mind that this is the second case of such an implementation trap for the ElGamal signature scheme. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB255Iib027648 for ; Mon, 1 Dec 2003 21:05:18 -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 hB255IoT027647 for ietf-openpgp-bks; Mon, 1 Dec 2003 21:05:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB255Hib027642 for ; Mon, 1 Dec 2003 21:05:17 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 1 Dec 2003 21:05:15 -0800 Received: from callas.org ([63.73.97.181]) by bletchley.merrymeet.com (PGP Universal service); Mon, 01 Dec 2003 21:05:18 -0800 Date: Mon, 1 Dec 2003 21:05:28 -0800 Subject: Re: Removing Elgamal signatures Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Jon Callas To: OpenPGP Content-Transfer-Encoding: 7bit In-Reply-To: <873cc7uxjz.fsf@alberti.g10code.de> Message-Id: <256D894E-2485-11D8-8FA1-000A9568596C@callas.org> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm happy to remove it, if there's rough consensus that it be removed, myself. I just want to make sure that there is that consensus. Elgamal sigs have been controversial from the start. The main reason for them is to have a discrete-log public key system that parallels RSA in being able to both encrypt and sign. We've always known that Elgamal signatures were tetchy, and 2440 has finger-wagging in that direction, anyway. In 1998, there was more reason to have a discrete-log encrypt+sign key than there is in 2004. There's very little reason to have them today. Lutz has stated a preference for them remaining, but with exactly zero implementers of it, that sounds like something resembling rough consensus to remove them. If we *don't* remove them, then they are part of the standard, but an interesting part of the folklore. If a brand new implemented came to me and asked about them, I'd reply something like the following: "I don't see why you should implement them. They're a MAY, which means you don't have do. All signature algorithms are tetchy in that if you don't do them right, bad things can happen, but Elgamal sigs are even tetchier. The only people who did implement them removed them after some exasperating bugs showed up. If you implement them, then you have to make sure you don't put in some weird bug. If you do, people will say, 'I told you so.' If you do, anyone with a different implementation can't verify a signature -- you're the only one who does. I see a lot of bother for you and not much benefit. There are much better things for you to spend your time on." I then hear in my head, "So why didn't you remove them from 2440+ when you had the chance? If they're such a pain that no one does them, why are they there at all?" I don't have a good answer to that question. I say remove them, myself. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Lv1ib008950 for ; Mon, 1 Dec 2003 13:57: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 hB1Lv1N2008949 for ietf-openpgp-bks; Mon, 1 Dec 2003 13:57: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 hB1Luxib008941 for ; Mon, 1 Dec 2003 13:57:00 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id 04C3B69B29; Mon, 1 Dec 2003 16:57:01 -0500 (EST) Message-ID: <3FCBB87C.98B6371B@systemics.com> Date: Mon, 01 Dec 2003 16:54:04 -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: Re: Removing Elgamal signatures References: <873cc7uxjz.fsf@alberti.g10code.de> <3FCB9B01.4967C080@systemics.com> 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: Ian Grigg wrote: > > c. Some change has to be made, because there is a bug. Correction supplied by Micheal Young: > The bug is in the GnuPG implementation, not the specification. Thanks! Delete c. then. > [I'm neutral on whether to keep ElGamal signatures in the > specification, but I wouldn't consider this a compelling factor.] iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1Lcmib008264 for ; Mon, 1 Dec 2003 13:38:48 -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 hB1LcmZw008263 for ietf-openpgp-bks; Mon, 1 Dec 2003 13:38:48 -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 hB1Lclib008257 for ; Mon, 1 Dec 2003 13:38:47 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hB1LcmV06419 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 16:38:48 -0500 Date: Mon, 1 Dec 2003 16:38:48 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031201213848.GB4618@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <873cc7uxjz.fsf@alberti.g10code.de> <3FCB9B01.4967C080@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FCB9B01.4967C080@systemics.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 Waxing Gibbous (60% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Dec 01, 2003 at 02:48:17PM -0500, Ian Grigg wrote: > If there are O(1000) users of the ElGamal signature > algorithm, I'd say at first glance this does not qualify > as a major usage. > > Also, if GnuPG is the *only* implementation of this, > then that would seem to go against the spirit of the > "two implementations" rule. (Although, not breached > in practice, as it is only a small part, I would guess.) With regards to this point - very shortly, GnuPG will not be an implementation of this. The upcoming GnuPG (1.2.4) does not allow users to do anything with Elgamal sign+encrypt keys except revoke them. It will not encrypt to them, it will not sign with them. The next large release (1.4) will not implement Elgamal sign+encrypt at all. > One thing I am not sure of - what is it useful for? In the > sense, does it do something that is highly prized and wanted? In the past it was a patent-free signing algorithm that wasn't limited to a 1024 bit key and a 160 bit hash. Given that the RSA patent has expired, I see little benefit to Elgamal signatures that RSA signatures do not provide, and at the same time there are some significant advantages to RSA (like speed.) David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KPdib005837 for ; Mon, 1 Dec 2003 12:25:39 -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 hB1KPdFH005836 for ietf-openpgp-bks; Mon, 1 Dec 2003 12:25:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com ([129.33.1.37]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1KPbib005831 for ; Mon, 1 Dec 2003 12:25:38 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id PAA10782 for ; Mon, 1 Dec 2003 15:25:25 -0500 (EST) Message-ID: <3FCBA308.3090706@the-youngs.org> Date: Mon, 01 Dec 2003 15:22:32 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures References: <200312011646.hB1GkP808727@finney.org> In-Reply-To: <200312011646.hB1GkP808727@finney.org> 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: Hal Finney wrote: > It would be good to see these results made available because > they might turn out to be applicable to other types of keys > that we might consider in the future. While we're at it, I'd like the specification to include references to the research that was the rationalization for using a small "k" for encryption. Given that a full-width "k" is impractical (for cost reasons) and every implementation will be inclined to use a small "k", it's important that we make note of the security limitations. This is particularly true when they're based on the *relative* performance of known methods, which can change over time. [As I recall, the published PGP6 source code contained a comment with a reference. I don't have that handy, but perhaps someone here does.] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1JpEib004462 for ; Mon, 1 Dec 2003 11:51:14 -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 hB1JpEUB004461 for ietf-openpgp-bks; Mon, 1 Dec 2003 11:51:14 -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 hB1JpCib004455 for ; Mon, 1 Dec 2003 11:51:13 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id EA0CA69A94; Mon, 1 Dec 2003 14:51:13 -0500 (EST) Message-ID: <3FCB9B01.4967C080@systemics.com> Date: Mon, 01 Dec 2003 14:48:17 -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: Re: Removing Elgamal signatures References: <873cc7uxjz.fsf@alberti.g10code.de> 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: Lutz Donnerhacke wrote: > > * Werner Koch wrote: > > In the light of the recent GnuPG bug, where I accidently used the same > > small sized k for signature creation as it is used for encrypting, I'd > > very much like to drop the ElGamal signing ability all together from > > OpenPGP. AFAIK, GnuPG is the only implementation with support for > > these keys and by now the about 1100 known primary and subkeys should > > have been revoked. Thus there won't be any interoperability problem > > anymore. > > I'd like to oppose. ElGamal signatures are still useful, despite there is a > charge of signatures with some algorithmic errors. I'd prefer a paragraph > describing the problem and advicing to not use keys of this charge. Thinking about the case for removing ElGamal from the standard, here are the pluses that I see: a. The purpose of the standard is to document the greater good set of common and useful algorithms to which most implementation should try and implement. If there are O(1000) users of the ElGamal signature algorithm, I'd say at first glance this does not qualify as a major usage. Also, if GnuPG is the *only* implementation of this, then that would seem to go against the spirit of the "two implementations" rule. (Although, not breached in practice, as it is only a small part, I would guess.) b. Removing it from the standard would only mean that other implementations could then totally ignore it, instead of choosing to ignore it. Also, removing it from the standard does not mean it can't be used - it just means that it is then a private algorithm. If it later on proves to be of great use and other implementations adopt it, it can always be added back into a future version, or written into a informational draft. c. Some change has to be made, because there is a bug. So it might simply be a balance between removing it - easy? - and writing in the bug-fixed-text - not so easy? d. Less is much better. OpenPGP is already way too big and complex, which slows its implementation and thus slows its use, and its long term success. Against the removal: A. This is supposed to be very late in the game for the production of the standard. There should be very minor changes, if any. On balance, there seems to be a good case for removing it entirely! ( I speak here without any knowledge of the technical aspects of the algorithm, of course! Standard Dilbert comments apply... ) One thing I am not sure of - what is it useful for? In the sense, does it do something that is highly prized and wanted? That would perhaps be key in determining if removal is to be warranted at this late stage... iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1HVBib097900 for ; Mon, 1 Dec 2003 09:31: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 hB1HVBMe097899 for ietf-openpgp-bks; Mon, 1 Dec 2003 09:31:11 -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 hB1HVAib097894 for ; Mon, 1 Dec 2003 09:31:10 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hB1HVBl04480 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 12:31:11 -0500 Date: Mon, 1 Dec 2003 12:31:11 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031201173111.GA4304@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200312011646.hB1GkP808727@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200312011646.hB1GkP808727@finney.org> 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 Gibbous (60% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Dec 01, 2003 at 08:46:25AM -0800, Hal Finney wrote: > It would be good to see these results made available because they might > turn out to be applicable to other types of keys that we might consider > in the future. The paper is as yet unpublished, but the author's web page with contact info is http://www.di.ens.fr/~pnguyen/ David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1GwEib096468 for ; Mon, 1 Dec 2003 08:58:14 -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 hB1GwEu6096460 for ietf-openpgp-bks; Mon, 1 Dec 2003 08:58:14 -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 hB1GwCib096442 for ; Mon, 1 Dec 2003 08:58:12 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id hB1GwC304212 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 11:58:12 -0500 Date: Mon, 1 Dec 2003 11:58:12 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Message-ID: <20031201165812.GB3184@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <873cc7uxjz.fsf@alberti.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873cc7uxjz.fsf@alberti.g10code.de> 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 Gibbous (59% of Full) User-Agent: Mutt/1.5.5i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Nov 29, 2003 at 02:14:08PM +0100, Werner Koch wrote: > In the light of the recent GnuPG bug, where I accidently used the same > small sized k for signature creation as it is used for encrypting, I'd > very much like to drop the ElGamal signing ability all together from > OpenPGP. AFAIK, GnuPG is the only implementation with support for > these keys and by now the about 1100 known primary and subkeys should > have been revoked. Thus there won't be any interoperability problem > anymore. I agree with this. Not too long ago, we removed a handful of unused hash algorithms from the standard using the "less is more" rationale. I see this as a similar case. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1GlUib095887 for ; Mon, 1 Dec 2003 08:47:30 -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 hB1GlUmD095886 for ietf-openpgp-bks; Mon, 1 Dec 2003 08:47:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hB1GlTib095878 for ; Mon, 1 Dec 2003 08:47:29 -0800 (PST) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id hB1GkP808727 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 08:46:25 -0800 Date: Mon, 1 Dec 2003 08:46:25 -0800 From: "Hal Finney" Message-Id: <200312011646.hB1GkP808727@finney.org> To: ietf-openpgp@imc.org Subject: Re: Removing Elgamal signatures Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'd like to see some technical details about the attack, if they can be made available. The ElGamal signature formulas are: r = g^k mod p s = (H-rx)/k mod q The latter comes from rx+sk=H mod q. I gather from what Werner has said that choosing small x and k in this formula is unsafe. This looks similar to a lattice problem where there are relatively efficient articles for finding "small" vectors. But I am not that familiar with the mathematics. Incidentally, in trying to research this I found that the attack by Bleichenberger on poorly-chosen random numbers in DSA signatures had never been published. I'm not sure if that was a lattice based attack or not. It would be good to see these results made available because they might turn out to be applicable to other types of keys that we might consider in the future. 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 hB1EjFib085732 for ; Mon, 1 Dec 2003 06:45:15 -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 hB1EjFiN085731 for ietf-openpgp-bks; Mon, 1 Dec 2003 06:45:15 -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.10/8.12.8) with ESMTP id hB1EjDib085720 for ; Mon, 1 Dec 2003 06:45:13 -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.10/8.12.9) with ESMTP id hB1Ej806006040 for ; Mon, 1 Dec 2003 15:45:08 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.10/8.12.1/Submit) id hB1Ej8Qi006039 for ietf-openpgp@imc.org; Mon, 1 Dec 2003 15:45:08 +0100 To: ietf-openpgp@imc.org Path: not-for-mail From: Lutz Donnerhacke Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Removing Elgamal signatures Date: Mon, 1 Dec 2003 14:45:08 +0000 (UTC) Organization: IKS GmbH Jena Lines: 19 Message-ID: References: <873cc7uxjz.fsf@alberti.g10code.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1070289908 4051 217.17.192.37 (1 Dec 2003 14:45:08 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 1 Dec 2003 14:45:08 +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: > In the light of the recent GnuPG bug, where I accidently used the same > small sized k for signature creation as it is used for encrypting, I'd > very much like to drop the ElGamal signing ability all together from > OpenPGP. AFAIK, GnuPG is the only implementation with support for > these keys and by now the about 1100 known primary and subkeys should > have been revoked. Thus there won't be any interoperability problem > anymore. I'd like to oppose. ElGamal signatures are still useful, despite there is a charge of signatures with some algorithmic errors. I'd prefer a paragraph describing the problem and advicing to not use keys of this charge. > If we can't agree on that, I'd suggest to declare type 20 keys to be > Elgamal sign only - this way a new problem with this algorithm will > at least not affect the encryption use. It's only the parameter k, right? Type 20 keys are not limited to the small parameter.