From owner-ietf-openpgp@mail.imc.org Sat Nov 3 14:04:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17385 for ; Sat, 3 Nov 2001 14:04:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA3If7e24805 for ietf-openpgp-bks; Sat, 3 Nov 2001 10:41:07 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA3If6824801 for ; Sat, 3 Nov 2001 10:41:06 -0800 (PST) Received: from softhome.net ([207.180.179.68]) (AUTH: PLAIN jkane89@softhome.net) by softhome.net with esmtp; Sat, 03 Nov 2001 11:34:08 -0700 Message-ID: <3BE43214.9557E0A3@softhome.net> Date: Sat, 03 Nov 2001 13:06:12 -0500 From: John J Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: pointers to openpgp-interop knowledge base? 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 Are there any sources online for the following? * contact info for people involved in interop testing * examples of non-conformant output (for testing) * examples of conformant output which have been documented to break certain implementations Should a page be set up to host this information? -- JJK From owner-ietf-openpgp@mail.imc.org Sat Nov 3 20:05:30 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19901 for ; Sat, 3 Nov 2001 20:05:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA40iox03143 for ietf-openpgp-bks; Sat, 3 Nov 2001 16:44:50 -0800 (PST) Received: from keyhole.dublin.hush.com (root@dublin.hush.com [193.95.161.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA40in803138 for ; Sat, 3 Nov 2001 16:44:49 -0800 (PST) Received: from Hush-intranet.dublin.hush.com (exchange.dublin.hush.com [192.168.0.29]) by keyhole.dublin.hush.com (8.11.1/8.9.3) with ESMTP id fA40lqj17748; Sun, 4 Nov 2001 00:47:52 GMT Received: by Hush-intranet.dublin.hush.com with Internet Mail Service (5.5.2650.21) id <41AH5DLF>; Sun, 4 Nov 2001 00:47:54 -0000 Message-ID: From: Brian Smith To: "'John J Kane'" , ietf-openpgp@imc.org Subject: RE: pointers to openpgp-interop knowledge base? Date: Sun, 4 Nov 2001 00:47:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://www.openpgp.org/technical/interoperability/ However, the information there is pretty limited. If anyone has contributions of the types described below, send them to me and I'll see that they're added to the site. Brian Smith Hush Communications > -----Original Message----- > From: John J Kane [mailto:jkane89@softhome.net] > Sent: 03 November 2001 18:06 > To: ietf-openpgp@imc.org > Subject: pointers to openpgp-interop knowledge base? > > ________________________________________________________ > > This message has NOT been ENCRYPTED and has NOT been SIGNED > ________________________________________________________ > > > Are there any sources online for the following? > > * contact info for people involved in interop testing > * examples of non-conformant output (for testing) > * examples of conformant output which have been > documented to break certain implementations > > Should a page be set up to host this information? > > -- > JJK > > From owner-ietf-openpgp@mail.imc.org Sun Nov 4 09:44:22 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13114 for ; Sun, 4 Nov 2001 09:44:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA4EMpk19880 for ietf-openpgp-bks; Sun, 4 Nov 2001 06:22:51 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA4EMn819876 for ; Sun, 4 Nov 2001 06:22:49 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id DAA13042; Mon, 5 Nov 2001 03:22:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA75086; Mon, 5 Nov 2001 03:22:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 5 Nov 2001 03:22:41 +1300 (NZDT) Message-ID: <200111041422.DAA75086@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, jkane89@softhome.net Subject: Re: pointers to openpgp-interop knowledge base? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John J Kane wrote: >Are there any sources online for the following? > > * contact info for people involved in interop testing > * examples of non-conformant output (for testing) > * examples of conformant output which have been documented to break certain > implementations I've found that just using the various options of PGP 5.0 (which is not-quite- OpenPGP), 6.5.x, and GPG will give you all the quirks and peculiarities you need. Once you've made sure you can read what they produce, you should also check that they can read what you produce. Peter. From owner-ietf-openpgp@mail.imc.org Sun Nov 4 12:27:56 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14613 for ; Sun, 4 Nov 2001 12:27:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA4H8Eg11871 for ietf-openpgp-bks; Sun, 4 Nov 2001 09:08:14 -0800 (PST) Received: from hotmail.com (oe65.law3.hotmail.com [209.185.240.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA4H8C811862 for ; Sun, 4 Nov 2001 09:08:12 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Nov 2001 09:08:09 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <200111041422.DAA75086@ruru.cs.auckland.ac.nz> Subject: Re: pointers to openpgp-interop knowledge base? Date: Sun, 4 Nov 2001 12:07:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 04 Nov 2001 17:08:09.0177 (UTC) FILETIME=[470C6490:01C16553] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 - ----- Original Message ----- From: "Peter Gutmann" To: ; Sent: Sunday, November 04, 2001 9:22 AM Subject: Re: pointers to openpgp-interop knowledge base? > I've found that just using the various options of PGP 5.0 (which is > not-quite- OpenPGP), 6.5.x, and GPG will give you all the quirks and > peculiarities you need. Once you've made sure you can read what they > produce, you should also check that they can read what you produce. > > Peter. short summary of intercompatibility, and incompatibilities: messages from any pgp version can be read and verified by gpg {with the idea plugin}, except if a shared key/split key system is used [gpg can encrypt to a split key, but not sign or decrypt with a shared key system] messages from gpg using the throw-key id switch, cannot be read by 'any' version of pgp {except for Disastry's 2.6.3i multi 5} messages from gpg using mdc, cannot be read by any pgp version prior to 7.xx {6.5.8ckt is an exception, having a patch to ignore the mdc packets} messages from 7.xx using twofish or aes, cannot be decrypted by pgp versions prior to 7.xx, but signatures can be verified {again, 6.5.8ckt is an exception} messages using an RSA v4 key, can be decrypted, and can be verified, by pgp versions prior to 7.xx, but, for some reason, not, if the message is 'both' signed and encrypted messages signed with ripemd-160 or sha-1, can be verified by all pgp versions greater than 2.6.x, even if they do not use them to sign with for a particular key type hope this is useful, please correct if there are any mistakes or oversights, thanks, vedaal -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: KeyID: 0x6A05A0B785306D25 Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA iQEVAwUBO+Vzv2oFoLeFMG0lAQM+LQgAlt+ExlozIUSER30Ru/umGr/U3vPrtNzd 8naUSPJhjQEpB1usLpALy6Oj/uw8/2sGuXmjZ371+rR7Lr8IlI4/YMZw8ufKIjGN zfPlOEHyd64SO3bDsWrzi9sJ+6dzSif/JA/t6Uxl2mDCWAxmhigdXfbEM/USYxAR hPzjSjqEXLOhRuDxEe82Zpb9hhzShgayfJmTTR6dSqPRMbT92FVDs9pqYnlb1BwR 5dKWBG0dP6HIDWEnAaLyoOQodxoJA/b9wat81uEOvelvbHIwkKeKsI21uylHBy9u QU01nlWe6tinjdzm+tiriqOBMjAbqSHahgYTnV9cCdPGygyMYXC8rg== =tENm -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Nov 4 15:53:55 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16071 for ; Sun, 4 Nov 2001 15:53:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA4KTfO25131 for ietf-openpgp-bks; Sun, 4 Nov 2001 12:29:41 -0800 (PST) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA4KTd825127 for ; Sun, 4 Nov 2001 12:29:39 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA23628 for ; Sun, 4 Nov 2001 12:29:25 -0800 Date: Sun, 4 Nov 2001 12:29:25 -0800 (PST) From: Len Sassaman X-Sender: To: Subject: Re: pointers to openpgp-interop knowledge base? In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 4 Nov 2001, vedaal wrote: > messages from any pgp version can be read and verified by gpg {with the > idea plugin}, > except if a shared key/split key system is used > [gpg can encrypt to a split key, but not sign or decrypt with a shared key > system] > > messages from gpg using the throw-key id switch, cannot be read by 'any' > version > of pgp {except for Disastry's 2.6.3i multi 5} > > messages from gpg using mdc, cannot be read by any pgp version prior to > 7.xx > {6.5.8ckt is an exception, having a patch to ignore the mdc packets} > > messages from 7.xx using twofish or aes, cannot be decrypted by pgp > versions prior > to 7.xx, but signatures can be verified > {again, 6.5.8ckt is an exception} > > messages using an RSA v4 key, can be decrypted, and can be verified, by pgp > versions > prior to 7.xx, but, for some reason, not, if the message is 'both' signed > and encrypted > > messages signed with ripemd-160 or sha-1, can be verified by all pgp > versions greater > than 2.6.x, even if they do not use them to sign with for a particular key > type > > > hope this is useful, > > please correct if there are any mistakes or oversights, Well, you've left out GnuPG versions. GnuPG hasn't always been able to handle everything you mention. GnuPG of any version produces messages signed with v3 keys encrypted in v3 format that PGP cannot decrypt. In the implementation nits, it is noted that PGP 5.x cannot verify v4 sigs on non-v4 material. Actually, 6.x cannot either, but 7.x and greater can. Then there's the ElGamal signing-keys that GnuPG generates. I don't know what else supports them. Also, signing subkeys are probably a problem with a lot of other implementations as well. We have no idea what Hushmail's interop status is, since there appears to be no way to either get access to Hushmail users' public keys in order to verify their signatures, or import non-Hushmail users' keys into the Hushmail system to encrypt to them. ...etc. I could keep throwing things off the top of my head -- but shouldn't we have some formal system for listing all of this? -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson From owner-ietf-openpgp@mail.imc.org Mon Nov 5 04:51:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09968 for ; Mon, 5 Nov 2001 04:51:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA59VC800197 for ietf-openpgp-bks; Mon, 5 Nov 2001 01:31:12 -0800 (PST) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA59VA800184 for ; Mon, 5 Nov 2001 01:31:11 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 05 Nov 2001 10:21:57 +0200 Message-ID: <3BE65A35.79D43134@saiknes.lv> Date: Mon, 05 Nov 2001 11:21:57 +0200 From: disastry@saiknes.lv Organization: disastry.NO.SPaM.NET X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: pointers to openpgp-interop knowledge base? 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Len Sassamanwrote: > > GnuPG of any version produces messages signed with v3 keys encrypted in v3 > format that PGP cannot decrypt. except PGP 2.6.3ia-multi05, I modified it so that it can decrypt/verify these GnuPG produced non OpenPGP compliant messages. > In the implementation nits, it is noted that PGP 5.x cannot verify v4 sigs > on non-v4 material. Actually, 6.x cannot either, but 7.x and greater can. even PGP 7.x have problems with v4 sigs. it can verify v4 clearsignatures and detached signatures but not one pass signatures. PGP 6.5.8ckt06 can verify all v4 signatures. > Then there's the ElGamal signing-keys that GnuPG generates. I don't know > what else supports them. PGP 6.5.8ckt06 does. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBO+Y97zBaTVEuJQxkEQNoFACfeSh00qrCkaDgDcNQ/e3lCiSrtIIAoIHw zLRMMcdbox/lYo1m+oEzQ87c =Sq+J -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Nov 5 16:24:43 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08292 for ; Mon, 5 Nov 2001 16:24:43 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5L0To15814 for ietf-openpgp-bks; Mon, 5 Nov 2001 13:00:29 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5L0M815809 for ; Mon, 5 Nov 2001 13:00:27 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA5L0A9I006913; Mon, 5 Nov 2001 13:00:12 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Mon, 5 Nov 2001 12:45:33 -0800 To: Len Sassaman From: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:29 PM -0800 11/4/01, Len Sassaman wrote: > >I could keep throwing things off the top of my head -- but shouldn't we >have some formal system for listing all of this? Yes. Both Brian Smith and John Kane have volunteered to maintain the information. I've asked them to collaborate on maintaining the pages. My preference is we set something up under openpgp.org site. openpgp.org is a computer at Phil Zimmermann's house. There's other stuff I would like to see there, but interoperability info would be a Real Good Thing to get 2440 to DRAFT. I have a program to contribute which will read openpgp files and report on their structure. John Callas wrote the original version, and I've been updating it for 2440. It's not a complete implementation of 2440. But it locates packet boundaries, identifies packet types, and describes the plaintext portions of packets. If people send me files, I'll run them through my parser, and tell you what happens. The program runs on my Mac, but should be reasonably portable to other systems. I'll publish it on openpgp.org, as soon as we make a suitable place. I've heard tell of similar programs, but I don't have particular knowledge of any. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Mon Nov 5 23:39:41 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16247 for ; Mon, 5 Nov 2001 23:39:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA64NlO24683 for ietf-openpgp-bks; Mon, 5 Nov 2001 20:23:47 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA64Nj824679 for ; Mon, 5 Nov 2001 20:23:45 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id NAA29628 for ; Tue, 6 Nov 2001 13:23:45 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA10873 for ; Tue, 6 Nov 2001 13:23:44 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA09176 for ; Tue, 6 Nov 2001 13:23:44 +0900 (JST) Date: Tue, 06 Nov 2001 13:24:24 +0900 (JST) Message-Id: <20011106.132424.68557949.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: pointers to openpgp-interop knowledge base? From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: X-Mailer: Mew version 3.0.50 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 From: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? > I have a program to contribute which will read openpgp files and > report on their structure. John Callas wrote the original version, > and I've been updating it for 2440. It's not a complete > implementation of 2440. But it locates packet boundaries, identifies > packet types, and describes the plaintext portions of packets. Another PGP parser can be found: http://pgp.iijlab.net/pgpdump.html Web interface is also available. --Kazu From owner-ietf-openpgp@mail.imc.org Tue Nov 6 15:00:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00827 for ; Tue, 6 Nov 2001 15:00:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6Jc0f06280 for ietf-openpgp-bks; Tue, 6 Nov 2001 11:38:00 -0800 (PST) Received: from hotmail.com (oe18.law3.hotmail.com [209.185.240.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6Jbx806274 for ; Tue, 6 Nov 2001 11:37:59 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Nov 2001 11:37:52 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <20011106.132424.68557949.kazu@iijlab.net> Subject: Re: pointers to openpgp-interop knowledge base? Date: Tue, 6 Nov 2001 14:33:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 06 Nov 2001 19:37:52.0647 (UTC) FILETIME=[8670A170:01C166FA] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Kazu Yamamoto (????)" To: Sent: Monday, November 05, 2001 11:24 PM Subject: Re: pointers to openpgp-interop knowledge base? > Another PGP parser can be found: > http://pgp.iijlab.net/pgpdump.html > > Web interface is also available. > > --Kazu have tried the web interface, with a peculiar result: encrypted a message to an rsa key using gpg with the preference set to twofish, decrypting with gpg showed algorithm 10, as expected. using the pgp dump web interface, it identified the message as using mdc packets, [also as expected], but listed the algorithm as 1 {a 'default ' listing for 'idea' once an rsa key is identified, even though 'idea' was not used?} is this just the web interface, or does the parser do this too? vedaal From owner-ietf-openpgp@mail.imc.org Tue Nov 6 15:37:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02497 for ; Tue, 6 Nov 2001 15:37:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6KKNk07624 for ietf-openpgp-bks; Tue, 6 Nov 2001 12:20:23 -0800 (PST) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6KKL807620 for ; Tue, 6 Nov 2001 12:20:21 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA03769; Tue, 6 Nov 2001 12:19:45 -0800 Date: Tue, 6 Nov 2001 12:19:45 -0800 (PST) From: Len Sassaman X-Sender: To: John W Noerenberg II cc: Subject: Re: pointers to openpgp-interop knowledge base? In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 Nov 2001, John W Noerenberg II wrote: > I've heard tell of similar programs, but I don't have particular > knowledge of any. -- GnuPG has such a parser built into it. Also, there's a perl script written by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing. From owner-ietf-openpgp@mail.imc.org Tue Nov 6 21:04:07 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08157 for ; Tue, 6 Nov 2001 21:04:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA71hSY15451 for ietf-openpgp-bks; Tue, 6 Nov 2001 17:43:28 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA71hQ815447 for ; Tue, 6 Nov 2001 17:43:27 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA25692; Wed, 7 Nov 2001 10:43:19 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA10976; Wed, 7 Nov 2001 10:43:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA01668; Wed, 7 Nov 2001 10:43:18 +0900 (JST) Date: Wed, 07 Nov 2001 10:43:58 +0900 (JST) Message-Id: <20011107.104358.125124924.kazu@iijlab.net> To: vedaal@hotmail.com Cc: ietf-openpgp@imc.org Subject: Re: pointers to openpgp-interop knowledge base? From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <20011106.132424.68557949.kazu@iijlab.net> X-Mailer: Mew version 3.0.50 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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 From: "vedaal" Subject: Re: pointers to openpgp-interop knowledge base? > using the pgp dump web interface, it identified the message as using mdc > packets, [also as expected], but listed the algorithm as 1 {a 'default ' > listing for 'idea' once an rsa key is identified, even though 'idea' was > not used?} Please send such a report directly to me, not to the entire list. Please send me a sample packet which causes your problem. I will fix it if it's a bug. --Kazu From owner-ietf-openpgp@mail.imc.org Tue Nov 6 23:43:39 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12540 for ; Tue, 6 Nov 2001 23:43:39 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA74ImD18109 for ietf-openpgp-bks; Tue, 6 Nov 2001 20:18:48 -0800 (PST) Received: from smtprelay8.dc2.adelphia.net (smtprelay8.dc2.adelphia.net [64.8.50.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA74Ie818104 for ; Tue, 6 Nov 2001 20:18:46 -0800 (PST) Received: from mwyoung ([24.48.51.230]) by smtprelay8.dc2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GMEXB000.K08 for ; Tue, 6 Nov 2001 23:18:36 -0500 Message-ID: <009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <20011106.132424.68557949.kazu@iijlab.net> Subject: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) Date: Tue, 6 Nov 2001 23:17:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- > using the pgp dump web interface, it identified the message as using mdc > packets, [also as expected], but listed the algorithm as 1 {a 'default ' > listing for 'idea' once an rsa key is identified, even though 'idea' was > not used?} The algorithm identifier lives in material encrypted under the public key. Without the private key, all the parser could do is guess. (Does this parser have the ability to decrypt the contents even if the unprotected private key were present?) The MDC packet itself is encrypted under the session key. Again, the parser wouldn't be able to verify it. When you say it "identified the message as using mdc packets", I presume you mean that it noted that a "symmetrically encrypted integrity protected data packet" (tag 18) was present at the beginning, not that there was a valid MDC packet, right? On that note, I've asked a couple of times about the way GnuPG generates these packets, but I have never seen an authoritative answer. The issue was that GnuPG used an old-style indeterminate-length packet for the plaintext before the MDC (see my message of August 23 and any followup discussion for details). Should this be legal? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO+i1v2NDnIII+QUHAQEDuwf/RDBc0LbP8jwwg6T6y0GQGqTOBUbvWRpC ClbmXN2XKfYt1g47cxBVc3Tg2NWD0YSFcdhguvtBb9fwQd+7YIwakLmJ/z52NhbJ jTA/eAA2Y1blYYAn43whIatogEP1R3ssvqnvpo/awT4UEryxfV5oVh4sZZ/m9yCb EzMolf6CKy2ocin7a6t1Ix71pevpTiYsufsF45ju6QvRSvZOG2pzTYasGZpfEIgQ 75yRZqOhSGI4MfLxE/MzsGHwBZlDotDoLyb3tfXCoGKhRFTCOX2ZN1/YeSthvkA1 l8wdQxv1/gWOEQ0tr4xtbopliFH8QvRSVq/Eznjtr4bg2jIWJNXaZg== =yQeY -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Nov 7 03:24:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29254 for ; Wed, 7 Nov 2001 03:24:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA789d004055 for ietf-openpgp-bks; Wed, 7 Nov 2001 00:09:39 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA789b804044 for ; Wed, 7 Nov 2001 00:09:37 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 161NxH-0000RA-00; Wed, 07 Nov 2001 09:21:03 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 161NnD-00046r-00; Wed, 07 Nov 2001 09:10:39 +0100 To: "Michael Young" Cc: Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) References: <20011106.132424.68557949.kazu@iijlab.net> <009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Wed, 07 Nov 2001 09:10:39 +0100 In-Reply-To: <009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> ("Michael Young"'s message of "Tue, 6 Nov 2001 23:17:56 -0500") Message-ID: <87r8rbknls.fsf@alberti.gnupg.de> Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > answer. The issue was that GnuPG used an old-style indeterminate-length > packet for the plaintext before the MDC (see my message of August 23 But only if the plaintext is a compressed packet - right? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Wed Nov 7 11:15:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14157 for ; Wed, 7 Nov 2001 11:15:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA7FpWO25659 for ietf-openpgp-bks; Wed, 7 Nov 2001 07:51:32 -0800 (PST) Received: from walrus.jabberwocky.com (walrus.ne.mediaone.net [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA7FpU825655 for ; Wed, 7 Nov 2001 07:51:30 -0800 (PST) Received: from claude.kendall.akamai.com (ppp-216-158-59-64.cust.oldcity.dca.net [216.158.59.64]) by walrus.jabberwocky.com (8.9.3/8.9.3) with ESMTP id KAA31416; Wed, 7 Nov 2001 10:50:28 -0500 Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id KAA01516; Wed, 7 Nov 2001 10:50:17 -0500 Date: Wed, 7 Nov 2001 10:50:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Cc: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? Message-ID: <20011107105017.A1479@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org, John W Noerenberg II References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rabbi@quickie.net on Tue, Nov 06, 2001 at 12:19:45PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (60% of Full) X-Pointless-Random-Number: 96 X-Silly-Header: It sure is. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 06, 2001 at 12:19:45PM -0800, Len Sassaman wrote: > > On Mon, 5 Nov 2001, John W Noerenberg II wrote: > > > I've heard tell of similar programs, but I don't have particular > > knowledge of any. -- > > GnuPG has such a parser built into it. Also, there's a perl script written > by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing. The new (currently in test) GnuPG also comes with "gpgsplit" which breaks OpenPGP messages into their constituent packets. It's quite handy for comparing the output of two different programs. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Nov 7 13:37:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19761 for ; Wed, 7 Nov 2001 13:37:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA7IB7n05193 for ietf-openpgp-bks; Wed, 7 Nov 2001 10:11:07 -0800 (PST) Received: from hotmail.com (oe57.law3.hotmail.com [209.185.240.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA7IB5805189 for ; Wed, 7 Nov 2001 10:11:05 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Nov 2001 10:11:02 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <20011106.132424.68557949.kazu@iijlab.net><009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> <87r8rbknls.fsf@alberti.gnupg.de> Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) Date: Wed, 7 Nov 2001 13:09:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 07 Nov 2001 18:11:02.0334 (UTC) FILETIME=[8F43B5E0:01C167B7] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Werner Koch" To: "Michael Young" Cc: Sent: Wednesday, November 07, 2001 3:10 AM Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) > > On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > > > answer. The issue was that GnuPG used an old-style indeterminate-length > > packet for the plaintext before the MDC (see my message of August 23 > > But only if the plaintext is a compressed packet - right? > > Werner ----- Original Message ----- From: "Werner Koch" To: "Michael Young" Cc: Sent: Wednesday, November 07, 2001 3:10 AM Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) > > On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > > > answer. The issue was that GnuPG used an old-style indeterminate-length > > packet for the plaintext before the MDC (see my message of August 23 > > But only if the plaintext is a compressed packet - right? > > Werner here is the url for the pgpdump web interface: http://xdv.org/pgpdump/ here is the output for a message encrypted to an rsa key using gpg with twofish as the algorithm: PGPdump Results Old: Public-Key Encrypted Session Key Packet(tag 1)(268 bytes) New version(3) Key ID - f1 56 64 88 f7 7a ff 7b Pub alg - RSA Encrypt or Sign(pub 1) RSA m^e mod n(2047 bits) - 78 02 54 44 fd 0b ec 0d 44 de 38 f8 95 f4 8d 89 0a 92 4a 47 4e f8 84 55 38 47 24 1a 3e 91 36 9f 72 32 21 54 43 f5 8b 4f be 1d ce 4c ec ac 87 89 85 f0 ae 2c a7 48 c8 e0 31 aa 42 88 68 41 51 56 84 6b bc 0a a1 9d 50 9b f8 7b 35 96 82 d7 9b 77 e6 95 b1 83 77 13 f2 bb c1 0b 28 9a e8 f9 ac 09 10 8d 93 84 92 5b 95 8c 7a a9 43 44 6d 38 a7 40 46 ef a6 86 2c bc 1c ae 2b 27 0d 48 34 d9 c3 89 d3 7b ef a9 b3 b7 dd 9d 87 80 30 26 8f b1 0d a6 a7 ba d0 aa 6c 3e 76 6d 82 ac 72 88 14 eb 90 8f 8e b8 29 bf ed 5a 07 46 93 02 ae 0e d4 46 3f df 6d 29 6b 70 70 a6 20 8a 95 83 4c dc 7e 69 e9 69 56 a1 a6 8d fd ab 79 38 1d 93 da b8 1f d1 78 84 84 7b 48 74 d8 66 94 64 5d 8a 88 61 fb 14 de ba 4e 33 1c 6f ba 84 70 02 28 11 4f 05 ba 7d 4f 2e c6 f4 92 7a 99 cc 5d e6 98 e3 4f 24 7c df f9 57 -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02 New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes) Ver 1 Encrypted data (plain text + MDC SHA1(20 bytes)) PGPdump Interface, Copyright (c) 2001, Stefan H. Holek, stefan@epy.co.at is there any additional mdc information necessary/desirable to be displayed? vedaal From owner-ietf-openpgp@mail.imc.org Thu Nov 8 04:14:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21449 for ; Thu, 8 Nov 2001 04:14:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA88hwS21184 for ietf-openpgp-bks; Thu, 8 Nov 2001 00:43:58 -0800 (PST) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA88ht821168 for ; Thu, 8 Nov 2001 00:43:56 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 08 Nov 2001 09:34:44 +0200 Message-ID: <3BEA43A4.3CEF218E@saiknes.lv> Date: Thu, 08 Nov 2001 10:34:44 +0200 From: disastry@saiknes.lv Organization: disastry.NO.SPaM.NET X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Werner Koch wrote: > On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > > > answer. The issue was that GnuPG used an old-style indeterminate-length > > packet for the plaintext before the MDC (see my message of August 23 > > But only if the plaintext is a compressed packet - right? > > Werner rfc2440b03> 4.2.1. Old-Format Packet Lengths rfc2440b03> [snip] rfc2440b03> The meaning of the length-type in old-format packets is: rfc2440b03> 3 - The packet is of indeterminate length. The header is 1 octet rfc2440b03> long, and the implementation must determine how long the packet rfc2440b03> is. If the packet is in a file, this means that the packet rfc2440b03> extends until the end of the file. In general, an implementation rfc2440b03> SHOULD NOT use indeterminate length packets except where the end rfc2440b03> of the data will be clear from the context, it does not talks about compression, so I think it should be the same for any packet type rfc2440b03> 4.2.3. Packet Length Examples rfc2440b03> [snip] rfc2440b03> An implementation MAY use Partial Body Lengths for data packets, be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rfc2440b03> they literal, compressed, or encrypted. The first partial length ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rfc2440b03> MUST be at least 512 octets long. Partial Body Lengths MUST NOT be rfc2440b03> used for any other packet types. so it is ok for all data packets.. rfc1991> 4.1 Packet structure fields rfc1991> [snip] rfc1991> 11 - no packet length supplied, unknown packet length rfc1991> [snip] rfc1991> A value of 11 is currently used in one place: on compressed data. rfc1991> That is, a compressed data block currently looks like , rfc1991> where , binary 10 1000 11, is an indefinite-length packet. The rfc1991> proper interpretation is "until the end of the enclosing structure", rfc1991> although it should never appear outermost (where the enclosing rfc1991> structure is a file). 'currently used in one place' is not the same as 'MUST/SHOULD be used in one place'. so I think it's ok to use 'unknown packet length' for other than compressed packets but gpg implements this different way than in RFC1991 and RFC2440: doc\DETAILS> Packet Headers doc\DETAILS> [snip] doc\DETAILS> + It works like this: After the CTB (with a length field of 11) a doc\DETAILS> + marker field is used, which gives the length of the following datablock. doc\DETAILS> + This is a simple 2 byte field (MSB first) containing the amount of data doc\DETAILS> + following this field, not including this length field. After this datablock doc\DETAILS> + another length field follows, which gives the size of the next datablock. doc\DETAILS> + A value of 0 indicates the end of the packet. The maximum size of a doc\DETAILS> + data block is limited to 65534, thereby reserving a value of 0xffff for doc\DETAILS> + future extensions. other interoperability problem is that gpg puts signature after the data packet, pgp expect it before.. I think it is because gpg wants to do all in one pass without seeking or using temporary files. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBO+lTFjBaTVEuJQxkEQO4ygCfYLMPK9yLSplSO1Gm8iGWTHZJibMAoNcs HXqktgfnXYl4hg2158xR7UEd =QaId -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Nov 8 06:41:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22493 for ; Thu, 8 Nov 2001 06:41:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8BHa409538 for ietf-openpgp-bks; Thu, 8 Nov 2001 03:17:36 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8BHX809534 for ; Thu, 8 Nov 2001 03:17:34 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 161nN2-0007pq-00; Thu, 08 Nov 2001 12:29:20 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 161nDJ-0007Mr-00; Thu, 08 Nov 2001 12:19:17 +0100 To: disastry@saiknes.lv Cc: ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <3BEA43A4.3CEF218E@saiknes.lv> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 08 Nov 2001 12:19:16 +0100 In-Reply-To: <3BEA43A4.3CEF218E@saiknes.lv> (disastry@saiknes.lv's message of "Thu, 08 Nov 2001 10:34:44 +0200") Message-ID: <87zo5xh5mz.fsf@alberti.gnupg.de> Lines: 30 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 08 Nov 2001 10:34:44 +0200, disastry said: rfc2440b03> extends until the end of the file. In general, an implementation rfc2440b03> SHOULD NOT use indeterminate length packets except where the end rfc2440b03> of the data will be clear from the context, > it does not talks about compression, Well, the "clear from context" is exactly the case for compressed packets because the zip algorithm has its own length management. > but gpg implements this different way than in RFC1991 and RFC2440: Not if you give --openpgp or when the recipient uses a v4 key. I used the other method to implement the indefinite length packets before I knew about the OpenPGP WG. > other interoperability problem is that gpg puts > signature after the data packet, pgp expect it before.. > I think it is because gpg wants to do all in > one pass without seeking or using temporary files. Exactly. I have suggested to write a wrapper which swaps the sequence. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Thu Nov 8 13:22:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03420 for ; Thu, 8 Nov 2001 13:22:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8I2n007771 for ietf-openpgp-bks; Thu, 8 Nov 2001 10:02:49 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8I2l807767 for ; Thu, 8 Nov 2001 10:02:47 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA13071; Fri, 9 Nov 2001 07:02:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA18648; Fri, 9 Nov 2001 07:02:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 07:02:39 +1300 (NZDT) Message-ID: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: disastry@saiknes.lv writes: >rfc2440b03>4.2.1. Old-Format Packet Lengths >rfc2440b03>[snip] >rfc2440b03> The meaning of the length-type in old-format packets is: >rfc2440b03> 3 - The packet is of indeterminate length. The header is 1 octet >rfc2440b03> long, and the implementation must determine how long the packet >rfc2440b03> is. If the packet is in a file, this means that the packet >rfc2440b03> extends until the end of the file. In general, an implementation >rfc2440b03> SHOULD NOT use indeterminate length packets except where theend >rfc2440b03> of the data will be clear from the context, > >it does not talks about compression, so I think it should be the same for any >packet type In general indefinite-length packets are a pain, you can avoid them in all cases except compressed-data where you don't know the length in advance (and maybe a few oddball streaming applications). Although the standard doesn't say it, common sense would dictate using the definite-length encoding for all but compressed data. >rfc2440b03>4.2.3. Packet Length Examples >rfc2440b03>[snip] >rfc2440b03> An implementation MAY use Partial Body Lengths for data packets,be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >rfc2440b03> they literal, compressed, or encrypted. The first partial length > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >rfc2440b03> MUST be at least 512 octets long. Partial Body Lengths MUST NOT be >rfc2440b03> used for any other packet types. > >so it is ok for all data packets.. Urgh, I hope no-one interprets it that way. The partial-length encoding is incredibly painful to use with its silly power-of-two restriction (you can't just say "This is what I've got so far, the next lot starts here" but have to chop it up into little power-of-two length pieces just to fit the *&#^$&#* length-encoding mechanism). GPG uses the definite-length format where it can and 0xA3 where it can't (compressed data), something I agree with wholeheartedly. Peter. From owner-ietf-openpgp@mail.imc.org Thu Nov 8 13:49:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03971 for ; Thu, 8 Nov 2001 13:49:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8IUag08840 for ietf-openpgp-bks; Thu, 8 Nov 2001 10:30:36 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8IUY808835 for ; Thu, 8 Nov 2001 10:30:34 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01587; Thu, 8 Nov 2001 13:30:34 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA14885; Thu, 8 Nov 2001 13:30:32 -0500 (EST) Received: from alice-whacker.mit.edu (ALICE-WHACKER.MIT.EDU [18.187.1.68]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25154; Thu, 8 Nov 2001 13:30:29 -0500 (EST) Received: (from warlord@localhost) by alice-whacker.mit.edu (8.9.3) id NAA24440; Thu, 8 Nov 2001 13:30:28 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> From: Derek Atkins Date: 08 Nov 2001 13:30:28 -0500 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Fri, 9 Nov 2001 07:02:39 +1300 (NZDT)" Message-ID: Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Urgh, I hope no-one interprets it that way. The partial-length encoding is > incredibly painful to use with its silly power-of-two restriction (you can't > just say "This is what I've got so far, the next lot starts here" but have to > chop it up into little power-of-two length pieces just to fit the *&#^$&#* > length-encoding mechanism). GPG uses the definite-length format where it can > and 0xA3 where it can't (compressed data), something I agree with > wholeheartedly. Come on, Peter... If you have to buffer 4K-bytes, is that so horrible? Besides, if you're doing a streaming application where you don't want to buffer, you're better off packetizing anyways instead of making one large stream. > Peter. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Nov 8 14:04:42 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04255 for ; Thu, 8 Nov 2001 14:04:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8IlR109448 for ietf-openpgp-bks; Thu, 8 Nov 2001 10:47:27 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8IlP809444 for ; Thu, 8 Nov 2001 10:47:25 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA13941; Fri, 9 Nov 2001 07:46:24 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA19709; Fri, 9 Nov 2001 07:46:24 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 07:46:24 +1300 (NZDT) Message-ID: <200111081846.HAA19709@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, warlord@mit.edu Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: warlord@ALICE-WHACKER.MIT.EDU writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>Urgh, I hope no-one interprets it that way. The partial-length encoding is >>incredibly painful to use with its silly power-of-two restriction (you can't >>just say "This is what I've got so far, the next lot starts here" but have to >>chop it up into little power-of-two length pieces just to fit the *&#^$&#* >>length-encoding mechanism). GPG uses the definite-length format where it can >>and 0xA3 where it can't (compressed data), something I agree with >>wholeheartedly. > >Come on, Peter... If you have to buffer 4K-bytes, is that so horrible? If only it were that easy. Consider what happens when someone says "You have a 900K transfer buffer, stream data through it". Instead of being able to drop a simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc. Because the amount of expansion is variable-length, depending on the size of the I/O buffer I have to precalculate the encoding expansion beforehand and reduce the data amount read by that amount to see what it'll take to optimally fill the buffer, and because I have to keep dropping in partial-length headers all over the place I can't do a single I/O but have to do it all in dribs and drabs, and in general do a lot of unnecessary work (both in terms of writing code and CPU time) and waste a lot more space in encoding than simply using a 32-bit length would have. Peter. From owner-ietf-openpgp@mail.imc.org Thu Nov 8 14:26:00 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04615 for ; Thu, 8 Nov 2001 14:26:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8J3Y009926 for ietf-openpgp-bks; Thu, 8 Nov 2001 11:03:34 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8J3X809922 for ; Thu, 8 Nov 2001 11:03:33 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12268; Thu, 8 Nov 2001 14:03:33 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA26216; Thu, 8 Nov 2001 14:00:42 -0500 (EST) Received: from alice-whacker.mit.edu (ALICE-WHACKER.MIT.EDU [18.187.1.68]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA27097; Thu, 8 Nov 2001 13:57:45 -0500 (EST) Received: (from warlord@localhost) by alice-whacker.mit.edu (8.9.3) id NAA24691; Thu, 8 Nov 2001 13:57:45 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <200111081846.HAA19709@ruru.cs.auckland.ac.nz> From: Derek Atkins Date: 08 Nov 2001 13:57:45 -0500 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Fri, 9 Nov 2001 07:46:24 +1300 (NZDT)" Message-ID: Lines: 40 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > If only it were that easy. Consider what happens when someone says "You have a > 900K transfer buffer, stream data through it". Instead of being able to drop a Do you mean you have 900K to transfer, or you have a buffer of 900K that you can use to buffer something larger? In either case, I'd use the largest buffer-size that fits (i.e. 512K in this case) and just eat the rest of the buffer. > simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write > it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K > chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc. > Because the amount of expansion is variable-length, depending on the size of > the I/O buffer I have to precalculate the encoding expansion beforehand and > reduce the data amount read by that amount to see what it'll take to optimally > fill the buffer, and because I have to keep dropping in partial-length headers > all over the place I can't do a single I/O but have to do it all in dribs and > drabs, and in general do a lot of unnecessary work (both in terms of writing > code and CPU time) and waste a lot more space in encoding than simply using a > 32-bit length would have. The reason Colin and I came up with this idea was the belief that a) we might want to encode data longer than 32 bits, and b) we needed a way to differentiate ourselves with the then-existing PGP 2.x length-encoding scheme So, based on these constraints, we couldn't use a simple 32-bit length encoding without adding extra bytes to the overhead. Perhaps this was a poor choice, but it's what we came up with at the time. > Peter. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Nov 8 14:48:15 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04965 for ; Thu, 8 Nov 2001 14:48:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8JQUZ11423 for ietf-openpgp-bks; Thu, 8 Nov 2001 11:26:30 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8JQS811419 for ; Thu, 8 Nov 2001 11:26:28 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id IAA15139; Fri, 9 Nov 2001 08:25:52 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id IAA20711; Fri, 9 Nov 2001 08:25:52 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 08:25:52 +1300 (NZDT) Message-ID: <200111081925.IAA20711@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, warlord@mit.edu Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins writes: >>If only it were that easy. Consider what happens when someone says "You have a >>900K transfer buffer, stream data through it". > >Do you mean you have 900K to transfer, or you have a buffer of 900K that you >can use to buffer something larger? In either case, I'd use the largest >buffer-size that fits (i.e. 512K in this case) and just eat the rest of the >buffer. I don't control it, I'm told "Here's an xK buffer, employ it optimally" (as a generalisation of that, any encoding method which forces a certain implementation style to the exclusion of others is a bad idea. In this instance it makes it extremely painful to use arbitrary-sized buffers). >it's what we came up with at the time. There's a simple solution, which is to avoid it where possible (it's not actually needed anywhere except maybe a few special-case situations, so you can use definite-length encoding and 0xA3 in most cases). Peter. From owner-ietf-openpgp@mail.imc.org Thu Nov 8 14:53:20 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05125 for ; Thu, 8 Nov 2001 14:53:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8JZhl11723 for ietf-openpgp-bks; Thu, 8 Nov 2001 11:35:43 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8JZf811717 for ; Thu, 8 Nov 2001 11:35:41 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA27255; Thu, 8 Nov 2001 14:35:41 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA25146; Thu, 8 Nov 2001 14:35:41 -0500 (EST) Received: from alice-whacker.mit.edu (ALICE-WHACKER.MIT.EDU [18.187.1.68]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12213; Thu, 8 Nov 2001 14:35:33 -0500 (EST) Received: (from warlord@localhost) by alice-whacker.mit.edu (8.9.3) id OAA24906; Thu, 8 Nov 2001 14:35:33 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <200111081925.IAA20711@ruru.cs.auckland.ac.nz> From: Derek Atkins Date: 08 Nov 2001 14:35:33 -0500 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Fri, 9 Nov 2001 08:25:52 +1300 (NZDT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well, the whole point of indefinite-length encoding was to encode something when you didn't know how long it was. For example: run-some-command | pgp | some-other-command In this case, you don't know how long the input is going to be, therefore you want to use indefinite-length encoding. On the other hand, if you can 'stat()' the source file ahead of time, you should DEFINITELY use definite-length encoding. -derek pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Derek Atkins writes: > >>If only it were that easy. Consider what happens when someone says "You have a > >>900K transfer buffer, stream data through it". > > > >Do you mean you have 900K to transfer, or you have a buffer of 900K that you > >can use to buffer something larger? In either case, I'd use the largest > >buffer-size that fits (i.e. 512K in this case) and just eat the rest of the > >buffer. > > I don't control it, I'm told "Here's an xK buffer, employ it optimally" (as a > generalisation of that, any encoding method which forces a certain > implementation style to the exclusion of others is a bad idea. In this > instance it makes it extremely painful to use arbitrary-sized buffers). > > >it's what we came up with at the time. > > There's a simple solution, which is to avoid it where possible (it's not > actually needed anywhere except maybe a few special-case situations, so you can > use definite-length encoding and 0xA3 in most cases). > > Peter. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Nov 8 15:21:16 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05859 for ; Thu, 8 Nov 2001 15:21:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8K1TE13648 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:01:29 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA8K1R813644 for ; Thu, 8 Nov 2001 12:01:27 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA28473; Thu, 8 Nov 2001 11:59:01 -0800 Date: Thu, 8 Nov 2001 11:59:01 -0800 From: hal@finney.org Message-Id: <200111081959.LAA28473@finney.org> To: pgut001@cs.auckland.ac.nz, warlord@mit.edu Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins writes: > The reason Colin and I came up with this idea was the belief that > a) we might want to encode data longer than 32 bits, and > b) we needed a way to differentiate ourselves with the > then-existing PGP 2.x length-encoding scheme Actually at NAI we have used this scheme to be able to handle > 2^32 bit files for one of our applications. It was an astonishingly easy modification to the code to be able to handle such large buffers, thanks to Derek's and Colin's design, which we are still using. In fact it really came down to a two-line change to set the flag to use partial body length packets in this case, and everything else worked automatically. Most of the work was in identifying that the file was > 2^32 bits and changing the APIs to pass that information into the place where it was needed. Hal From owner-ietf-openpgp@mail.imc.org Thu Nov 8 15:27:05 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06071 for ; Thu, 8 Nov 2001 15:27:04 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8K6TC13785 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:06:29 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8K6S813781 for ; Thu, 8 Nov 2001 12:06:28 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA8K6H9K007779; Thu, 8 Nov 2001 12:06:23 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <20011106.132424.68557949.kazu@iijlab.net> References: <20011106.132424.68557949.kazu@iijlab.net> X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 8 Nov 2001 11:58:41 -0800 To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) From: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:24 PM +0900 11/6/01, Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote: >Another PGP parser can be found: > http://pgp.iijlab.net/pgpdump.html > >Web interface is also available. Thanks, Kazu. I'll have a look. At 12:19 PM -0800 11/6/01, Len Sassaman wrote: >GnuPG has such a parser built into it. Also, there's a perl script written >by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing. It will be interesting to compare the different parsers. I suspect each will have their uses. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Thu Nov 8 16:09:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07838 for ; Thu, 8 Nov 2001 16:09:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8KpDF15854 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:51:13 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8KpA815847 for ; Thu, 8 Nov 2001 12:51:10 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id JAA17183; Fri, 9 Nov 2001 09:50:26 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id JAA22264; Fri, 9 Nov 2001 09:50:25 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 09:50:25 +1300 (NZDT) Message-ID: <200111082050.JAA22264@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jwn2@qualcomm.com, pgut001@cs.auckland.ac.nz Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John W Noerenberg II writes: >What I'm mainly concerned with as far as interoperability on this point is >whether implementations support segmented packets, and the interpretation of >of the data is consistent across implementations. Mine doesn't. If I get a huge amount of demand for it (which seems unlikely, since none of the PGP versions I've got installed seem to produce them under normal usage) I may add decode-only support for them. Peter. From owner-ietf-openpgp@mail.imc.org Thu Nov 8 16:25:18 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06072 for ; Thu, 8 Nov 2001 15:27:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8K7s513840 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:07:54 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8K7r813836 for ; Thu, 8 Nov 2001 12:07:53 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA8K6H9I007779; Thu, 8 Nov 2001 12:06:18 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> References: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 8 Nov 2001 11:53:43 -0800 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: John W Noerenberg II Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:02 AM +1300 11/9/01, Peter Gutmann wrote: >Urgh, I hope no-one interprets it that way. The partial-length encoding is >incredibly painful to use with its silly power-of-two restriction (you can't >just say "This is what I've got so far, the next lot starts here" but have to >chop it up into little power-of-two length pieces just to fit the *&#^$&#* >length-encoding mechanism). GPG uses the definite-length format where it can >and 0xA3 where it can't (compressed data), something I agree with >wholeheartedly. What I'm mainly concerned with as far as interoperability on this point is whether implementations support segmented packets, and the interpretation of of the data is consistent across implementations. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Thu Nov 8 23:02:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16625 for ; Thu, 8 Nov 2001 23:02:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA93jQm26428 for ietf-openpgp-bks; Thu, 8 Nov 2001 19:45:26 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA93jP826424 for ; Thu, 8 Nov 2001 19:45:25 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA93hk9I007806; Thu, 8 Nov 2001 19:43:46 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200111082050.JAA22264@ruru.cs.auckland.ac.nz> References: <200111082050.JAA22264@ruru.cs.auckland.ac.nz> X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 8 Nov 2001 19:38:13 -0800 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: John W Noerenberg II Subject: segmented packets (was Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)) Cc: pgut001@cs.auckland.ac.nz, disastry@saiknes.lv, ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:50 AM +1300 11/9/01, Peter Gutmann wrote: >John W Noerenberg II writes: > >>What I'm mainly concerned with as far as interoperability on this point is >>whether implementations support segmented packets, and the interpretation of >>of the data is consistent across implementations. > >Mine doesn't. If I get a huge amount of demand for it (which seems unlikely, >since none of the PGP versions I've got installed seem to produce them under >normal usage) I may add decode-only support for them. I've got an example that uses segmented packets generated with PGP 7.0.3! What I did was encrypt and sign a 2K text file. I can't tell you why PGP 7.0.3 uses a segmented packet, but it certainly does. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Fri Nov 16 11:42:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09588 for ; Fri, 16 Nov 2001 11:42:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAGG2TF12881 for ietf-openpgp-bks; Fri, 16 Nov 2001 08:02:29 -0800 (PST) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGG2R812874 for ; Fri, 16 Nov 2001 08:02:27 -0800 (PST) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 164lQG-0002xz-00 for ietf-openpgp@imc.org; Fri, 16 Nov 2001 17:00:56 +0100 To: ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <3BEA43A4.3CEF218E@saiknes.lv> <87zo5xh5mz.fsf@alberti.gnupg.de> From: Florian Weimer Date: 16 Nov 2001 17:00:56 +0100 In-Reply-To: <87zo5xh5mz.fsf@alberti.gnupg.de> (Werner Koch's message of "Thu, 08 Nov 2001 12:19:16 +0100") Message-ID: Lines: 22 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On Thu, 08 Nov 2001 10:34:44 +0200, disastry said: > > rfc2440b03> extends until the end of the file. In general, an implementation > rfc2440b03> SHOULD NOT use indeterminate length packets except where the end > rfc2440b03> of the data will be clear from the context, > > > it does not talks about compression, > > Well, the "clear from context" is exactly the case for compressed > packets because the zip algorithm has its own length management. As far as I understand this description, "clear from context" means "clear from the OpenPGP context", e.g., the packet is contained in a larger packet which has got a length limitation, or it is the last one in an OpenPGP message. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Fri Nov 16 20:30:54 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01112 for ; Fri, 16 Nov 2001 20:30:54 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH15Tu08857 for ietf-openpgp-bks; Fri, 16 Nov 2001 17:05:29 -0800 (PST) Received: from pick.home.fargonauten.de (bkhm57kiy18ei.bc.hsia.telus.net [64.180.242.187] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH15S808851 for ; Fri, 16 Nov 2001 17:05:28 -0800 (PST) Received: by pick.home.fargonauten.de (Postfix, from userid 1000) id A7333937CE; Fri, 16 Nov 2001 17:05:25 -0800 (PST) Date: Fri, 16 Nov 2001 17:05:25 -0800 From: Ingo Luetkebohle To: ietf-openpgp@imc.org Subject: interop/encryption to pgp2 Message-ID: <20011116170525.B388@fargonauten.de> Reply-To: ingo@fargonauten.de Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, David Shaw just pointed out that PGP2.6.2 chokes when it receives a message that has been encrypted to a v4 key, even when it has been encrypted to a v3 key, too.=20 I can only assume that this is because public-key encrypted session key packets allow non-RSA cipher material. Can anybody who has a working knowledge of the old code confirm this? If this is the case, would it be possible to introduce a v4 packet of that type? Would that be ignored by PGP2, so that having both v3 and v4 public key encrypted session key packets would work with pgp2? Ingo --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE79bfVzZDBZDStzlsRAvfoAJ9No97fDMgoVCdCIEVRPu5rV+mJuQCeJB/P XkZYDFmyylSMnNKMxtUNn3o= =5kFE -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- From owner-ietf-openpgp@mail.imc.org Fri Nov 16 20:50:17 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01347 for ; Fri, 16 Nov 2001 20:50:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH1Usj11071 for ietf-openpgp-bks; Fri, 16 Nov 2001 17:30:54 -0800 (PST) Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH1Uq811065 for ; Fri, 16 Nov 2001 17:30:52 -0800 (PST) Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3) id UAA05568; Fri, 16 Nov 2001 20:30:49 -0500 To: ingo@fargonauten.de Cc: ietf-openpgp@imc.org Subject: Re: interop/encryption to pgp2 References: <20011116170525.B388@fargonauten.de> From: Derek Atkins Date: 16 Nov 2001 20:30:48 -0500 In-Reply-To: Ingo Luetkebohle's message of "Fri, 16 Nov 2001 17:05:25 -0800" Message-ID: Lines: 56 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: PGP 2.6.2 does not handle any new-style packets, even if it's only part of a message. If PGP 2.6.2 doesn't understand _any_ packet, it will barf. Basically, the only thing you can do is, if you're using -ANY- non-RFC1991 packets, you should emit a leading "nonce" header that declares the message to be a non-RFC1991 message. IIRC, in PGP 5.0 we did this via a two-byte leading sequence followed by the three ASCII characters P, G, and P. I'd have to go look at the code to figure out what the leading bytes were. -derek Ingo Luetkebohle writes: > --1UWUbFP1cBYEclgG > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi, > > David Shaw just pointed out that PGP2.6.2 chokes when it receives a > message that has been encrypted to a v4 key, even when it has been > encrypted to a v3 key, too.=20 > > I can only assume that this is because public-key encrypted session > key packets allow non-RSA cipher material. Can anybody who has a > working knowledge of the old code confirm this? > > If this is the case, would it be possible to introduce a v4 packet of > that type? Would that be ignored by PGP2, so that having both v3 and > v4 public key encrypted session key packets would work with pgp2? > > Ingo > > --1UWUbFP1cBYEclgG > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Weitere Infos: siehe http://www.gnupg.org > > iD8DBQE79bfVzZDBZDStzlsRAvfoAJ9No97fDMgoVCdCIEVRPu5rV+mJuQCeJB/P > XkZYDFmyylSMnNKMxtUNn3o= > =5kFE > -----END PGP SIGNATURE----- > > --1UWUbFP1cBYEclgG-- -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Fri Nov 16 23:46:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05256 for ; Fri, 16 Nov 2001 23:46:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH4TRn18586 for ietf-openpgp-bks; Fri, 16 Nov 2001 20:29:27 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH4TP818582 for ; Fri, 16 Nov 2001 20:29:25 -0800 (PST) Received: from [192.168.1.180] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 16 Nov 2001 20:29:15 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: <20011116170525.B388@fargonauten.de> Date: Fri, 16 Nov 2001 20:29:05 -0800 To: Derek Atkins , ingo@fargonauten.de From: Jon Callas Subject: Re: interop/encryption to pgp2 Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:30 PM -0500 11/16/01, Derek Atkins wrote: >Basically, the only thing you can do is, if you're using -ANY- >non-RFC1991 packets, you should emit a leading "nonce" header that >declares the message to be a non-RFC1991 message. IIRC, in PGP 5.0 we >did this via a two-byte leading sequence followed by the three ASCII >characters P, G, and P. I'd have to go look at the code to figure out >what the leading bytes were. Marker Packet -- Section 5.8 of 2440. I'll note that while OpenPGP encourages interoperating with 2.6.2, it is not required. It is not quite deprecated, but there are weasel words in 2440 that permit "breaking" 2440 in a few cases for 2.6.2 compatibility. So 2.6.2 compatibility will get you a golf clap, but it shouldn't stand in the way of getting us to Draft Standard. Jon Jon From owner-ietf-openpgp@mail.imc.org Sat Nov 17 01:26:53 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08955 for ; Sat, 17 Nov 2001 01:26:53 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAH6B2K20032 for ietf-openpgp-bks; Fri, 16 Nov 2001 22:11:02 -0800 (PST) Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH6B0820025 for ; Fri, 16 Nov 2001 22:11:01 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fAH6Ajs06344 for ietf-openpgp@imc.org; Sat, 17 Nov 2001 01:10:45 -0500 Date: Sat, 17 Nov 2001 01:10:45 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: interop/encryption to pgp2 Message-ID: <20011117011045.C659@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20011116170525.B388@fargonauten.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011116170525.B388@fargonauten.de>; from ingo@fargonauten.de on Fri, Nov 16, 2001 at 05:05:25PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Crescent (4% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 16, 2001 at 05:05:25PM -0800, Ingo Luetkebohle wrote: > Hi, >=20 > David Shaw just pointed out that PGP2.6.2 chokes when it receives a > message that has been encrypted to a v4 key, even when it has been > encrypted to a v3 key, too.=20 >=20 > I can only assume that this is because public-key encrypted session > key packets allow non-RSA cipher material. Can anybody who has a > working knowledge of the old code confirm this? It can also be the size of the key. V4 RSA keys that are greater than 2048 bits long will cause PGP 2.6.2 to fail with various odd errors. V4 RSA keys <=3D 2048 bits long can be mixed in with v3 keys without causing any problems. David --=20 David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO/X/ZYccwqs8s7QVAQE1tAf+KWAVEHm3GZyM/zkCRLz9Nn3xNjsDFvYa q82xBOEf6ynuEHoSpbl6e08XMnIPdrCQAv3fjy0v6hKM53vJXHlus3xcE9QwZOZR L4c2ziwK8DqgG7BiU3RtYkzt++7kMzz8dVeYQduFG7HN80aFLIfPf0oa7BOxs68U v8K6jssXwXK3Wc5gSQyR38waOVABtIlCFkr7DR7e/60UP3Kqhi6yVSpM9Umxv6JS P82GoFtmxXqYjvuPX1m2uUDa1Iq4TlcE+rnvWHnQ9SQYiyWLx/we0f4sKz7NRr8s TZLwO31s6yVAZ+34KZTV1zYc0mopVssoaJUMn9CrW+BZkpMW093QaA== =v2N/ -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-ietf-openpgp@mail.imc.org Mon Nov 19 05:10:28 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24046 for ; Mon, 19 Nov 2001 05:10:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJ9fDk03644 for ietf-openpgp-bks; Mon, 19 Nov 2001 01:41:13 -0800 (PST) Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJ9fB803639 for ; Mon, 19 Nov 2001 01:41:11 -0800 (PST) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.1/8.12.1) with ESMTP id fAJ9ex9Q022287 for ; Mon, 19 Nov 2001 10:40:59 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.1/8.12.1/Submit) id fAJ9ewBa022286 for ietf-openpgp@imc.org; Mon, 19 Nov 2001 10:40:58 +0100 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC) Organization: IKS GmbH Jena Lines: 22 Message-ID: References: <3BEA43A4.3CEF218E@saiknes.lv> <87zo5xh5mz.fsf@alberti.gnupg.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1006162858 22074 217.17.192.37 (19 Nov 2001 09:40:58 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Florian Weimer wrote: >Werner Koch writes: >> On Thu, 08 Nov 2001 10:34:44 +0200, disastry said: >> rfc2440b03> extends until the end of the file. In general, an implementation >> rfc2440b03> SHOULD NOT use indeterminate length packets except where the end >> rfc2440b03> of the data will be clear from the context, >> >> > it does not talks about compression, >> >> Well, the "clear from context" is exactly the case for compressed >> packets because the zip algorithm has its own length management. > >As far as I understand this description, "clear from context" means >"clear from the OpenPGP context", e.g., the packet is contained in a >larger packet which has got a length limitation, or it is the last one >in an OpenPGP message. Yes and no. ;-) The senctence was coined by describing the 2.6.2ff. implementation. This implementation does terminate the packet on the end of compressed data as Werner said, but never generate further packets as Florian remarked. So Werner is right by implementation and Florian is right by phenomenology. From owner-ietf-openpgp@mail.imc.org Wed Nov 28 10:32:37 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14191 for ; Wed, 28 Nov 2001 10:32:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASFACn18337 for ietf-openpgp-bks; Wed, 28 Nov 2001 07:10:12 -0800 (PST) Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASFAA818332 for ; Wed, 28 Nov 2001 07:10:10 -0800 (PST) Received: from sobolev.does-not-exist.org (d-dialin-2451.addcom.de [213.61.80.51]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id QAA29302; Wed, 28 Nov 2001 16:08:44 +0100 (CET) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 21FC42ED15; Wed, 28 Nov 2001 16:07:58 +0100 (CET) Date: Wed, 28 Nov 2001 16:07:58 +0100 From: Thomas Roessler To: whom it may concern: ; Subject: MIME polymorphism Message-ID: <20011128150758.GA2128@sobolev.does-not-exist.org> Reply-To: roessler@does-not-exist.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.3.23.2i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The two major e-mail security protocols currently proposed - S/MIME and PGP/MIME - both build on the fundamental framework of multipart/signed messages specified in RFC 1847. In this framework, the data to be signed is formatted as a single MIME part (which may, of course, contain nested sub-parts). This MIME part is then hashed for the signature. The hash does, in particular, include all the meta infomration present on the MIME level, including the body part's content type. That way, the signature does, for instance, include the information whether some PostScript code which was signed should be interpreted by a postscript interpreter for display (application/postscript), or whether this code should just be displayed as plain text (text/plain). In theory, with multipart/signed, the actual data and the information how it must be interpreted is both signed and protected. This theory fails on two levels: First, knowing a file's content type is not sufficient to guarantee correct interpretation. This has been demonstrated before; think about differences in the interpretation of certain special characters when documents are exchanged between some Microsoft Word versions for the Windows and Macintosh platforms. [4] Second, the theory is based on the assumption that the interpretation of the MIME meta information contained in Content-* headers is well-defined. This assumption is violated with malformed MIME messages which contain contradictory information: When there are, for instance, multiple boundary parameters for a single multipart/* attachment, implementations will generally follow the mantra of being liberal in what they accept, and just choose one. When there are multiple Content-Type headers present on a single attachment, implementations will likewise be liberal, and choose one (or even mix information from the two headers). Since the choices made differ between MIME implementations, it is for instance easily possible to create an e-mail mesage with a multipart/mixed body which seems to contain different content, depending on whether it's displayed with mutt [5] or pine [6]. Note that this problem does not only apply to digital signatures, but also to virus scanners: If these try to be liberal with respect to malformed MIME messages, they may easily check attachments for viruses which will never be seen by users - and, likewise, they may not scan those attachments which are actually displayed by users' software. To prevent this problem from occuring, security services must not be liberal in what they accept, or try to hide possible problems from users. Instead of software silently making choices, ambiguities must be treated as malicious, and users must be warned. References: 1. Galvin, Murphy, Crocker, Freed: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. RFC 1847, October 1995. 2. Freed, Borenstein: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, November 1996. 3. Elkins, Del Torto, Levien, Roessler: MIME Security with OpenPGP. RFC 3156, August 2001. 4. Fox, Zu einem prinzipiellen Problem digitaler Signaturen, Datenschutz und Datensicherheit (DuD) 7/1998, pp. 386-388. 5. Mutt home page: 6. Pine Information Center: -- Thomas Roessler http://log.does-not-exist.org/ From owner-ietf-openpgp@mail.imc.org Thu Nov 29 08:54:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29790 for ; Thu, 29 Nov 2001 08:54:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATDboM21394 for ietf-openpgp-bks; Thu, 29 Nov 2001 05:37:50 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATDbn821387 for ; Thu, 29 Nov 2001 05:37:49 -0800 (PST) Received: from softhome.net ([209.6.136.167]) by softhome.net with esmtp; Thu, 29 Nov 2001 06:27:25 -0700 Message-ID: <3C0638F9.BC15DE1F@softhome.net> Date: Thu, 29 Nov 2001 08:32:43 -0500 From: John J Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: prefer "- From " instead of ">From "?? 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 Implementation note: For implementations which emit out-of-spec workarounds to forestall mangling of "From " in transit, it has been pointed out that stuffing "From " with "- " safely masks the offending sequence. On the receiving end, the stuffed line automatically reverts cleanly to the original text, without any special handling. This may be the sanest way to handle that case. Comments? -- John J. Kane From owner-ietf-openpgp@mail.imc.org Thu Nov 29 09:46:04 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04399 for ; Thu, 29 Nov 2001 09:46:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fATER6q25122 for ietf-openpgp-bks; Thu, 29 Nov 2001 06:27:06 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@relay.hq.tis.com [192.94.214.100] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATER6825117 for ; Thu, 29 Nov 2001 06:27:06 -0800 (PST) Received: by sentry.gw.tislabs.com; id JAA21470; Thu, 29 Nov 2001 09:32:07 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma021429; Thu, 29 Nov 01 09:31:52 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fATEQqO27648 for ietf-openpgp@imc.org; Thu, 29 Nov 2001 09:26:52 -0500 (EST) Date: Thu, 29 Nov 2001 09:26:52 -0500 (EST) Message-Id: <200111291426.fATEQqO27648@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-openpgp@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. Received: by above.proper.com (8.11.6/8.11.3) id fATER6q25122 for ietf-openpgp-bks; Thu, 29 Nov 2001 06:27:06 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@relay.hq.tis.com [192.94.214.100] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATER6825117 for ; Thu, 29 Nov 2001 06:27:06 -0800 (PST) Received: by sentry.gw.tislabs.com; id JAA21470; Thu, 29 Nov 2001 09:32:07 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma021429; Thu, 29 Nov 01 09:31:52 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fATEQqO27648 for ietf-openpgp@imc.org; Thu, 29 Nov 2001 09:26:52 -0500 (EST) Date: Thu, 29 Nov 2001 09:26:52 -0500 (EST) Message-Id: <200111291426.fATEQqO27648@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-openpgp@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fATDboM21394 for ietf-openpgp-bks; Thu, 29 Nov 2001 05:37:50 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fATDbn821387 for ; Thu, 29 Nov 2001 05:37:49 -0800 (PST) Received: from softhome.net ([209.6.136.167]) by softhome.net with esmtp; Thu, 29 Nov 2001 06:27:25 -0700 Message-ID: <3C0638F9.BC15DE1F@softhome.net> Date: Thu, 29 Nov 2001 08:32:43 -0500 From: John J Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: prefer "- From " instead of ">From "?? 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: Implementation note: For implementations which emit out-of-spec workarounds to forestall mangling of "From " in transit, it has been pointed out that stuffing "From " with "- " safely masks the offending sequence. On the receiving end, the stuffed line automatically reverts cleanly to the original text, without any special handling. This may be the sanest way to handle that case. Comments? -- John J. Kane Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASFACn18337 for ietf-openpgp-bks; Wed, 28 Nov 2001 07:10:12 -0800 (PST) Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASFAA818332 for ; Wed, 28 Nov 2001 07:10:10 -0800 (PST) Received: from sobolev.does-not-exist.org (d-dialin-2451.addcom.de [213.61.80.51]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id QAA29302; Wed, 28 Nov 2001 16:08:44 +0100 (CET) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 21FC42ED15; Wed, 28 Nov 2001 16:07:58 +0100 (CET) Date: Wed, 28 Nov 2001 16:07:58 +0100 From: Thomas Roessler To: whom it may concern: ; Subject: MIME polymorphism Message-ID: <20011128150758.GA2128@sobolev.does-not-exist.org> Reply-To: roessler@does-not-exist.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline User-Agent: Mutt/1.3.23.2i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The two major e-mail security protocols currently proposed - S/MIME and PGP/MIME - both build on the fundamental framework of multipart/signed messages specified in RFC 1847. In this framework, the data to be signed is formatted as a single MIME part (which may, of course, contain nested sub-parts). This MIME part is then hashed for the signature. The hash does, in particular, include all the meta infomration present on the MIME level, including the body part's content type. That way, the signature does, for instance, include the information whether some PostScript code which was signed should be interpreted by a postscript interpreter for display (application/postscript), or whether this code should just be displayed as plain text (text/plain). In theory, with multipart/signed, the actual data and the information how it must be interpreted is both signed and protected. This theory fails on two levels: First, knowing a file's content type is not sufficient to guarantee correct interpretation. This has been demonstrated before; think about differences in the interpretation of certain special characters when documents are exchanged between some Microsoft Word versions for the Windows and Macintosh platforms. [4] Second, the theory is based on the assumption that the interpretation of the MIME meta information contained in Content-* headers is well-defined. This assumption is violated with malformed MIME messages which contain contradictory information: When there are, for instance, multiple boundary parameters for a single multipart/* attachment, implementations will generally follow the mantra of being liberal in what they accept, and just choose one. When there are multiple Content-Type headers present on a single attachment, implementations will likewise be liberal, and choose one (or even mix information from the two headers). Since the choices made differ between MIME implementations, it is for instance easily possible to create an e-mail mesage with a multipart/mixed body which seems to contain different content, depending on whether it's displayed with mutt [5] or pine [6]. Note that this problem does not only apply to digital signatures, but also to virus scanners: If these try to be liberal with respect to malformed MIME messages, they may easily check attachments for viruses which will never be seen by users - and, likewise, they may not scan those attachments which are actually displayed by users' software. To prevent this problem from occuring, security services must not be liberal in what they accept, or try to hide possible problems from users. Instead of software silently making choices, ambiguities must be treated as malicious, and users must be warned. References: 1. Galvin, Murphy, Crocker, Freed: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted. RFC 1847, October 1995. 2. Freed, Borenstein: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045, November 1996. 3. Elkins, Del Torto, Levien, Roessler: MIME Security with OpenPGP. RFC 3156, August 2001. 4. Fox, Zu einem prinzipiellen Problem digitaler Signaturen, Datenschutz und Datensicherheit (DuD) 7/1998, pp. 386-388. 5. Mutt home page: 6. Pine Information Center: -- Thomas Roessler http://log.does-not-exist.org/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJ9fDk03644 for ietf-openpgp-bks; Mon, 19 Nov 2001 01:41:13 -0800 (PST) Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAJ9fB803639 for ; Mon, 19 Nov 2001 01:41:11 -0800 (PST) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.1/8.12.1) with ESMTP id fAJ9ex9Q022287 for ; Mon, 19 Nov 2001 10:40:59 +0100 Received: (from news@localhost) by branwen.iks-jena.de (8.12.1/8.12.1/Submit) id fAJ9ewBa022286 for ietf-openpgp@imc.org; Mon, 19 Nov 2001 10:40:58 +0100 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC) Organization: IKS GmbH Jena Lines: 22 Message-ID: References: <3BEA43A4.3CEF218E@saiknes.lv> <87zo5xh5mz.fsf@alberti.gnupg.de> NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1006162858 22074 217.17.192.37 (19 Nov 2001 09:40:58 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Mon, 19 Nov 2001 09:40:58 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Florian Weimer wrote: >Werner Koch writes: >> On Thu, 08 Nov 2001 10:34:44 +0200, disastry said: >> rfc2440b03> extends until the end of the file. In general, an implementation >> rfc2440b03> SHOULD NOT use indeterminate length packets except where the end >> rfc2440b03> of the data will be clear from the context, >> >> > it does not talks about compression, >> >> Well, the "clear from context" is exactly the case for compressed >> packets because the zip algorithm has its own length management. > >As far as I understand this description, "clear from context" means >"clear from the OpenPGP context", e.g., the packet is contained in a >larger packet which has got a length limitation, or it is the last one >in an OpenPGP message. Yes and no. ;-) The senctence was coined by describing the 2.6.2ff. implementation. This implementation does terminate the packet on the end of compressed data as Werner said, but never generate further packets as Florian remarked. So Werner is right by implementation and Florian is right by phenomenology. Received: by above.proper.com (8.11.6/8.11.3) id fAH6B2K20032 for ietf-openpgp-bks; Fri, 16 Nov 2001 22:11:02 -0800 (PST) Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH6B0820025 for ; Fri, 16 Nov 2001 22:11:01 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id fAH6Ajs06344 for ietf-openpgp@imc.org; Sat, 17 Nov 2001 01:10:45 -0500 Date: Sat, 17 Nov 2001 01:10:45 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: interop/encryption to pgp2 Message-ID: <20011117011045.C659@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20011116170525.B388@fargonauten.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011116170525.B388@fargonauten.de>; from ingo@fargonauten.de on Fri, Nov 16, 2001 at 05:05:25PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Crescent (4% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 16, 2001 at 05:05:25PM -0800, Ingo Luetkebohle wrote: > Hi, >=20 > David Shaw just pointed out that PGP2.6.2 chokes when it receives a > message that has been encrypted to a v4 key, even when it has been > encrypted to a v3 key, too.=20 >=20 > I can only assume that this is because public-key encrypted session > key packets allow non-RSA cipher material. Can anybody who has a > working knowledge of the old code confirm this? It can also be the size of the key. V4 RSA keys that are greater than 2048 bits long will cause PGP 2.6.2 to fail with various odd errors. V4 RSA keys <=3D 2048 bits long can be mixed in with v3 keys without causing any problems. David --=20 David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6b (GNU/Linux) iQEVAwUBO/X/ZYccwqs8s7QVAQE1tAf+KWAVEHm3GZyM/zkCRLz9Nn3xNjsDFvYa q82xBOEf6ynuEHoSpbl6e08XMnIPdrCQAv3fjy0v6hKM53vJXHlus3xcE9QwZOZR L4c2ziwK8DqgG7BiU3RtYkzt++7kMzz8dVeYQduFG7HN80aFLIfPf0oa7BOxs68U v8K6jssXwXK3Wc5gSQyR38waOVABtIlCFkr7DR7e/60UP3Kqhi6yVSpM9Umxv6JS P82GoFtmxXqYjvuPX1m2uUDa1Iq4TlcE+rnvWHnQ9SQYiyWLx/we0f4sKz7NRr8s TZLwO31s6yVAZ+34KZTV1zYc0mopVssoaJUMn9CrW+BZkpMW093QaA== =v2N/ -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH4TRn18586 for ietf-openpgp-bks; Fri, 16 Nov 2001 20:29:27 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH4TP818582 for ; Fri, 16 Nov 2001 20:29:25 -0800 (PST) Received: from [192.168.1.180] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 16 Nov 2001 20:29:15 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: <20011116170525.B388@fargonauten.de> Date: Fri, 16 Nov 2001 20:29:05 -0800 To: Derek Atkins , ingo@fargonauten.de From: Jon Callas Subject: Re: interop/encryption to pgp2 Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:30 PM -0500 11/16/01, Derek Atkins wrote: >Basically, the only thing you can do is, if you're using -ANY- >non-RFC1991 packets, you should emit a leading "nonce" header that >declares the message to be a non-RFC1991 message. IIRC, in PGP 5.0 we >did this via a two-byte leading sequence followed by the three ASCII >characters P, G, and P. I'd have to go look at the code to figure out >what the leading bytes were. Marker Packet -- Section 5.8 of 2440. I'll note that while OpenPGP encourages interoperating with 2.6.2, it is not required. It is not quite deprecated, but there are weasel words in 2440 that permit "breaking" 2440 in a few cases for 2.6.2 compatibility. So 2.6.2 compatibility will get you a golf clap, but it shouldn't stand in the way of getting us to Draft Standard. Jon Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH1Usj11071 for ietf-openpgp-bks; Fri, 16 Nov 2001 17:30:54 -0800 (PST) Received: from benjamin.ihtfp.org (BENJAMIN.IHTFP.ORG [204.107.200.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH1Uq811065 for ; Fri, 16 Nov 2001 17:30:52 -0800 (PST) Received: (from warlord@localhost) by benjamin.ihtfp.org (8.9.3) id UAA05568; Fri, 16 Nov 2001 20:30:49 -0500 To: ingo@fargonauten.de Cc: ietf-openpgp@imc.org Subject: Re: interop/encryption to pgp2 References: <20011116170525.B388@fargonauten.de> From: Derek Atkins Date: 16 Nov 2001 20:30:48 -0500 In-Reply-To: Ingo Luetkebohle's message of "Fri, 16 Nov 2001 17:05:25 -0800" Message-ID: Lines: 56 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: PGP 2.6.2 does not handle any new-style packets, even if it's only part of a message. If PGP 2.6.2 doesn't understand _any_ packet, it will barf. Basically, the only thing you can do is, if you're using -ANY- non-RFC1991 packets, you should emit a leading "nonce" header that declares the message to be a non-RFC1991 message. IIRC, in PGP 5.0 we did this via a two-byte leading sequence followed by the three ASCII characters P, G, and P. I'd have to go look at the code to figure out what the leading bytes were. -derek Ingo Luetkebohle writes: > --1UWUbFP1cBYEclgG > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > Hi, > > David Shaw just pointed out that PGP2.6.2 chokes when it receives a > message that has been encrypted to a v4 key, even when it has been > encrypted to a v3 key, too.=20 > > I can only assume that this is because public-key encrypted session > key packets allow non-RSA cipher material. Can anybody who has a > working knowledge of the old code confirm this? > > If this is the case, would it be possible to introduce a v4 packet of > that type? Would that be ignored by PGP2, so that having both v3 and > v4 public key encrypted session key packets would work with pgp2? > > Ingo > > --1UWUbFP1cBYEclgG > Content-Type: application/pgp-signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Weitere Infos: siehe http://www.gnupg.org > > iD8DBQE79bfVzZDBZDStzlsRAvfoAJ9No97fDMgoVCdCIEVRPu5rV+mJuQCeJB/P > XkZYDFmyylSMnNKMxtUNn3o= > =5kFE > -----END PGP SIGNATURE----- > > --1UWUbFP1cBYEclgG-- -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAH15Tu08857 for ietf-openpgp-bks; Fri, 16 Nov 2001 17:05:29 -0800 (PST) Received: from pick.home.fargonauten.de (bkhm57kiy18ei.bc.hsia.telus.net [64.180.242.187] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAH15S808851 for ; Fri, 16 Nov 2001 17:05:28 -0800 (PST) Received: by pick.home.fargonauten.de (Postfix, from userid 1000) id A7333937CE; Fri, 16 Nov 2001 17:05:25 -0800 (PST) Date: Fri, 16 Nov 2001 17:05:25 -0800 From: Ingo Luetkebohle To: ietf-openpgp@imc.org Subject: interop/encryption to pgp2 Message-ID: <20011116170525.B388@fargonauten.de> Reply-To: ingo@fargonauten.de Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1UWUbFP1cBYEclgG" Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --1UWUbFP1cBYEclgG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, David Shaw just pointed out that PGP2.6.2 chokes when it receives a message that has been encrypted to a v4 key, even when it has been encrypted to a v3 key, too.=20 I can only assume that this is because public-key encrypted session key packets allow non-RSA cipher material. Can anybody who has a working knowledge of the old code confirm this? If this is the case, would it be possible to introduce a v4 packet of that type? Would that be ignored by PGP2, so that having both v3 and v4 public key encrypted session key packets would work with pgp2? Ingo --1UWUbFP1cBYEclgG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Weitere Infos: siehe http://www.gnupg.org iD8DBQE79bfVzZDBZDStzlsRAvfoAJ9No97fDMgoVCdCIEVRPu5rV+mJuQCeJB/P XkZYDFmyylSMnNKMxtUNn3o= =5kFE -----END PGP SIGNATURE----- --1UWUbFP1cBYEclgG-- Received: by above.proper.com (8.11.6/8.11.3) id fAGG2TF12881 for ietf-openpgp-bks; Fri, 16 Nov 2001 08:02:29 -0800 (PST) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAGG2R812874 for ; Fri, 16 Nov 2001 08:02:27 -0800 (PST) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.33 #1) id 164lQG-0002xz-00 for ietf-openpgp@imc.org; Fri, 16 Nov 2001 17:00:56 +0100 To: ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <3BEA43A4.3CEF218E@saiknes.lv> <87zo5xh5mz.fsf@alberti.gnupg.de> From: Florian Weimer Date: 16 Nov 2001 17:00:56 +0100 In-Reply-To: <87zo5xh5mz.fsf@alberti.gnupg.de> (Werner Koch's message of "Thu, 08 Nov 2001 12:19:16 +0100") Message-ID: Lines: 22 User-Agent: Gnus/5.090001 (Oort Gnus v0.01) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On Thu, 08 Nov 2001 10:34:44 +0200, disastry said: > > rfc2440b03> extends until the end of the file. In general, an implementation > rfc2440b03> SHOULD NOT use indeterminate length packets except where the end > rfc2440b03> of the data will be clear from the context, > > > it does not talks about compression, > > Well, the "clear from context" is exactly the case for compressed > packets because the zip algorithm has its own length management. As far as I understand this description, "clear from context" means "clear from the OpenPGP context", e.g., the packet is contained in a larger packet which has got a length limitation, or it is the last one in an OpenPGP message. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 Received: by above.proper.com (8.11.6/8.11.3) id fA93jQm26428 for ietf-openpgp-bks; Thu, 8 Nov 2001 19:45:26 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA93jP826424 for ; Thu, 8 Nov 2001 19:45:25 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA93hk9I007806; Thu, 8 Nov 2001 19:43:46 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200111082050.JAA22264@ruru.cs.auckland.ac.nz> References: <200111082050.JAA22264@ruru.cs.auckland.ac.nz> X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 8 Nov 2001 19:38:13 -0800 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: John W Noerenberg II Subject: segmented packets (was Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?)) Cc: pgut001@cs.auckland.ac.nz, disastry@saiknes.lv, ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:50 AM +1300 11/9/01, Peter Gutmann wrote: >John W Noerenberg II writes: > >>What I'm mainly concerned with as far as interoperability on this point is >>whether implementations support segmented packets, and the interpretation of >>of the data is consistent across implementations. > >Mine doesn't. If I get a huge amount of demand for it (which seems unlikely, >since none of the PGP versions I've got installed seem to produce them under >normal usage) I may add decode-only support for them. I've got an example that uses segmented packets generated with PGP 7.0.3! What I did was encrypt and sign a 2K text file. I can't tell you why PGP 7.0.3 uses a segmented packet, but it certainly does. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8KpDF15854 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:51:13 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8KpA815847 for ; Thu, 8 Nov 2001 12:51:10 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id JAA17183; Fri, 9 Nov 2001 09:50:26 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id JAA22264; Fri, 9 Nov 2001 09:50:25 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 09:50:25 +1300 (NZDT) Message-ID: <200111082050.JAA22264@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jwn2@qualcomm.com, pgut001@cs.auckland.ac.nz Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John W Noerenberg II writes: >What I'm mainly concerned with as far as interoperability on this point is >whether implementations support segmented packets, and the interpretation of >of the data is consistent across implementations. Mine doesn't. If I get a huge amount of demand for it (which seems unlikely, since none of the PGP versions I've got installed seem to produce them under normal usage) I may add decode-only support for them. Peter. Received: by above.proper.com (8.11.6/8.11.3) id fA8K7s513840 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:07:54 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8K7r813836 for ; Thu, 8 Nov 2001 12:07:53 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA8K6H9I007779; Thu, 8 Nov 2001 12:06:18 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> References: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 8 Nov 2001 11:53:43 -0800 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: John W Noerenberg II Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:02 AM +1300 11/9/01, Peter Gutmann wrote: >Urgh, I hope no-one interprets it that way. The partial-length encoding is >incredibly painful to use with its silly power-of-two restriction (you can't >just say "This is what I've got so far, the next lot starts here" but have to >chop it up into little power-of-two length pieces just to fit the *&#^$&#* >length-encoding mechanism). GPG uses the definite-length format where it can >and 0xA3 where it can't (compressed data), something I agree with >wholeheartedly. What I'm mainly concerned with as far as interoperability on this point is whether implementations support segmented packets, and the interpretation of of the data is consistent across implementations. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8K6TC13785 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:06:29 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8K6S813781 for ; Thu, 8 Nov 2001 12:06:28 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA8K6H9K007779; Thu, 8 Nov 2001 12:06:23 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <20011106.132424.68557949.kazu@iijlab.net> References: <20011106.132424.68557949.kazu@iijlab.net> X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Thu, 8 Nov 2001 11:58:41 -0800 To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) From: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:24 PM +0900 11/6/01, Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) wrote: >Another PGP parser can be found: > http://pgp.iijlab.net/pgpdump.html > >Web interface is also available. Thanks, Kazu. I'll have a look. At 12:19 PM -0800 11/6/01, Len Sassaman wrote: >GnuPG has such a parser built into it. Also, there's a perl script written >by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing. It will be interesting to compare the different parsers. I suspect each will have their uses. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8K1TE13648 for ietf-openpgp-bks; Thu, 8 Nov 2001 12:01:29 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA8K1R813644 for ; Thu, 8 Nov 2001 12:01:27 -0800 (PST) Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA28473; Thu, 8 Nov 2001 11:59:01 -0800 Date: Thu, 8 Nov 2001 11:59:01 -0800 From: hal@finney.org Message-Id: <200111081959.LAA28473@finney.org> To: pgut001@cs.auckland.ac.nz, warlord@mit.edu Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins writes: > The reason Colin and I came up with this idea was the belief that > a) we might want to encode data longer than 32 bits, and > b) we needed a way to differentiate ourselves with the > then-existing PGP 2.x length-encoding scheme Actually at NAI we have used this scheme to be able to handle > 2^32 bit files for one of our applications. It was an astonishingly easy modification to the code to be able to handle such large buffers, thanks to Derek's and Colin's design, which we are still using. In fact it really came down to a two-line change to set the flag to use partial body length packets in this case, and everything else worked automatically. Most of the work was in identifying that the file was > 2^32 bits and changing the APIs to pass that information into the place where it was needed. Hal Received: by above.proper.com (8.11.6/8.11.3) id fA8JZhl11723 for ietf-openpgp-bks; Thu, 8 Nov 2001 11:35:43 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.72.0.53]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8JZf811717 for ; Thu, 8 Nov 2001 11:35:41 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA27255; Thu, 8 Nov 2001 14:35:41 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA25146; Thu, 8 Nov 2001 14:35:41 -0500 (EST) Received: from alice-whacker.mit.edu (ALICE-WHACKER.MIT.EDU [18.187.1.68]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12213; Thu, 8 Nov 2001 14:35:33 -0500 (EST) Received: (from warlord@localhost) by alice-whacker.mit.edu (8.9.3) id OAA24906; Thu, 8 Nov 2001 14:35:33 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <200111081925.IAA20711@ruru.cs.auckland.ac.nz> From: Derek Atkins Date: 08 Nov 2001 14:35:33 -0500 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Fri, 9 Nov 2001 08:25:52 +1300 (NZDT)" Message-ID: Lines: 41 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well, the whole point of indefinite-length encoding was to encode something when you didn't know how long it was. For example: run-some-command | pgp | some-other-command In this case, you don't know how long the input is going to be, therefore you want to use indefinite-length encoding. On the other hand, if you can 'stat()' the source file ahead of time, you should DEFINITELY use definite-length encoding. -derek pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Derek Atkins writes: > >>If only it were that easy. Consider what happens when someone says "You have a > >>900K transfer buffer, stream data through it". > > > >Do you mean you have 900K to transfer, or you have a buffer of 900K that you > >can use to buffer something larger? In either case, I'd use the largest > >buffer-size that fits (i.e. 512K in this case) and just eat the rest of the > >buffer. > > I don't control it, I'm told "Here's an xK buffer, employ it optimally" (as a > generalisation of that, any encoding method which forces a certain > implementation style to the exclusion of others is a bad idea. In this > instance it makes it extremely painful to use arbitrary-sized buffers). > > >it's what we came up with at the time. > > There's a simple solution, which is to avoid it where possible (it's not > actually needed anywhere except maybe a few special-case situations, so you can > use definite-length encoding and 0xA3 in most cases). > > Peter. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8JQUZ11423 for ietf-openpgp-bks; Thu, 8 Nov 2001 11:26:30 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8JQS811419 for ; Thu, 8 Nov 2001 11:26:28 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id IAA15139; Fri, 9 Nov 2001 08:25:52 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id IAA20711; Fri, 9 Nov 2001 08:25:52 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 08:25:52 +1300 (NZDT) Message-ID: <200111081925.IAA20711@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, warlord@mit.edu Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins writes: >>If only it were that easy. Consider what happens when someone says "You have a >>900K transfer buffer, stream data through it". > >Do you mean you have 900K to transfer, or you have a buffer of 900K that you >can use to buffer something larger? In either case, I'd use the largest >buffer-size that fits (i.e. 512K in this case) and just eat the rest of the >buffer. I don't control it, I'm told "Here's an xK buffer, employ it optimally" (as a generalisation of that, any encoding method which forces a certain implementation style to the exclusion of others is a bad idea. In this instance it makes it extremely painful to use arbitrary-sized buffers). >it's what we came up with at the time. There's a simple solution, which is to avoid it where possible (it's not actually needed anywhere except maybe a few special-case situations, so you can use definite-length encoding and 0xA3 in most cases). Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8J3Y009926 for ietf-openpgp-bks; Thu, 8 Nov 2001 11:03:34 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8J3X809922 for ; Thu, 8 Nov 2001 11:03:33 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12268; Thu, 8 Nov 2001 14:03:33 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA26216; Thu, 8 Nov 2001 14:00:42 -0500 (EST) Received: from alice-whacker.mit.edu (ALICE-WHACKER.MIT.EDU [18.187.1.68]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA27097; Thu, 8 Nov 2001 13:57:45 -0500 (EST) Received: (from warlord@localhost) by alice-whacker.mit.edu (8.9.3) id NAA24691; Thu, 8 Nov 2001 13:57:45 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <200111081846.HAA19709@ruru.cs.auckland.ac.nz> From: Derek Atkins Date: 08 Nov 2001 13:57:45 -0500 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Fri, 9 Nov 2001 07:46:24 +1300 (NZDT)" Message-ID: Lines: 40 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > If only it were that easy. Consider what happens when someone says "You have a > 900K transfer buffer, stream data through it". Instead of being able to drop a Do you mean you have 900K to transfer, or you have a buffer of 900K that you can use to buffer something larger? In either case, I'd use the largest buffer-size that fits (i.e. 512K in this case) and just eat the rest of the buffer. > simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write > it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K > chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc. > Because the amount of expansion is variable-length, depending on the size of > the I/O buffer I have to precalculate the encoding expansion beforehand and > reduce the data amount read by that amount to see what it'll take to optimally > fill the buffer, and because I have to keep dropping in partial-length headers > all over the place I can't do a single I/O but have to do it all in dribs and > drabs, and in general do a lot of unnecessary work (both in terms of writing > code and CPU time) and waste a lot more space in encoding than simply using a > 32-bit length would have. The reason Colin and I came up with this idea was the belief that a) we might want to encode data longer than 32 bits, and b) we needed a way to differentiate ourselves with the then-existing PGP 2.x length-encoding scheme So, based on these constraints, we couldn't use a simple 32-bit length encoding without adding extra bytes to the overhead. Perhaps this was a poor choice, but it's what we came up with at the time. > Peter. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: by above.proper.com (8.11.6/8.11.3) id fA8IlR109448 for ietf-openpgp-bks; Thu, 8 Nov 2001 10:47:27 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8IlP809444 for ; Thu, 8 Nov 2001 10:47:25 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA13941; Fri, 9 Nov 2001 07:46:24 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA19709; Fri, 9 Nov 2001 07:46:24 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 07:46:24 +1300 (NZDT) Message-ID: <200111081846.HAA19709@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, warlord@mit.edu Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: warlord@ALICE-WHACKER.MIT.EDU writes: >pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: >>Urgh, I hope no-one interprets it that way. The partial-length encoding is >>incredibly painful to use with its silly power-of-two restriction (you can't >>just say "This is what I've got so far, the next lot starts here" but have to >>chop it up into little power-of-two length pieces just to fit the *&#^$&#* >>length-encoding mechanism). GPG uses the definite-length format where it can >>and 0xA3 where it can't (compressed data), something I agree with >>wholeheartedly. > >Come on, Peter... If you have to buffer 4K-bytes, is that so horrible? If only it were that easy. Consider what happens when someone says "You have a 900K transfer buffer, stream data through it". Instead of being able to drop a simple 32-bit length at the start and read in 899,996 bytes, encrypt, and write it out again, I have to break off a 512K chunk, then a 256K chunk, then a 64K chunk, then a 32K chunk, then an 8K chunk, then a 4K chunk, etc etc etc. Because the amount of expansion is variable-length, depending on the size of the I/O buffer I have to precalculate the encoding expansion beforehand and reduce the data amount read by that amount to see what it'll take to optimally fill the buffer, and because I have to keep dropping in partial-length headers all over the place I can't do a single I/O but have to do it all in dribs and drabs, and in general do a lot of unnecessary work (both in terms of writing code and CPU time) and waste a lot more space in encoding than simply using a 32-bit length would have. Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8IUag08840 for ietf-openpgp-bks; Thu, 8 Nov 2001 10:30:36 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8IUY808835 for ; Thu, 8 Nov 2001 10:30:34 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01587; Thu, 8 Nov 2001 13:30:34 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA14885; Thu, 8 Nov 2001 13:30:32 -0500 (EST) Received: from alice-whacker.mit.edu (ALICE-WHACKER.MIT.EDU [18.187.1.68]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25154; Thu, 8 Nov 2001 13:30:29 -0500 (EST) Received: (from warlord@localhost) by alice-whacker.mit.edu (8.9.3) id NAA24440; Thu, 8 Nov 2001 13:30:28 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Cc: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> From: Derek Atkins Date: 08 Nov 2001 13:30:28 -0500 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Fri, 9 Nov 2001 07:02:39 +1300 (NZDT)" Message-ID: Lines: 24 X-Mailer: Gnus v5.7/Emacs 20.7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Urgh, I hope no-one interprets it that way. The partial-length encoding is > incredibly painful to use with its silly power-of-two restriction (you can't > just say "This is what I've got so far, the next lot starts here" but have to > chop it up into little power-of-two length pieces just to fit the *&#^$&#* > length-encoding mechanism). GPG uses the definite-length format where it can > and 0xA3 where it can't (compressed data), something I agree with > wholeheartedly. Come on, Peter... If you have to buffer 4K-bytes, is that so horrible? Besides, if you're doing a streaming application where you don't want to buffer, you're better off packetizing anyways instead of making one large stream. > Peter. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA8I2n007771 for ietf-openpgp-bks; Thu, 8 Nov 2001 10:02:49 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8I2l807767 for ; Thu, 8 Nov 2001 10:02:47 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id HAA13071; Fri, 9 Nov 2001 07:02:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id HAA18648; Fri, 9 Nov 2001 07:02:39 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Fri, 9 Nov 2001 07:02:39 +1300 (NZDT) Message-ID: <200111081802.HAA18648@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: disastry@saiknes.lv writes: >rfc2440b03>4.2.1. Old-Format Packet Lengths >rfc2440b03>[snip] >rfc2440b03> The meaning of the length-type in old-format packets is: >rfc2440b03> 3 - The packet is of indeterminate length. The header is 1 octet >rfc2440b03> long, and the implementation must determine how long the packet >rfc2440b03> is. If the packet is in a file, this means that the packet >rfc2440b03> extends until the end of the file. In general, an implementation >rfc2440b03> SHOULD NOT use indeterminate length packets except where theend >rfc2440b03> of the data will be clear from the context, > >it does not talks about compression, so I think it should be the same for any >packet type In general indefinite-length packets are a pain, you can avoid them in all cases except compressed-data where you don't know the length in advance (and maybe a few oddball streaming applications). Although the standard doesn't say it, common sense would dictate using the definite-length encoding for all but compressed data. >rfc2440b03>4.2.3. Packet Length Examples >rfc2440b03>[snip] >rfc2440b03> An implementation MAY use Partial Body Lengths for data packets,be > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >rfc2440b03> they literal, compressed, or encrypted. The first partial length > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >rfc2440b03> MUST be at least 512 octets long. Partial Body Lengths MUST NOT be >rfc2440b03> used for any other packet types. > >so it is ok for all data packets.. Urgh, I hope no-one interprets it that way. The partial-length encoding is incredibly painful to use with its silly power-of-two restriction (you can't just say "This is what I've got so far, the next lot starts here" but have to chop it up into little power-of-two length pieces just to fit the *&#^$&#* length-encoding mechanism). GPG uses the definite-length format where it can and 0xA3 where it can't (compressed data), something I agree with wholeheartedly. Peter. Received: by above.proper.com (8.11.6/8.11.3) id fA8BHa409538 for ietf-openpgp-bks; Thu, 8 Nov 2001 03:17:36 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8BHX809534 for ; Thu, 8 Nov 2001 03:17:34 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 161nN2-0007pq-00; Thu, 08 Nov 2001 12:29:20 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 161nDJ-0007Mr-00; Thu, 08 Nov 2001 12:19:17 +0100 To: disastry@saiknes.lv Cc: ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) References: <3BEA43A4.3CEF218E@saiknes.lv> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 08 Nov 2001 12:19:16 +0100 In-Reply-To: <3BEA43A4.3CEF218E@saiknes.lv> (disastry@saiknes.lv's message of "Thu, 08 Nov 2001 10:34:44 +0200") Message-ID: <87zo5xh5mz.fsf@alberti.gnupg.de> Lines: 30 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 08 Nov 2001 10:34:44 +0200, disastry said: rfc2440b03> extends until the end of the file. In general, an implementation rfc2440b03> SHOULD NOT use indeterminate length packets except where the end rfc2440b03> of the data will be clear from the context, > it does not talks about compression, Well, the "clear from context" is exactly the case for compressed packets because the zip algorithm has its own length management. > but gpg implements this different way than in RFC1991 and RFC2440: Not if you give --openpgp or when the recipient uses a v4 key. I used the other method to implement the indefinite length packets before I knew about the OpenPGP WG. > other interoperability problem is that gpg puts > signature after the data packet, pgp expect it before.. > I think it is because gpg wants to do all in > one pass without seeking or using temporary files. Exactly. I have suggested to write a wrapper which swaps the sequence. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA88hwS21184 for ietf-openpgp-bks; Thu, 8 Nov 2001 00:43:58 -0800 (PST) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA88ht821168 for ; Thu, 8 Nov 2001 00:43:56 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 08 Nov 2001 09:34:44 +0200 Message-ID: <3BEA43A4.3CEF218E@saiknes.lv> Date: Thu, 08 Nov 2001 10:34:44 +0200 From: disastry@saiknes.lv Organization: disastry.NO.SPaM.NET X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interopknowledge base?) 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Werner Koch wrote: > On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > > > answer. The issue was that GnuPG used an old-style indeterminate-length > > packet for the plaintext before the MDC (see my message of August 23 > > But only if the plaintext is a compressed packet - right? > > Werner rfc2440b03> 4.2.1. Old-Format Packet Lengths rfc2440b03> [snip] rfc2440b03> The meaning of the length-type in old-format packets is: rfc2440b03> 3 - The packet is of indeterminate length. The header is 1 octet rfc2440b03> long, and the implementation must determine how long the packet rfc2440b03> is. If the packet is in a file, this means that the packet rfc2440b03> extends until the end of the file. In general, an implementation rfc2440b03> SHOULD NOT use indeterminate length packets except where the end rfc2440b03> of the data will be clear from the context, it does not talks about compression, so I think it should be the same for any packet type rfc2440b03> 4.2.3. Packet Length Examples rfc2440b03> [snip] rfc2440b03> An implementation MAY use Partial Body Lengths for data packets, be ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rfc2440b03> they literal, compressed, or encrypted. The first partial length ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ rfc2440b03> MUST be at least 512 octets long. Partial Body Lengths MUST NOT be rfc2440b03> used for any other packet types. so it is ok for all data packets.. rfc1991> 4.1 Packet structure fields rfc1991> [snip] rfc1991> 11 - no packet length supplied, unknown packet length rfc1991> [snip] rfc1991> A value of 11 is currently used in one place: on compressed data. rfc1991> That is, a compressed data block currently looks like , rfc1991> where , binary 10 1000 11, is an indefinite-length packet. The rfc1991> proper interpretation is "until the end of the enclosing structure", rfc1991> although it should never appear outermost (where the enclosing rfc1991> structure is a file). 'currently used in one place' is not the same as 'MUST/SHOULD be used in one place'. so I think it's ok to use 'unknown packet length' for other than compressed packets but gpg implements this different way than in RFC1991 and RFC2440: doc\DETAILS> Packet Headers doc\DETAILS> [snip] doc\DETAILS> + It works like this: After the CTB (with a length field of 11) a doc\DETAILS> + marker field is used, which gives the length of the following datablock. doc\DETAILS> + This is a simple 2 byte field (MSB first) containing the amount of data doc\DETAILS> + following this field, not including this length field. After this datablock doc\DETAILS> + another length field follows, which gives the size of the next datablock. doc\DETAILS> + A value of 0 indicates the end of the packet. The maximum size of a doc\DETAILS> + data block is limited to 65534, thereby reserving a value of 0xffff for doc\DETAILS> + future extensions. other interoperability problem is that gpg puts signature after the data packet, pgp expect it before.. I think it is because gpg wants to do all in one pass without seeking or using temporary files. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBO+lTFjBaTVEuJQxkEQO4ygCfYLMPK9yLSplSO1Gm8iGWTHZJibMAoNcs HXqktgfnXYl4hg2158xR7UEd =QaId -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA7IB7n05193 for ietf-openpgp-bks; Wed, 7 Nov 2001 10:11:07 -0800 (PST) Received: from hotmail.com (oe57.law3.hotmail.com [209.185.240.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA7IB5805189 for ; Wed, 7 Nov 2001 10:11:05 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 7 Nov 2001 10:11:02 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <20011106.132424.68557949.kazu@iijlab.net><009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> <87r8rbknls.fsf@alberti.gnupg.de> Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) Date: Wed, 7 Nov 2001 13:09:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 07 Nov 2001 18:11:02.0334 (UTC) FILETIME=[8F43B5E0:01C167B7] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Werner Koch" To: "Michael Young" Cc: Sent: Wednesday, November 07, 2001 3:10 AM Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) > > On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > > > answer. The issue was that GnuPG used an old-style indeterminate-length > > packet for the plaintext before the MDC (see my message of August 23 > > But only if the plaintext is a compressed packet - right? > > Werner ----- Original Message ----- From: "Werner Koch" To: "Michael Young" Cc: Sent: Wednesday, November 07, 2001 3:10 AM Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) > > On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > > > answer. The issue was that GnuPG used an old-style indeterminate-length > > packet for the plaintext before the MDC (see my message of August 23 > > But only if the plaintext is a compressed packet - right? > > Werner here is the url for the pgpdump web interface: http://xdv.org/pgpdump/ here is the output for a message encrypted to an rsa key using gpg with twofish as the algorithm: PGPdump Results Old: Public-Key Encrypted Session Key Packet(tag 1)(268 bytes) New version(3) Key ID - f1 56 64 88 f7 7a ff 7b Pub alg - RSA Encrypt or Sign(pub 1) RSA m^e mod n(2047 bits) - 78 02 54 44 fd 0b ec 0d 44 de 38 f8 95 f4 8d 89 0a 92 4a 47 4e f8 84 55 38 47 24 1a 3e 91 36 9f 72 32 21 54 43 f5 8b 4f be 1d ce 4c ec ac 87 89 85 f0 ae 2c a7 48 c8 e0 31 aa 42 88 68 41 51 56 84 6b bc 0a a1 9d 50 9b f8 7b 35 96 82 d7 9b 77 e6 95 b1 83 77 13 f2 bb c1 0b 28 9a e8 f9 ac 09 10 8d 93 84 92 5b 95 8c 7a a9 43 44 6d 38 a7 40 46 ef a6 86 2c bc 1c ae 2b 27 0d 48 34 d9 c3 89 d3 7b ef a9 b3 b7 dd 9d 87 80 30 26 8f b1 0d a6 a7 ba d0 aa 6c 3e 76 6d 82 ac 72 88 14 eb 90 8f 8e b8 29 bf ed 5a 07 46 93 02 ae 0e d4 46 3f df 6d 29 6b 70 70 a6 20 8a 95 83 4c dc 7e 69 e9 69 56 a1 a6 8d fd ab 79 38 1d 93 da b8 1f d1 78 84 84 7b 48 74 d8 66 94 64 5d 8a 88 61 fb 14 de ba 4e 33 1c 6f ba 84 70 02 28 11 4f 05 ba 7d 4f 2e c6 f4 92 7a 99 cc 5d e6 98 e3 4f 24 7c df f9 57 -> m = sym alg(1 byte) + checksum(2 bytes) + PKCS-1 block type 02 New: Symmetrically Encrypted and MDC Packet(tag 18)(70 bytes) Ver 1 Encrypted data (plain text + MDC SHA1(20 bytes)) PGPdump Interface, Copyright (c) 2001, Stefan H. Holek, stefan@epy.co.at is there any additional mdc information necessary/desirable to be displayed? vedaal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA7FpWO25659 for ietf-openpgp-bks; Wed, 7 Nov 2001 07:51:32 -0800 (PST) Received: from walrus.jabberwocky.com (walrus.ne.mediaone.net [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA7FpU825655 for ; Wed, 7 Nov 2001 07:51:30 -0800 (PST) Received: from claude.kendall.akamai.com (ppp-216-158-59-64.cust.oldcity.dca.net [216.158.59.64]) by walrus.jabberwocky.com (8.9.3/8.9.3) with ESMTP id KAA31416; Wed, 7 Nov 2001 10:50:28 -0500 Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.9.3/8.9.3) id KAA01516; Wed, 7 Nov 2001 10:50:17 -0500 Date: Wed, 7 Nov 2001 10:50:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Cc: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? Message-ID: <20011107105017.A1479@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org, John W Noerenberg II References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rabbi@quickie.net on Tue, Nov 06, 2001 at 12:19:45PM -0800 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (60% of Full) X-Pointless-Random-Number: 96 X-Silly-Header: It sure is. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Nov 06, 2001 at 12:19:45PM -0800, Len Sassaman wrote: > > On Mon, 5 Nov 2001, John W Noerenberg II wrote: > > > I've heard tell of similar programs, but I don't have particular > > knowledge of any. -- > > GnuPG has such a parser built into it. Also, there's a perl script written > by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing. The new (currently in test) GnuPG also comes with "gpgsplit" which breaks OpenPGP messages into their constituent packets. It's quite handy for comparing the output of two different programs. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA789d004055 for ietf-openpgp-bks; Wed, 7 Nov 2001 00:09:39 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA789b804044 for ; Wed, 7 Nov 2001 00:09:37 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 161NxH-0000RA-00; Wed, 07 Nov 2001 09:21:03 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.32 #1 (Debian)) id 161NnD-00046r-00; Wed, 07 Nov 2001 09:10:39 +0100 To: "Michael Young" Cc: Subject: Re: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) References: <20011106.132424.68557949.kazu@iijlab.net> <009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Wed, 07 Nov 2001 09:10:39 +0100 In-Reply-To: <009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> ("Michael Young"'s message of "Tue, 6 Nov 2001 23:17:56 -0500") Message-ID: <87r8rbknls.fsf@alberti.gnupg.de> Lines: 13 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 6 Nov 2001 23:17:56 -0500, Michael Young said: > answer. The issue was that GnuPG used an old-style indeterminate-length > packet for the plaintext before the MDC (see my message of August 23 But only if the plaintext is a compressed packet - right? Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id fA74ImD18109 for ietf-openpgp-bks; Tue, 6 Nov 2001 20:18:48 -0800 (PST) Received: from smtprelay8.dc2.adelphia.net (smtprelay8.dc2.adelphia.net [64.8.50.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA74Ie818104 for ; Tue, 6 Nov 2001 20:18:46 -0800 (PST) Received: from mwyoung ([24.48.51.230]) by smtprelay8.dc2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GMEXB000.K08 for ; Tue, 6 Nov 2001 23:18:36 -0500 Message-ID: <009501c16743$2e6dc4a0$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <20011106.132424.68557949.kazu@iijlab.net> Subject: Parser abilities, and MDCs (Re: pointers to openpgp-interop knowledge base?) Date: Tue, 6 Nov 2001 23:17:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- > using the pgp dump web interface, it identified the message as using mdc > packets, [also as expected], but listed the algorithm as 1 {a 'default ' > listing for 'idea' once an rsa key is identified, even though 'idea' was > not used?} The algorithm identifier lives in material encrypted under the public key. Without the private key, all the parser could do is guess. (Does this parser have the ability to decrypt the contents even if the unprotected private key were present?) The MDC packet itself is encrypted under the session key. Again, the parser wouldn't be able to verify it. When you say it "identified the message as using mdc packets", I presume you mean that it noted that a "symmetrically encrypted integrity protected data packet" (tag 18) was present at the beginning, not that there was a valid MDC packet, right? On that note, I've asked a couple of times about the way GnuPG generates these packets, but I have never seen an authoritative answer. The issue was that GnuPG used an old-style indeterminate-length packet for the plaintext before the MDC (see my message of August 23 and any followup discussion for details). Should this be legal? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBO+i1v2NDnIII+QUHAQEDuwf/RDBc0LbP8jwwg6T6y0GQGqTOBUbvWRpC ClbmXN2XKfYt1g47cxBVc3Tg2NWD0YSFcdhguvtBb9fwQd+7YIwakLmJ/z52NhbJ jTA/eAA2Y1blYYAn43whIatogEP1R3ssvqnvpo/awT4UEryxfV5oVh4sZZ/m9yCb EzMolf6CKy2ocin7a6t1Ix71pevpTiYsufsF45ju6QvRSvZOG2pzTYasGZpfEIgQ 75yRZqOhSGI4MfLxE/MzsGHwBZlDotDoLyb3tfXCoGKhRFTCOX2ZN1/YeSthvkA1 l8wdQxv1/gWOEQ0tr4xtbopliFH8QvRSVq/Eznjtr4bg2jIWJNXaZg== =yQeY -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA71hSY15451 for ietf-openpgp-bks; Tue, 6 Nov 2001 17:43:28 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA71hQ815447 for ; Tue, 6 Nov 2001 17:43:27 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA25692; Wed, 7 Nov 2001 10:43:19 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA10976; Wed, 7 Nov 2001 10:43:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA01668; Wed, 7 Nov 2001 10:43:18 +0900 (JST) Date: Wed, 07 Nov 2001 10:43:58 +0900 (JST) Message-Id: <20011107.104358.125124924.kazu@iijlab.net> To: vedaal@hotmail.com Cc: ietf-openpgp@imc.org Subject: Re: pointers to openpgp-interop knowledge base? From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <20011106.132424.68557949.kazu@iijlab.net> X-Mailer: Mew version 3.0.50 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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: From: "vedaal" Subject: Re: pointers to openpgp-interop knowledge base? > using the pgp dump web interface, it identified the message as using mdc > packets, [also as expected], but listed the algorithm as 1 {a 'default ' > listing for 'idea' once an rsa key is identified, even though 'idea' was > not used?} Please send such a report directly to me, not to the entire list. Please send me a sample packet which causes your problem. I will fix it if it's a bug. --Kazu Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6KKNk07624 for ietf-openpgp-bks; Tue, 6 Nov 2001 12:20:23 -0800 (PST) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6KKL807620 for ; Tue, 6 Nov 2001 12:20:21 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA03769; Tue, 6 Nov 2001 12:19:45 -0800 Date: Tue, 6 Nov 2001 12:19:45 -0800 (PST) From: Len Sassaman X-Sender: To: John W Noerenberg II cc: Subject: Re: pointers to openpgp-interop knowledge base? In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 5 Nov 2001, John W Noerenberg II wrote: > I've heard tell of similar programs, but I don't have particular > knowledge of any. -- GnuPG has such a parser built into it. Also, there's a perl script written by Mark E. Shoulson called pgpacket3.1 that tries to do the same thing. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6Jc0f06280 for ietf-openpgp-bks; Tue, 6 Nov 2001 11:38:00 -0800 (PST) Received: from hotmail.com (oe18.law3.hotmail.com [209.185.240.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6Jbx806274 for ; Tue, 6 Nov 2001 11:37:59 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 6 Nov 2001 11:37:52 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <20011106.132424.68557949.kazu@iijlab.net> Subject: Re: pointers to openpgp-interop knowledge base? Date: Tue, 6 Nov 2001 14:33:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 06 Nov 2001 19:37:52.0647 (UTC) FILETIME=[8670A170:01C166FA] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "Kazu Yamamoto (????)" To: Sent: Monday, November 05, 2001 11:24 PM Subject: Re: pointers to openpgp-interop knowledge base? > Another PGP parser can be found: > http://pgp.iijlab.net/pgpdump.html > > Web interface is also available. > > --Kazu have tried the web interface, with a peculiar result: encrypted a message to an rsa key using gpg with the preference set to twofish, decrypting with gpg showed algorithm 10, as expected. using the pgp dump web interface, it identified the message as using mdc packets, [also as expected], but listed the algorithm as 1 {a 'default ' listing for 'idea' once an rsa key is identified, even though 'idea' was not used?} is this just the web interface, or does the parser do this too? vedaal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA64NlO24683 for ietf-openpgp-bks; Mon, 5 Nov 2001 20:23:47 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA64Nj824679 for ; Mon, 5 Nov 2001 20:23:45 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id NAA29628 for ; Tue, 6 Nov 2001 13:23:45 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA10873 for ; Tue, 6 Nov 2001 13:23:44 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA09176 for ; Tue, 6 Nov 2001 13:23:44 +0900 (JST) Date: Tue, 06 Nov 2001 13:24:24 +0900 (JST) Message-Id: <20011106.132424.68557949.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: pointers to openpgp-interop knowledge base? From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: X-Mailer: Mew version 3.0.50 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 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: From: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? > I have a program to contribute which will read openpgp files and > report on their structure. John Callas wrote the original version, > and I've been updating it for 2440. It's not a complete > implementation of 2440. But it locates packet boundaries, identifies > packet types, and describes the plaintext portions of packets. Another PGP parser can be found: http://pgp.iijlab.net/pgpdump.html Web interface is also available. --Kazu Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5L0To15814 for ietf-openpgp-bks; Mon, 5 Nov 2001 13:00:29 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5L0M815809 for ; Mon, 5 Nov 2001 13:00:27 -0800 (PST) Received: from [129.46.77.249] (dhcp480.qualcomm.com [129.46.77.249]) by mage.qualcomm.com (8.12.1/8.12.1/1.0) with ESMTP id fA5L0A9I006913; Mon, 5 Nov 2001 13:00:12 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: References: X-Mailer: eudora51-ffc10713011434 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Mon, 5 Nov 2001 12:45:33 -0800 To: Len Sassaman From: John W Noerenberg II Subject: Re: pointers to openpgp-interop knowledge base? Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:29 PM -0800 11/4/01, Len Sassaman wrote: > >I could keep throwing things off the top of my head -- but shouldn't we >have some formal system for listing all of this? Yes. Both Brian Smith and John Kane have volunteered to maintain the information. I've asked them to collaborate on maintaining the pages. My preference is we set something up under openpgp.org site. openpgp.org is a computer at Phil Zimmermann's house. There's other stuff I would like to see there, but interoperability info would be a Real Good Thing to get 2440 to DRAFT. I have a program to contribute which will read openpgp files and report on their structure. John Callas wrote the original version, and I've been updating it for 2440. It's not a complete implementation of 2440. But it locates packet boundaries, identifies packet types, and describes the plaintext portions of packets. If people send me files, I'll run them through my parser, and tell you what happens. The program runs on my Mac, but should be reasonably portable to other systems. I'll publish it on openpgp.org, as soon as we make a suitable place. I've heard tell of similar programs, but I don't have particular knowledge of any. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- While the belief we have found the Answer can separate us and make us forget our humanity, it is the seeking that continues to bring us together, the makes and keeps us human. -- Daniel J. Boorstin, "The Seekers", 1998 ---------------------------------------------------------------------- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA59VC800197 for ietf-openpgp-bks; Mon, 5 Nov 2001 01:31:12 -0800 (PST) Received: from HACKSERV.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id fA59VA800184 for ; Mon, 5 Nov 2001 01:31:11 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by 127.0.0.1 (EMWAC SMTPRS 0.83) with SMTP id ; Mon, 05 Nov 2001 10:21:57 +0200 Message-ID: <3BE65A35.79D43134@saiknes.lv> Date: Mon, 05 Nov 2001 11:21:57 +0200 From: disastry@saiknes.lv Organization: disastry.NO.SPaM.NET X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: pointers to openpgp-interop knowledge base? 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Len Sassamanwrote: > > GnuPG of any version produces messages signed with v3 keys encrypted in v3 > format that PGP cannot decrypt. except PGP 2.6.3ia-multi05, I modified it so that it can decrypt/verify these GnuPG produced non OpenPGP compliant messages. > In the implementation nits, it is noted that PGP 5.x cannot verify v4 sigs > on non-v4 material. Actually, 6.x cannot either, but 7.x and greater can. even PGP 7.x have problems with v4 sigs. it can verify v4 clearsignatures and detached signatures but not one pass signatures. PGP 6.5.8ckt06 can verify all v4 signatures. > Then there's the ElGamal signing-keys that GnuPG generates. I don't know > what else supports them. PGP 6.5.8ckt06 does. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^--GPG for Win32 (supports loadable modules and IDEA) ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBO+Y97zBaTVEuJQxkEQNoFACfeSh00qrCkaDgDcNQ/e3lCiSrtIIAoIHw zLRMMcdbox/lYo1m+oEzQ87c =Sq+J -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA4KTfO25131 for ietf-openpgp-bks; Sun, 4 Nov 2001 12:29:41 -0800 (PST) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA4KTd825127 for ; Sun, 4 Nov 2001 12:29:39 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA23628 for ; Sun, 4 Nov 2001 12:29:25 -0800 Date: Sun, 4 Nov 2001 12:29:25 -0800 (PST) From: Len Sassaman X-Sender: To: Subject: Re: pointers to openpgp-interop knowledge base? In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 4 Nov 2001, vedaal wrote: > messages from any pgp version can be read and verified by gpg {with the > idea plugin}, > except if a shared key/split key system is used > [gpg can encrypt to a split key, but not sign or decrypt with a shared key > system] > > messages from gpg using the throw-key id switch, cannot be read by 'any' > version > of pgp {except for Disastry's 2.6.3i multi 5} > > messages from gpg using mdc, cannot be read by any pgp version prior to > 7.xx > {6.5.8ckt is an exception, having a patch to ignore the mdc packets} > > messages from 7.xx using twofish or aes, cannot be decrypted by pgp > versions prior > to 7.xx, but signatures can be verified > {again, 6.5.8ckt is an exception} > > messages using an RSA v4 key, can be decrypted, and can be verified, by pgp > versions > prior to 7.xx, but, for some reason, not, if the message is 'both' signed > and encrypted > > messages signed with ripemd-160 or sha-1, can be verified by all pgp > versions greater > than 2.6.x, even if they do not use them to sign with for a particular key > type > > > hope this is useful, > > please correct if there are any mistakes or oversights, Well, you've left out GnuPG versions. GnuPG hasn't always been able to handle everything you mention. GnuPG of any version produces messages signed with v3 keys encrypted in v3 format that PGP cannot decrypt. In the implementation nits, it is noted that PGP 5.x cannot verify v4 sigs on non-v4 material. Actually, 6.x cannot either, but 7.x and greater can. Then there's the ElGamal signing-keys that GnuPG generates. I don't know what else supports them. Also, signing subkeys are probably a problem with a lot of other implementations as well. We have no idea what Hushmail's interop status is, since there appears to be no way to either get access to Hushmail users' public keys in order to verify their signatures, or import non-Hushmail users' keys into the Hushmail system to encrypt to them. ...etc. I could keep throwing things off the top of my head -- but shouldn't we have some formal system for listing all of this? -- Len Sassaman Security Architect | "Now it's all change -- Technology Consultant | It's got to change more." | http://sion.quickie.net | --Joe Jackson Received: by above.proper.com (8.11.6/8.11.3) id fA4H8Eg11871 for ietf-openpgp-bks; Sun, 4 Nov 2001 09:08:14 -0800 (PST) Received: from hotmail.com (oe65.law3.hotmail.com [209.185.240.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA4H8C811862 for ; Sun, 4 Nov 2001 09:08:12 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Nov 2001 09:08:09 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <200111041422.DAA75086@ruru.cs.auckland.ac.nz> Subject: Re: pointers to openpgp-interop knowledge base? Date: Sun, 4 Nov 2001 12:07:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 04 Nov 2001 17:08:09.0177 (UTC) FILETIME=[470C6490:01C16553] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 - ----- Original Message ----- From: "Peter Gutmann" To: ; Sent: Sunday, November 04, 2001 9:22 AM Subject: Re: pointers to openpgp-interop knowledge base? > I've found that just using the various options of PGP 5.0 (which is > not-quite- OpenPGP), 6.5.x, and GPG will give you all the quirks and > peculiarities you need. Once you've made sure you can read what they > produce, you should also check that they can read what you produce. > > Peter. short summary of intercompatibility, and incompatibilities: messages from any pgp version can be read and verified by gpg {with the idea plugin}, except if a shared key/split key system is used [gpg can encrypt to a split key, but not sign or decrypt with a shared key system] messages from gpg using the throw-key id switch, cannot be read by 'any' version of pgp {except for Disastry's 2.6.3i multi 5} messages from gpg using mdc, cannot be read by any pgp version prior to 7.xx {6.5.8ckt is an exception, having a patch to ignore the mdc packets} messages from 7.xx using twofish or aes, cannot be decrypted by pgp versions prior to 7.xx, but signatures can be verified {again, 6.5.8ckt is an exception} messages using an RSA v4 key, can be decrypted, and can be verified, by pgp versions prior to 7.xx, but, for some reason, not, if the message is 'both' signed and encrypted messages signed with ripemd-160 or sha-1, can be verified by all pgp versions greater than 2.6.x, even if they do not use them to sign with for a particular key type hope this is useful, please correct if there are any mistakes or oversights, thanks, vedaal -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: KeyID: 0x6A05A0B785306D25 Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA iQEVAwUBO+Vzv2oFoLeFMG0lAQM+LQgAlt+ExlozIUSER30Ru/umGr/U3vPrtNzd 8naUSPJhjQEpB1usLpALy6Oj/uw8/2sGuXmjZ371+rR7Lr8IlI4/YMZw8ufKIjGN zfPlOEHyd64SO3bDsWrzi9sJ+6dzSif/JA/t6Uxl2mDCWAxmhigdXfbEM/USYxAR hPzjSjqEXLOhRuDxEe82Zpb9hhzShgayfJmTTR6dSqPRMbT92FVDs9pqYnlb1BwR 5dKWBG0dP6HIDWEnAaLyoOQodxoJA/b9wat81uEOvelvbHIwkKeKsI21uylHBy9u QU01nlWe6tinjdzm+tiriqOBMjAbqSHahgYTnV9cCdPGygyMYXC8rg== =tENm -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA4EMpk19880 for ietf-openpgp-bks; Sun, 4 Nov 2001 06:22:51 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA4EMn819876 for ; Sun, 4 Nov 2001 06:22:49 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id DAA13042; Mon, 5 Nov 2001 03:22:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id DAA75086; Mon, 5 Nov 2001 03:22:41 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 5 Nov 2001 03:22:41 +1300 (NZDT) Message-ID: <200111041422.DAA75086@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, jkane89@softhome.net Subject: Re: pointers to openpgp-interop knowledge base? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John J Kane wrote: >Are there any sources online for the following? > > * contact info for people involved in interop testing > * examples of non-conformant output (for testing) > * examples of conformant output which have been documented to break certain > implementations I've found that just using the various options of PGP 5.0 (which is not-quite- OpenPGP), 6.5.x, and GPG will give you all the quirks and peculiarities you need. Once you've made sure you can read what they produce, you should also check that they can read what you produce. Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA40iox03143 for ietf-openpgp-bks; Sat, 3 Nov 2001 16:44:50 -0800 (PST) Received: from keyhole.dublin.hush.com (root@dublin.hush.com [193.95.161.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA40in803138 for ; Sat, 3 Nov 2001 16:44:49 -0800 (PST) Received: from Hush-intranet.dublin.hush.com (exchange.dublin.hush.com [192.168.0.29]) by keyhole.dublin.hush.com (8.11.1/8.9.3) with ESMTP id fA40lqj17748; Sun, 4 Nov 2001 00:47:52 GMT Received: by Hush-intranet.dublin.hush.com with Internet Mail Service (5.5.2650.21) id <41AH5DLF>; Sun, 4 Nov 2001 00:47:54 -0000 Message-ID: From: Brian Smith To: "'John J Kane'" , ietf-openpgp@imc.org Subject: RE: pointers to openpgp-interop knowledge base? Date: Sun, 4 Nov 2001 00:47:51 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: http://www.openpgp.org/technical/interoperability/ However, the information there is pretty limited. If anyone has contributions of the types described below, send them to me and I'll see that they're added to the site. Brian Smith Hush Communications > -----Original Message----- > From: John J Kane [mailto:jkane89@softhome.net] > Sent: 03 November 2001 18:06 > To: ietf-openpgp@imc.org > Subject: pointers to openpgp-interop knowledge base? > > ________________________________________________________ > > This message has NOT been ENCRYPTED and has NOT been SIGNED > ________________________________________________________ > > > Are there any sources online for the following? > > * contact info for people involved in interop testing > * examples of non-conformant output (for testing) > * examples of conformant output which have been > documented to break certain implementations > > Should a page be set up to host this information? > > -- > JJK > > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA3If7e24805 for ietf-openpgp-bks; Sat, 3 Nov 2001 10:41:07 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA3If6824801 for ; Sat, 3 Nov 2001 10:41:06 -0800 (PST) Received: from softhome.net ([207.180.179.68]) (AUTH: PLAIN jkane89@softhome.net) by softhome.net with esmtp; Sat, 03 Nov 2001 11:34:08 -0700 Message-ID: <3BE43214.9557E0A3@softhome.net> Date: Sat, 03 Nov 2001 13:06:12 -0500 From: John J Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: pointers to openpgp-interop knowledge base? 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: Are there any sources online for the following? * contact info for people involved in interop testing * examples of non-conformant output (for testing) * examples of conformant output which have been documented to break certain implementations Should a page be set up to host this information? -- JJK