From owner-ietf-openpgp@mail.imc.org Sat Mar 18 14:47:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05713 for ; Sat, 18 Mar 2000 14:47:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19843 for ietf-openpgp-bks; Sat, 18 Mar 2000 11:16:42 -0800 (PST) Received: from tomts3-srv.bellnexxia.net (tomts3.bellnexxia.net [209.226.175.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19839 for ; Sat, 18 Mar 2000 11:16:39 -0800 (PST) Received: from [216.209.53.81] by tomts3-srv.bellnexxia.net (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20000318191741.IBPJ3031.tomts3-srv.bellnexxia.net@[216.209.53.81]>; Sat, 18 Mar 2000 14:17:41 -0500 Mime-Version: 1.0 X-Sender: rguerra@cryptorights.org (Unverified) Message-Id: In-Reply-To: <4.3.0.20000216114317.01b27df0@mail.well.com> References: <4.3.0.20000216114317.01b27df0@mail.well.com> Date: Sat, 18 Mar 2000 14:17:05 -0500 To: rguerra@cryptorights.org From: Robert Guerra Subject: CFP2000 Conference - PGP Keysigning Session Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi: I'll be attending the CFP2000 conference being held in Toronto the first week in April. If you are attending also, I'd like to extend an invitation to participate in the conference pgp keysigning I am organizing The conference is shaping up to be one of the primier meetings of the year and presents a unique opportunity not only personally meet the numerous key people in the field but also to extend and interweave the existing pgp global web of trust. I've set-up a web page (http://pgp.greatvideo.com) which i'll be updating latter this week with details on and about the numerous formal & informal web of trust/keysigning which i'll be organizing. If you attending the conference, I look forward to meeting you. If you'd like to exchange pgp signatures, but can't make the keysigning please let me know so I might be able to meet you ay another time. Yours Sincerely, -- --- Robert Guerra WWW Page From owner-ietf-openpgp@mail.imc.org Wed Mar 22 08:47:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20364 for ; Wed, 22 Mar 2000 08:47:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA17656 for ietf-openpgp-bks; Wed, 22 Mar 2000 05:18:12 -0800 (PST) Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17652 for ; Wed, 22 Mar 2000 05:18:11 -0800 (PST) Received: from [216.209.49.114] (HSE-Toronto-ppp93181.sympatico.ca [216.209.49.114]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA14129; Wed, 22 Mar 2000 08:23:03 -0500 (EST) Mime-Version: 1.0 X-Sender: b1vihi16@pop2.sympatico.ca Message-Id: Date: Wed, 22 Mar 2000 08:17:43 -0500 To: Recipient List Suppressed:; From: Robert Guerra Subject: Fwd: [PGP-Discussion] PGP-Users List is Operational Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --- begin forwarded text Date: Wed, 22 Mar 2000 06:48:50 -0600 From: Chuck44@goin.missouri.org Subject: [PGP-Discussion] PGP-Users List is Operational From: Chuck44@goin.missouri.org Hello everyone, Dave Del Torto has announced that the new, permanent PGP Users list is officially open. This is the list that he and Fred were working on setting up when Fred disappeared. To find out more, including how to subscribe go to: http://cryptorights.org/pgp-users/ Chuck in Missouri -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Digital Signatures ensure message authenticity iQA/AwUBONjH7cKdCsHMpdeSEQLeqwCgnt09VFuvjM3/EGe59izMlCigVJAAoOsH pJ3DFs8Ennum9zu6j2Ffm18M =NI1o -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Mar 27 19:52:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28116 for ; Mon, 27 Mar 2000 19:52:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19207 for ietf-openpgp-bks; Mon, 27 Mar 2000 16:22:14 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19203 for ; Mon, 27 Mar 2000 16:22:13 -0800 (PST) Received: from [169.208.192.29] (vpnap-g1-012018.qualcomm.com [10.13.12.18]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA07219; Mon, 27 Mar 2000 16:24:26 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 4.3.1] 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: Tue, 28 Mar 2000 09:41:01 +0930 To: OpenPGP mailing list From: John W Noerenberg II Subject: DRAFT status and Compatibility testing Cc: "Jeffrey I. Schiller" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We've talked about moving 2440 to DRAFT for a while now. We need to do this. There are really two things we need: 1) two interoperable implementations, and 2) verification of the requirements of the protocol. Even though we're not meeting in Adelaide, I thought kicking off some interoperability testing during the week would be an IETF'ish thing to do. Towards 1, I propose the following: We'll exchange encrypted, signed objects exercising the various modes described in 2440. I'll keep score, and publish the results for the WG. To participate, send me a note with subject: OpenPGP Compatibility Test 1 with directions on where to find a public key you'd like me to use. I will send an object encrypted with the keys I have and signed with mine on Thursday, Mar 30, 1500+930, at the conclusion of the SAAG meeting. When you receive the message, decrypt the object, validate the signature, and send me back the results signed with your key. Your response needs to include: the plaintext, what algorithms were used and evidence you've validated my signature. My key is available on the MIT key server. For 2, we'll need to build a compliance matrix to verify that all the required elements of 2440 have been treated (or not). If we find features that have not been used, or are disputed, I will propose eliminating them unless resolution is desired, and found. I'll start on 2, but I'll be looking for help. Remember, the subject of the message is: OpenPGP Compatibility Test 1. I'm filtering messages by the subject to get your entry. If you don't use this subject, I might miss you. The message will go out at the end of the SAAG meeting on Thursday. best, -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- But now I know our world is no more permanent than a wave rising on the ocean. -- Arthur Golden, "Memoirs of a Geisha", 1997 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Tue Mar 28 11:57:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23539 for ; Tue, 28 Mar 2000 11:57:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04649 for ietf-openpgp-bks; Tue, 28 Mar 2000 08:17:10 -0800 (PST) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04645 for ; Tue, 28 Mar 2000 08:17:08 -0800 (PST) Received: from whgiii.geiger.local (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA21187; Tue, 28 Mar 2000 11:19:07 -0500 Message-Id: <200003281619.LAA21187@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 28 Mar 2000 10:03:59 -0600 To: John W Noerenberg II In-Reply-To: Cc: OpenPGP mailing list , "Jeffrey I. Schiller" Subject: Re: DRAFT status and Compatibility testing X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.10a c10 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In , on 03/27/00 at 06:41 PM, John W Noerenberg II said: >Towards 1, I propose the following: We'll exchange encrypted, signed >objects exercising the various modes described in 2440. I'll keep >score, and publish the results for the WG. To participate, send me a >note with subject: IMHO what we need to do is put together a suite of test data that conforms to RFC 2440. Envelope -------- Ascii-armor PGP/MIME Algorithms ---------- Compresion Symetric encryption Public Key encryption Hash Signatures ---------- Signature Types Version 3 Version 4 -- Hashed Subpackets -- Non-Hashed Subpackets Keys ---- Private Keys Public Keys Version 3 Version 4 -- Subkeys (NOTE: This is not a complete list) Additionally data sets should be divided into MUST, SHOULD, and OPTIONAL catagories. Testing should be done to see if the products are able to generate & process the various packet types. Some of the non-RFC2440 packets should be included (X.509, PhotoID, ...ect) so vendors can test that their software can properly handle non-RFC2440 packets without crashing (this has been a problem with the pks software). IIRC someone had a partal data set available but I do not know if it is still around nor if it has been updated. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Tue Mar 28 14:34:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25400 for ; Tue, 28 Mar 2000 14:34:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA07164 for ietf-openpgp-bks; Tue, 28 Mar 2000 10:50:23 -0800 (PST) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07159 for ; Tue, 28 Mar 2000 10:50:22 -0800 (PST) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id KAA27958; Tue, 28 Mar 2000 10:52:15 -0800 (PST) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id KAA27954; Tue, 28 Mar 2000 10:52:08 -0800 (PST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200003281619.LAA21187@domains.invweb.net> References: <200003281619.LAA21187@domains.invweb.net> Date: Tue, 28 Mar 2000 10:51:09 -0800 To: "William H. Geiger III" , ietf-openpgp@imc.org From: Jon Callas Subject: Re: DRAFT status and Compatibility testing Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: DRAFT status and Compatibility testing", shown on 3/28/00), William H. Geiger III said: >IMHO what we need to do is put together a suite of test data that conforms >to RFC 2440. > [...] >Some of the non-RFC2440 packets should be included (X.509, PhotoID, >...ect) so vendors can test that their software can properly handle >non-RFC2440 packets without crashing (this has been a problem with the pks >software). > I think this is an excellent idea. 2440 is a data format standard, and consequently, the test suite mostly should consist of data. The only real comment I have on your list is that PGP/MIME isn't part of 2440, it's a separate RFC. (And in my opinion, this is a feature, not a bug. It's called layering.) There's a related issue that I want to bring up, though. Many messages, when generated require random numbers to be used. In a non-security environment, we'd have no objections to saying, "Here are the inputs, here is the final data, make sure you generate this." Do we have an objection to saying, "With a session key of K, encrypt message M, and your result should look like R"? I don't -- I consider this to be the equivalent of a crypto test vector. On the other hand, it still gives me a small shudder, and I think this is one of those things on which gentlepersons can disagree. An alternative is to come up with a test suite where an implementation generates a message with known keys, and then writes out the session keys and signature randoms, so that they can be verified. But on this one, I don't see it's any better. The problem, as I see it, is that if an implementation has a test mode in which a random can be specified, then that's potentially a way to create a hacked version with bad or known keys. But on the other hand, if an implementation has a test mode in which the randoms can be leaked, then that's a way to make a hacked version with a covert channel. If I have to pick between one of those risks, I pick the former. On the third hand, if we just say "non serviam" to that, then we run the risk that a hacked version could pass all compliance tests and no one would know otherwise. I don't like measuring compliance when we aren't specifying the inputs, either. I think my opinion (yes, I'm tentative here) is that 2440 is a data format standard. We already have been wise enough to not get it into the whole mess of crypto engineering in it. Our goal in advancing this is to make sure that given a set of inputs, an implementation produces the proper results. Those inputs may be finished messages that must be decoded, or they may be plaintext, ciphers, randoms, etc. that should generate a fixed message. There's an engineering problem in making an implementation testable and secure. But that's a problem that the implementors have to solve. Opinions? Jon From owner-ietf-openpgp@mail.imc.org Tue Mar 28 16:45:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27102 for ; Tue, 28 Mar 2000 16:45:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08723 for ietf-openpgp-bks; Tue, 28 Mar 2000 12:05:05 -0800 (PST) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08717 for ; Tue, 28 Mar 2000 12:04:56 -0800 (PST) Received: from whgiii.geiger.local (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id PAA12308; Tue, 28 Mar 2000 15:06:46 -0500 Message-Id: <200003282006.PAA12308@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 28 Mar 2000 14:06:36 -0600 To: Jon Callas In-Reply-To: Cc: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.10a c10 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In , on 03/28/00 at 12:51 PM, Jon Callas said: >I think this is an excellent idea. 2440 is a data format standard, and >consequently, the test suite mostly should consist of data. The only real >comment I have on your list is that PGP/MIME isn't part of 2440, it's a >separate RFC. (And in my opinion, this is a feature, not a bug. It's >called layering.) Yes but there is no reason why not to include PGP/MIME test data. One can document that this part of the data is for a seperate yet related RFC. Most 2440 applications will also want to be PGP/MIME compliant. >There's a related issue that I want to bring up, though. Well I see the testing of the application as 2 part. The 1st part would be the "inbound" processing of RFC 2440 packets. I don't see any risks involved with using a fixed data set for this part of the testing. The second part would be the "outbound" generation of RFC 2440 packets. We should be able to have a set of "skeleton" packets that the tester could use for compairison while ignoring the raw data (ie MPI's) that may be different. As an example the application being tested needs to generate a v3 RSA public key. The tests could use the "skeleton" test packet to compair that all of the parts are generated and formated properly while ignoring that data contained in MPI(1) and MPI(2) is different. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Tue Mar 28 19:30:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00352 for ; Tue, 28 Mar 2000 19:30:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA12072 for ietf-openpgp-bks; Tue, 28 Mar 2000 16:05:08 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12068 for ; Tue, 28 Mar 2000 16:05:07 -0800 (PST) Received: from [169.208.192.29] (vpnap-g1-012013.qualcomm.com [10.13.12.13]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA25700; Tue, 28 Mar 2000 16:07:22 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200003281619.LAA21187@domains.invweb.net> References: <200003281619.LAA21187@domains.invweb.net> X-Mailer: Eudora [Macintosh version 4.3.1] 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: Wed, 29 Mar 2000 09:34:46 +0930 To: "William H. Geiger III" From: John W Noerenberg II Subject: Re: DRAFT status and Compatibility testing Cc: OpenPGP mailing list , "Jeffrey I. Schiller" 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 10:03 AM -0600 3/28/00, William H. Geiger III wrote: > >IMHO what we need to do is put together a suite of test data that conforms >to RFC 2440. Sounds like a good idea. We'll need some data and specifications on what the data tests. The message I proposed isn't an exhaustive test. But at least it demonstrates some level of interoperability. That's a first step. Are you volunteering to write the specs and build the test data? > >Additionally data sets should be divided into MUST, SHOULD, and OPTIONAL >catagories. First step here is to create the matrix I have in mind a la 1123. > >Testing should be done to see if the products are able to generate & >process the various packet types. > >Some of the non-RFC2440 packets should be included (X.509, PhotoID, >...ect) so vendors can test that their software can properly handle >non-RFC2440 packets without crashing (this has been a problem with the pks >software). We can bear that in mind. It certainly has impact on what we do. If there are non-2440 packets we need to consider, I'd entertain the idea of an new draft to incorporate them into 2440's successor. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- But now I know our world is no more permanent than a wave rising on the ocean. -- Arthur Golden, "Memoirs of a Geisha", 1997 ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Tue Mar 28 19:46:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00588 for ; Tue, 28 Mar 2000 19:46:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA12477 for ietf-openpgp-bks; Tue, 28 Mar 2000 16:25:53 -0800 (PST) Received: from enigma.cyphers.net (IDENT:root@enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12473 for ; Tue, 28 Mar 2000 16:25:52 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [205.178.102.83]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id QAA19861; Tue, 28 Mar 2000 16:29:45 -0800 Message-ID: <38E14D68.CA703ABC@cyphers.net> Date: Tue, 28 Mar 2000 16:25:12 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: John W Noerenberg II , OpenPGP mailing list Subject: Re: DRAFT status and Compatibility testing References: <200003281619.LAA21187@domains.invweb.net> 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: SHA1 Some of the discussion I've seen thus far has gone a bit too far it seems. Proposals such as using pre-determined session keys or other low-level crypto items may require ripping apart the software packages being subjected to the testing and writing new code in order to perform the test. This is not going to prove anything other than the fact that the new code (which isn't necessarily part of the product) enabled a piece of software to complete an obscure low-level test, and will lengthen the testing cycle from something that could be done in a couple of weeks to something that will likely take many months to agree upon, design, write, perform testing, repeat. Any test designed to prove interoperability should adhere stricly to the principle that interoperability between OpenPGP products is a high-level operation basically limited to the following: * Public/Private Key import/export * Encrypted and/or signed message interop in its various forms Things like PGP/MIME, and low-level testing of crypto algorithms are irrelevant to this task except insofar as they have an effect on the above two items (which for instance PGP/MIME does not -- that document will require its own separate interop testing). We're not doing a FIPS crypto test on every product here, we're just testing interop of the items generated by our common products which apply directly to RFC 2440. Making a test suite of messages and keys which use an array of algorithms and variations should be a simple task any user can perform sitting at any of our products without rewriting code, turning on debug features, recompiling, etc... This set of data would be termed the OpenPGP Compatibility Suite, and each vendor could perform the testing on their own product, submit that to the list, and any other vendor could use that same data to verify the results. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 144 Alpha) iQA/AwUBOOFNMKy7FkvPc+xMEQJtdQCfTzZrTm9faAlZRfrgpSGfQjEbrqcAniGR 9NHfkzlUee6nCdrK+Nr/DrIO =5URX -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Mar 28 21:55:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02404 for ; Tue, 28 Mar 2000 21:55:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA17631 for ietf-openpgp-bks; Tue, 28 Mar 2000 18:28:43 -0800 (PST) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17625 for ; Tue, 28 Mar 2000 18:28:41 -0800 (PST) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id SAA25713 for ietf-openpgp@imc.org; Tue, 28 Mar 2000 18:31:30 -0800 Date: Tue, 28 Mar 2000 18:31:30 -0800 Message-Id: <200003290231.SAA25713@finney.org> To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The problem with a "test suite" is that it would allow a software creator to test that his software READS openpgp compliant data, but not that it CREATES compliant data. The latter testing is more difficult because as Jon Callas pointed out there is a lot of randomness in what is created and so you can't just compare against a "known good" output. I am inclined to think that traditional interoperability testing is a better way to approach this problem. At least with openpgp we don't all have to get together, it can all be done online. We would define a specific set of message/key types to create, and everyone who wanted to participate would create messages/keys of those types (or whatever subset they support), then everyone else would try to read them. See the S/MIME page at http://www.rsasecurity.com/standards/smime/interop_center.html for an example. They did it differently by comparing with a reference implementation, but since we have only a few implementations I think it is feasible to have N by N comparisons. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Mar 28 22:23:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02614 for ; Tue, 28 Mar 2000 22:23:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21191 for ietf-openpgp-bks; Tue, 28 Mar 2000 19:02:23 -0800 (PST) Received: from enterprise.powerup.com.au (IDENT:qmailr@enterprise.powerup.com.au [203.32.8.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21182 for ; Tue, 28 Mar 2000 19:02:20 -0800 (PST) Message-Id: <200003290302.TAA21182@ns.secondary.com> Received: (qmail 29646 invoked from network); 29 Mar 2000 03:04:23 -0000 Received: from unknown (HELO lindsay) (203.147.172.62) by enterprise.powerup.com.au with SMTP; 29 Mar 2000 03:04:23 -0000 Date: 29 Mar 2000 3:2:33 GMT From: Lindsay Mathieson Mime-Version: 1.0 Subject: Re: DRAFT status and Compatibility testing To: ietf-openpgp@imc.org X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.8 Preview 4 Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Is there a public freeware implementation of rfc 2440 ? -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.8 Preview 4, on March 29, 2000, in Win95 4.10 http://www.blackpaw.com/ From owner-ietf-openpgp@mail.imc.org Wed Mar 29 00:45:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05130 for ; Wed, 29 Mar 2000 00:45:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA01321 for ietf-openpgp-bks; Tue, 28 Mar 2000 21:21:46 -0800 (PST) Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA01310 for ; Tue, 28 Mar 2000 21:21:34 -0800 (PST) Received: from road-warrior (mg134-043.ricochet.net [204.179.134.43]) by rgate2.ricochet.net (8.9.3/8.9.3) with ESMTP id XAA21132 for ; Tue, 28 Mar 2000 23:23:42 -0600 (CST) Message-Id: <4.2.0.58.20000328212041.00b9ece0@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 28 Mar 2000 21:23:26 -0800 To: OpenPGP mailing list From: Rodney Thayer Subject: Re: DRAFT status and Compatibility testing In-Reply-To: <38E14D68.CA703ABC@cyphers.net> References: <200003281619.LAA21187@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that products should be built with "test points" in them, to allow such things as interoperability testing. This is how we've had to do things in the IPsec and TLS worlds, and in other places. I think we should be able to "dump the keys", and I realize that means one has to (gasp) have code that reveals the keys. On the other hand, if we run in "trust me, it's ok" mode, we're degenerating into security by obscurity. If I were auditing an implementation, I'd want to see the keys to validate it myself. Remember, there's nothing stopping someone from revealing the keys anyway -- you can't inhibit someone from saving copies of their key material, or even publishing it. So this is a previously existing non-problem. At 04:25 PM 3/28/00 -0800, Will Price wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Some of the discussion I've seen thus far has gone a bit too far it >seems. > >Proposals such as using pre-determined session keys or other >low-level crypto items may require ripping apart the software >packages being subjected to the testing and writing new code in order >to perform the test. This is not going to prove anything other than >the fact that the new code (which isn't necessarily part of the >product) enabled a piece of software to complete an obscure low-level >test, and will lengthen the testing cycle from something that could >be done in a couple of weeks to something that will likely take many >months to agree upon, design, write, perform testing, repeat. > >Any test designed to prove interoperability should adhere stricly to >the principle that interoperability between OpenPGP products is a >high-level operation basically limited to the following: > >* Public/Private Key import/export >* Encrypted and/or signed message interop in its various forms > >Things like PGP/MIME, and low-level testing of crypto algorithms are >irrelevant to this task except insofar as they have an effect on the >above two items (which for instance PGP/MIME does not -- that >document will require its own separate interop testing). We're not >doing a FIPS crypto test on every product here, we're just testing >interop of the items generated by our common products which apply >directly to RFC 2440. > >Making a test suite of messages and keys which use an array of >algorithms and variations should be a simple task any user can >perform sitting at any of our products without rewriting code, >turning on debug features, recompiling, etc... > >This set of data would be termed the OpenPGP Compatibility Suite, and >each vendor could perform the testing on their own product, submit >that to the list, and any other vendor could use that same data to >verify the results. > >- -- Will > >Will Price, Director of Engineering >PGP Security, Inc. >a division of Network Associates, Inc. > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP 7.0 (Build 144 Alpha) > >iQA/AwUBOOFNMKy7FkvPc+xMEQJtdQCfTzZrTm9faAlZRfrgpSGfQjEbrqcAniGR >9NHfkzlUee6nCdrK+Nr/DrIO >=5URX >-----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Mar 29 01:21:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07362 for ; Wed, 29 Mar 2000 01:21:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02396 for ietf-openpgp-bks; Tue, 28 Mar 2000 21:58:17 -0800 (PST) Received: from enigma.cyphers.net (IDENT:root@enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02391 for ; Tue, 28 Mar 2000 21:58:08 -0800 (PST) Received: from cyphers.net (blowfish.cyphers.net [205.178.102.84]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id WAA20791 for ; Tue, 28 Mar 2000 22:02:07 -0800 Message-ID: <38E19BF7.7FCA67D7@cyphers.net> Date: Tue, 28 Mar 2000 22:00:37 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: OpenPGP mailing list Subject: Re: DRAFT status and Compatibility testing References: <200003281619.LAA21187@domains.invweb.net> <4.2.0.58.20000328212041.00b9ece0@216.240.42.209> 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: SHA1 Rodney Thayer wrote: > > I think that products should be built with "test points" in them, > to allow such things as interoperability testing. This is how > we've had to do things in the IPsec and TLS worlds, and in other > places. I think we should be able to "dump the keys", and I > realize that means one > has to (gasp) have code that reveals the keys. IPsec and TLS are hundreds of times more complicated to interop test than OpenPGP should be. IPsec and TLS are extremely complex, OpenPGP is fairly straight forward. Dumping keys is an obscure debug scenario used to figure out why two implementations do not interop. Frankly, I expect the OpenPGP testing will have very few cases of interop failure, and that such cases will be reasonably explainable with things like "we didn't implement that optional algorithm." > On the other hand, if we run in "trust me, it's ok" mode, we're > degenerating into security by obscurity. If I were auditing an > implementation, I'd want to see the keys to validate it myself. A main part of the point I'm making is that we are NOT auditing implementations. This is not a security review for each of our products. This is an interop test. If some other product uses a session key of 0, it's not the job of the interop tests to discover that. If I can read the other guy's messages/keys and he can read mine, we're set to go. > Remember, there's nothing stopping someone from revealing the keys > anyway -- you can't inhibit someone from saving copies of their > key material, or even publishing it. So this is a previously > existing non-problem. As I said, the tests must be able to be run by any user sitting at each of our products without debug tools or special code. Going beyond that gets into a security review which is not what we're doing here. Hal Finney wrote: > I am inclined to think that traditional interoperability testing is > a better way to approach this problem. At least with openpgp we > don't all have to get together, it can all be done online. > > We would define a specific set of message/key types to create, and > everyone who wanted to participate would create messages/keys of > those types (or whatever subset they support), then everyone else > would try to read them. Thanks for the correction Hal. That sounds like an efficient approach. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 145 Alpha) iQA/AwUBOOGac6y7FkvPc+xMEQI9wgCg3OzL+yq5b4sK+OeZiQohxpwvtIAAnjob TdXKhEBO0bYmI73uRKwfjWvV =S5P6 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Mar 29 05:48:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18758 for ; Wed, 29 Mar 2000 05:48:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA18653 for ietf-openpgp-bks; Wed, 29 Mar 2000 02:21:47 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18645 for ; Wed, 29 Mar 2000 02:21:45 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aFl9-0005xB-00; Wed, 29 Mar 2000 12:31:35 +0200 Date: Wed, 29 Mar 2000 12:31:35 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329123135.K20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200003290302.TAA21182@ns.secondary.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <200003290302.TAA21182@ns.secondary.com>; from lindsay@powerup.com.au on Wed, Mar 29, 2000 at 03:02:33AM +0000 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 29 Mar 2000, Lindsay Mathieson wrote: > Is there a public freeware implementation of rfc 2440 ? I know these implementations: a) Tom Zerucha's OPGP (ftp.cryptography.org?) b) GnuPG (ftp.gnupg.org/gcrypt/gnupg) I don't know whether PGP 7 is going to implement OpenPGP correctly, at least they are using deprecated features (pubkey algos 2 and 3). -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Wed Mar 29 05:49:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18795 for ; Wed, 29 Mar 2000 05:49:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA19316 for ietf-openpgp-bks; Wed, 29 Mar 2000 02:33:46 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA19310 for ; Wed, 29 Mar 2000 02:33:44 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aFwl-0005xa-00; Wed, 29 Mar 2000 12:43:35 +0200 Date: Wed, 29 Mar 2000 12:43:35 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329124335.L20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200003282006.PAA12308@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <200003282006.PAA12308@domains.invweb.net>; from whgiii@openpgp.net on Tue, Mar 28, 2000 at 02:06:36PM -0600 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 28 Mar 2000, William H. Geiger III wrote: > Most 2440 applications will also want to be PGP/MIME compliant. I don't think so, it is good Unix practise to do layering and MIME is something you need in MUAs and not in an encryption tool. > The second part would be the "outbound" generation of RFC 2440 packets. We > should be able to have a set of "skeleton" packets that the tester could > use for compairison while ignoring the raw data (ie MPI's) that may be It is not possible to simply compare the packets for a couple of reasons: You should have random data in it, an implemenation has several choices to encode the packet length and and the order of subpackets is not regulated. Doing some clever diffs over the output of a packet dumping tools would be possible. > different. As an example the application being tested needs to generate a > v3 RSA public key. The tests could use the "skeleton" test packet to (OpenPGP implementations SHOULD generate V4 keys (see 5.5.2)) IMHO, tTest scripts are the way to go; this is a lot of work unless we agree on a common commandline interface and each implementation comes with a wrapper for this interface. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Wed Mar 29 06:50:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19475 for ; Wed, 29 Mar 2000 06:50:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25158 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:31:00 -0800 (PST) Received: from atanda.com (abel.intermag.com [209.31.7.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25154 for ; Wed, 29 Mar 2000 03:30:58 -0800 (PST) Received: from [192.168.248.7] (216.100.248.78) by atanda.com with ESMTP (Eudora Internet Mail Server 1.2.1); Wed, 29 Mar 2000 03:33:57 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <20000329124335.L20405@djebel.gnupg.de> References: <200003282006.PAA12308@domains.invweb.net> <20000329124335.L20405@djebel.gnupg.de> Date: Wed, 29 Mar 2000 03:19:54 -0800 To: Werner Koch From: Dave Del Torto Subject: Re: DRAFT status and Compatibility testing Cc: ietf-openpgp@imc.org, William H Geiger III 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:43 pm +0200 2000-03-29, Werner Koch wrote: >On Tue, 28 Mar 2000, William H. Geiger III wrote: > > > Most 2440 applications will also want to be PGP/MIME compliant. > >I don't think so, it is good Unix practise to do layering and MIME is >something you need in MUAs and not in an encryption tool. Werner, I am hoping you'll also implement our two newest drafts, OpenPGP/MIME and OpenPGP/MIME Multipart Signatures. Both could be extremely useful in a scriptable UNIX GnuPG version. I've asked Will Price at PGP Security if they plan to support the drafts, but I'm not sure they plan to do so. If both were interoperable, that would of course be ideal. :) dave From owner-ietf-openpgp@mail.imc.org Wed Mar 29 06:51:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19521 for ; Wed, 29 Mar 2000 06:51:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25310 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:34:25 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25293 for ; Wed, 29 Mar 2000 03:34:07 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id 202C712799; Wed, 29 Mar 2000 13:35:50 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 82D77F259; Wed, 29 Mar 2000 13:28:17 +0200 (MEST) Date: Wed, 29 Mar 2000 13:28:17 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329132817.L25646@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , ietf-openpgp@imc.org References: <200003290302.TAA21182@ns.secondary.com> <20000329123135.K20405@djebel.gnupg.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <20000329123135.K20405@djebel.gnupg.de>; from wk@gnupg.org on Wed, Mar 29, 2000 at 12:31:35PM +0200 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-29 12:31:35 +0200, Werner Koch wrote: > a) Tom Zerucha's OPGP (ftp.cryptography.org?) Is this, BTW, available outside the United States now? -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Wed Mar 29 06:58:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19613 for ; Wed, 29 Mar 2000 06:58:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25305 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:34:23 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25300 for ; Wed, 29 Mar 2000 03:34:21 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id 52F8D12787; Wed, 29 Mar 2000 13:35:49 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id B70B2F259; Wed, 29 Mar 2000 13:23:54 +0200 (MEST) Date: Wed, 29 Mar 2000 13:23:54 +0200 From: Thomas Roessler To: "William H. Geiger III" Cc: Jon Callas , ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329132354.K25646@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , "William H. Geiger III" , Jon Callas , ietf-openpgp@imc.org References: <200003282006.PAA12308@domains.invweb.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <200003282006.PAA12308@domains.invweb.net>; from whgiii@openpgp.net on Tue, Mar 28, 2000 at 02:06:36PM -0600 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-28 14:06:36 -0600, William H. Geiger III wrote: > Yes but there is no reason why not to include PGP/MIME > test data. One can document that this part of the data > is for a seperate yet related RFC. Most 2440 > applications will also want to be PGP/MIME compliant. I tend to disagree. For instance, code signing with OpenPGP certainly has no use for the PGP/MIME framework. Additionally, PGP/MIME is essentially just about MIME encapsulation of PGP messages, so a test suite for this could be quite restricted, and would mostly have to handle MIME encoding issues and pitfalls, plus some playing around with micalg parameters and their effect. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Wed Mar 29 07:03:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19757 for ; Wed, 29 Mar 2000 07:03:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25476 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:46:17 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25470 for ; Wed, 29 Mar 2000 03:45:44 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id A45341282F; Wed, 29 Mar 2000 13:47:38 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id EF0FAF259; Wed, 29 Mar 2000 13:45:52 +0200 (MEST) Date: Wed, 29 Mar 2000 13:45:52 +0200 From: Thomas Roessler To: Dave Del Torto Cc: Werner Koch , ietf-openpgp@imc.org, William H Geiger III Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329134552.O25646@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , Dave Del Torto , Werner Koch , ietf-openpgp@imc.org, William H Geiger III References: <200003282006.PAA12308@domains.invweb.net> <20000329124335.L20405@djebel.gnupg.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: ; from ddt@openpgp.net on Wed, Mar 29, 2000 at 03:19:54AM -0800 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-29 03:19:54 -0800, Dave Del Torto wrote: > I am hoping you'll also implement our two newest > drafts, OpenPGP/MIME and OpenPGP/MIME Multipart > Signatures. Both could be extremely useful in a > scriptable UNIX GnuPG version. I think that, for Unix use, a perl script based on, say, the MIME::Tools (3pm) package would be better suited. Everything else would mean code duplication when GnuPG is used with any reasonable Mail User Agent which has a decent MIME parser itself. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Wed Mar 29 07:17:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19960 for ; Wed, 29 Mar 2000 07:17:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25713 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:59:43 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25709 for ; Wed, 29 Mar 2000 03:59:42 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aHHy-00060x-00; Wed, 29 Mar 2000 14:09:34 +0200 Date: Wed, 29 Mar 2000 14:09:34 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329140934.N20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200003282006.PAA12308@domains.invweb.net> <20000329124335.L20405@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: ; from ddt@openpgp.net on Wed, Mar 29, 2000 at 03:19:54AM -0800 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 29 Mar 2000, Dave Del Torto wrote: > I am hoping you'll also implement our two newest drafts, OpenPGP/MIME > and OpenPGP/MIME Multipart Signatures. Both could be extremely useful > in a scriptable UNIX GnuPG version. I'll provide any low level function when needed; however everything else can be done with a little bit of scripting. -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Wed Mar 29 07:25:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20054 for ; Wed, 29 Mar 2000 07:25:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA25796 for ietf-openpgp-bks; Wed, 29 Mar 2000 04:06:01 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25791 for ; Wed, 29 Mar 2000 04:06:00 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aHO4-00061N-00; Wed, 29 Mar 2000 14:15:52 +0200 Date: Wed, 29 Mar 2000 14:15:52 +0200 From: Werner Koch To: ietf-openpgp@imc.org Cc: Thomas Roessler Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329141552.O20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org, Thomas Roessler References: <200003290302.TAA21182@ns.secondary.com> <20000329123135.K20405@djebel.gnupg.de> <20000329132817.L25646@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <20000329132817.L25646@sobolev.rhein.de>; from roessler@guug.de on Wed, Mar 29, 2000 at 01:28:17PM +0200 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 29 Mar 2000, Thomas Roessler wrote: > > a) Tom Zerucha's OPGP (ftp.cryptography.org?) > > Is this, BTW, available outside the United States now? An unamed person from outside the U.S. sent me a copy some time ago. A small problem with 0.99x is that it does not link against OpenSSL. -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Wed Mar 29 09:22:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21229 for ; Wed, 29 Mar 2000 09:22:43 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA28166 for ietf-openpgp-bks; Wed, 29 Mar 2000 05:55:17 -0800 (PST) Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28162 for ; Wed, 29 Mar 2000 05:55:15 -0800 (PST) Received: from road-warrior (mg128-055.ricochet.net [204.179.128.55]) by rgate2.ricochet.net (8.9.3/8.9.3) with ESMTP id HAA24580 for ; Wed, 29 Mar 2000 07:57:31 -0600 (CST) Message-Id: <4.2.0.58.20000329055643.0234be40@216.240.42.209> X-Sender: rodney@216.240.42.209 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 29 Mar 2000 05:57:29 -0800 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Zerucha's OPGP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: anyone actually found a copy of Zerucha's code lately? www.cryptography.org seens to not have it (an 'opgp', that is) From owner-ietf-openpgp@mail.imc.org Wed Mar 29 12:55:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23136 for ; Wed, 29 Mar 2000 12:55:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02529 for ietf-openpgp-bks; Wed, 29 Mar 2000 09:27:42 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02524 for ; Wed, 29 Mar 2000 09:27:36 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id B19811287D; Wed, 29 Mar 2000 19:29:29 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 75032F259; Wed, 29 Mar 2000 19:29:05 +0200 (MEST) Date: Wed, 29 Mar 2000 19:29:05 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000329192904.B12300@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , ietf-openpgp@imc.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've started work on a suite of test messages which are intended to help verify the correctness of the receiving end of a PGP/MIME implementation. Currently, I'm using PGP 2.6.3in and RSA/MD5 for the underlying encryption and signature creation, however, this can easily be changed to a more modern version of PGP or GnuPG - the messages are generated by a shell script, which does all the MIME stuff "by hand", so no actual MUA is involved with the creation of these messages. The set of messages I have so far is quite simple. Generally, I try to poke a bit at the interaction between the MIME and PGP layers, and at crucial features which should better be present on the PGP layer if PGP/MIME should work. - Problems I encountered in the past with the interaction of MIME and PGP/MIME engines - this includes things like quotes around boundary parameters where they aren't needed and positions of parameters (I've chosen a hopefully sufficiently strange order to expose eventual bugs here; we may wish to check all permutations in the future). - Binary and text-mode signatures. The PGP/MIME text doesn't specify what to send, and actually both types are valid and should work neatly. However, this should be verified. - Trailing whitespace. I've seen this break some back-ends. - Unterminated last lines. It seems that there has been some confusion about how this should be handled in the past. Those who are interested in trying this, please have a look at: ftp://riemann.iam.uni-bonn.de/pub/users/roessler/pgpmime-interop/ This directory contains 5 files: - forms.txt is a first take at a report form. - interop.maildir.tar is a tar archive which contains a maildir folder with the 36 test messages. Essentially, this is a directory structure where every message is stored in a file of it's own. - interop.mbox is an mbox folder which contains the 36 test messages. - interop.pgp.tar contains the pubring.pgp and secring.pgp files with the key I use for testing. The pass phrase is "none". - interop.src.tar contains the shell script and a small C helper program I use to create the messages. Comments are highly welcome. Also, please notify me immediately if my script is generating illegal messages (although I hope not to do this). -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Wed Mar 29 17:18:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25034 for ; Wed, 29 Mar 2000 17:18:36 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA07777 for ietf-openpgp-bks; Wed, 29 Mar 2000 13:57:08 -0800 (PST) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07773 for ; Wed, 29 Mar 2000 13:57:07 -0800 (PST) Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id QAA22523; Wed, 29 Mar 2000 16:59:26 -0500 (EST) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id QAA27342; Wed, 29 Mar 2000 16:56:33 -0500 Date: Wed, 29 Mar 2000 16:56:33 -0500 From: Tom Zerucha To: Rodney Thayer Cc: ietf-openpgp@imc.org Subject: Re: Zerucha's OPGP? Message-ID: <20000329165633.A27338@deimos.mw.mediaone.net> References: <4.2.0.58.20000329055643.0234be40@216.240.42.209> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.0.58.20000329055643.0234be40@216.240.42.209>; from rodney@tillerman.to on Wed, Mar 29, 2000 at 05:57:29AM -0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 29, 2000 at 05:57:29AM -0800, Rodney Thayer wrote: > anyone actually found a copy of Zerucha's code lately? www.cryptography.org > seens to not have it (an 'opgp', that is) http://cryptography.org/crypto/[RANDOM]/pgp/palmopgp/ has an openssl version, though it might be a little datd. http://cryptography.org/crypto/[RANDOM]/pgp/opgp/ has the 0.99x version If anyone else wants to host it, feel free to do so. Here is a (OOPS, REVERSED) patch against 0.99x for OpenSSL 0.9.4: diff -Bbur opgp-1.0a/libopgp.doc opgp99x/libopgp.doc --- opgp-1.0a/libopgp.doc Wed Mar 29 16:45:06 2000 +++ opgp99x/libopgp.doc Mon Aug 24 01:12:01 1998 @@ -1,4 +1,4 @@ -PGPlib 1.00 Free Open PGP toolkit +PGPlib 1.00 (prerelease) Open PGP toolkit opgplib is a set of routines designed to implement OpenPGP according to the IETF specification using SSLeay and zlib. @@ -42,8 +42,7 @@ MAIN -opgp is a command line program that allows easy script (batch) access -for encryption and signature functions within the library. +opgp is a not-quite compatible version of PGP5.0. See opgp -q usage for updates, but briefly, opgp without encryption parameters will process until it gets text or a literal packet, and thus duplicates most diff -Bbur opgp-1.0a/opgplib/getkey.c opgp99x/opgplib/getkey.c --- opgp-1.0a/opgplib/getkey.c Wed Mar 29 16:44:35 2000 +++ opgp99x/opgplib/getkey.c Sat Jul 18 00:07:12 1998 @@ -186,7 +186,7 @@ continue; rsatmp->d = PGP_mpiBN(&bp); rsatmp->q = PGP_mpiBN(&bp), rsatmp->p = PGP_mpiBN(&bp); - BN_mul(temp = BN_new(), rsatmp->q, rsatmp->p, ctx); /* n=pq? */ + BN_mul(temp = BN_new(), rsatmp->q, rsatmp->p); /* n=pq? */ if (BN_cmp(temp, rsatmp->n) != 0) { RSA_free(rsatmp); BN_free(temp); diff -Bbur opgp-1.0a/opgplib/pkdec.c opgp99x/opgplib/pkdec.c --- opgp-1.0a/opgplib/pkdec.c Wed Mar 29 16:44:37 2000 +++ opgp99x/opgplib/pkdec.c Sat Jul 18 00:07:12 1998 @@ -29,13 +29,13 @@ if (j == 16 || j == 20) { u8_t cbuf[1024]; /* size of key */ BN_CTX *ctx = BN_CTX_new(); - BIGNUM *a, *b, *c = BN_new(); + BIGNUM *a, *b, *c; DH *dhkey = deckey; a = PGP_mpiBN(&bp); b = PGP_mpiBN(&bp); BN_mod_exp(a, a, dhkey->priv_key, dhkey->p, ctx); - BN_mod_inverse(c, a, dhkey->p, ctx); + c = BN_mod_inverse(a, dhkey->p, ctx); BN_mod_mul(a, c, b, dhkey->p, ctx); DH_free(dhkey), BN_clear_free(b), BN_clear_free(c), BN_CTX_free(ctx); j = BN_bn2bin(a, cbuf); diff -Bbur opgp-1.0a/opgplib/sigchk.c opgp99x/opgplib/sigchk.c --- opgp-1.0a/opgplib/sigchk.c Wed Mar 29 16:44:40 2000 +++ opgp99x/opgplib/sigchk.c Mon Aug 24 01:13:04 1998 @@ -10,10 +10,10 @@ u8_t * hash, int hlen) { BN_CTX *ctx = BN_CTX_new(); - BIGNUM *t1 = BN_new(), *t2 = BN_new(), *t3 = BN_new(), *u2 = BN_new(); + BIGNUM *t1 = BN_new(), *t2 = BN_new(), *t3 = BN_new(), *u2 = NULL; int ret; - BN_mod_inverse(u2, u1, dsakey->q, ctx); + u2 = BN_mod_inverse(u1, dsakey->q, ctx); BN_bin2bn(hash, hlen, t3); BN_mod_mul(t3, t3, u2, dsakey->q, ctx); BN_mod_mul(u2, r, u2, dsakey->q, ctx); diff -Bbur opgp-1.0a/opgplib/sigmak.c opgp99x/opgplib/sigmak.c --- opgp-1.0a/opgplib/sigmak.c Wed Mar 29 16:44:41 2000 +++ opgp99x/opgplib/sigmak.c Mon Aug 24 01:13:04 1998 @@ -62,9 +62,9 @@ BN_mod_exp(u1, ((DSA *) seckey)->g, u2, ((DSA *) seckey)->p, ctx); BN_mod(r, u1, ((DSA *) seckey)->q, ctx); /* Compute u1 = inv(u2) (t2 + xr) mod q */ - BN_mul(u1, ((DSA *) seckey)->priv_key, r, ctx); + BN_mul(u1, ((DSA *) seckey)->priv_key, r); BN_add(u1, u1, t2); - BN_mod_inverse(t1, u2, ((DSA *) seckey)->q, ctx); + t1 = BN_mod_inverse(u2, ((DSA *) seckey)->q, ctx); BN_mod_mul(u1, u1, t1, ((DSA *) seckey)->q, ctx); DSA_free(((DSA *) seckey)); } else diff -Bbur opgp-1.0a/paths.mak opgp99x/paths.mak --- opgp-1.0a/paths.mak Wed Mar 29 16:44:27 2000 +++ opgp99x/paths.mak Mon Jun 8 11:28:33 1998 @@ -1,6 +1,6 @@ SSLPATH = /usr/local/ssl LIBPATH = -L$(SSLPATH)/lib -INCLUDE = -I$(SSLPATH)/include/openssl -I$(SSLPATH)/include +INCLUDE = -I$(SSLPATH)/include CFLAGS = -Wall $(INCLUDE) -O6 -s #where to put the files From owner-ietf-openpgp@mail.imc.org Wed Mar 29 18:04:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25353 for ; Wed, 29 Mar 2000 18:04:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08445 for ietf-openpgp-bks; Wed, 29 Mar 2000 14:42:03 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08436 for ; Wed, 29 Mar 2000 14:41:58 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id ECFEF12835; Thu, 30 Mar 2000 00:43:54 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id F1D62F259; Thu, 30 Mar 2000 00:29:13 +0200 (MEST) Date: Thu, 30 Mar 2000 00:29:13 +0200 From: Thomas Roessler To: Tom Zerucha Cc: Rodney Thayer , ietf-openpgp@imc.org Subject: Re: Zerucha's OPGP? Message-ID: <20000330002913.C19932@sobolev.rhein.de> Mail-Followup-To: Tom Zerucha , Rodney Thayer , ietf-openpgp@imc.org References: <4.2.0.58.20000329055643.0234be40@216.240.42.209> <20000329165633.A27338@deimos.mw.mediaone.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <20000329165633.A27338@deimos.mw.mediaone.net>; from tz@execpc.com on Wed, Mar 29, 2000 at 04:56:33PM -0500 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tom, would you mind to check out http://cryptome.org/bernstein-bxa.org? I think you can now legally make your implementation accessible to the general public, even outside the United States, so we can use it as a reference module for some of the interoperability testing. Thanks. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Thu Mar 30 05:46:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15276 for ; Thu, 30 Mar 2000 05:46:29 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA10711 for ietf-openpgp-bks; Thu, 30 Mar 2000 02:10:22 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10707 for ; Thu, 30 Mar 2000 02:10:20 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA15113; Thu, 30 Mar 2000 11:12:36 +0100 (BST) Message-ID: Date: Thu, 30 Mar 2000 11:09:56 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. References: <20000329192904.B12300@sobolev.rhein.de> In-Reply-To: <20000329192904.B12300@sobolev.rhein.de> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.00 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Mar 2000, Thomas Roessler wrote: >- Binary and text-mode signatures. The PGP/MIME text > doesn't specify what to send, and actually both types > are valid and should work neatly. However, this should > be verified. From RFC2015: 2. PGP data formats PGP can generate either ASCII armor (described in [3]) or 8-bit binary output when encrypting data, generating a digital signature, or extracting public key data. The ASCII armor output is the REQUIRED method for data transfer. So binary-mode signatures are forbidden, and remain so in the new draft. -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Thu Mar 30 06:07:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15438 for ; Thu, 30 Mar 2000 06:07:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA11577 for ietf-openpgp-bks; Thu, 30 Mar 2000 02:35:33 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11572 for ; Thu, 30 Mar 2000 02:35:29 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id D571B1278C; Thu, 30 Mar 2000 12:37:19 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 2BF92F259; Thu, 30 Mar 2000 12:36:07 +0200 (MEST) Date: Thu, 30 Mar 2000 12:36:06 +0200 From: Thomas Roessler To: Ian Bell Cc: ietf-openpgp@imc.org Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000330123606.F27865@sobolev.rhein.de> Mail-Followup-To: Ian Bell , ietf-openpgp@imc.org References: <20000329192904.B12300@sobolev.rhein.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.10i In-Reply-To: ; from ianbell@turnpike.com on Thu, Mar 30, 2000 at 11:09:56AM +0100 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-30 11:09:56 +0100, Ian Bell wrote: > PGP can generate either ASCII armor (described in > [3]) or 8-bit binary output when encrypting data, > generating a digital signature, or extracting > public key data. The ASCII armor output is the > REQUIRED method for data transfer. > So binary-mode signatures are forbidden, and remain so > in the new draft. We are talking about different things here. What you are quoting concerns PGP's _output_ format. The test is about signature types 0 (binary document) and 1 (canonical text document), see section 5.2.1 of RFC 2440. The point here is that, with type 0 signatures, any PGP/MIME implemenation must make sure that the proper line endings are passed to the PGP back-end, while, with type 1 signatures in mind, one may be tempted to short-cut this requirement from the PGP/MIME document and leave line-end con versions to the back-end. (Note that this should actually work nicely when _generating_ signatures. Actually, I don't even know whether any existing implementation really generates type 0 signatures with PGP/MIME.) -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Thu Mar 30 08:20:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16268 for ; Thu, 30 Mar 2000 08:20:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA17140 for ietf-openpgp-bks; Thu, 30 Mar 2000 04:17:52 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17136 for ; Thu, 30 Mar 2000 04:17:46 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id 55D1B128BA; Thu, 30 Mar 2000 14:19:47 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 97704F259; Thu, 30 Mar 2000 14:19:28 +0200 (MEST) Date: Thu, 30 Mar 2000 14:19:27 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: PGP/MIME interop, new test data Message-ID: <20000330141927.B30730@sobolev.rhein.de> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.10i Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The script I used to generate the test data triggered a bug in the PGP version installed here (over-eager addition of carriage returns, *grrrr*). I've just uploaded new test data. --=20 http://www.guug.de/~roessler/ --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOONGTNImKUTOasbBAQFChQf8DeVEns4sHuP+azKrE3FeQBwWctwZCx1e NVlRhwTIiRAKtkSDnFQHJG2ClXX7fzrqP05RI6oJ1pYoUqNBT04aWmbLu8f88Mbq lhXGjjeYEe7XACuOzeR47cj3gN6WuJW3XfCxIMbOV0WCFFADskmO18GtSe5+ROUl MfwQlYBo18oOvIjzs46q8HBpvKA8YGRIqmzLFeFOrIsHP+ANHh2uGZ8W0Yh8gVbU lNpCyc73eux9MIOLd7rQE2vz1ZFF18qpOOhwyOZZ8g4xS2btVTaZ8BbxPkQ/JN1c LEnCybdrpPsmdi+yBf17SrXmxZ7rhAzUNUC4JqQ22kLjyg966a0OVA== =75hk -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- From owner-ietf-openpgp@mail.imc.org Thu Mar 30 20:44:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24539 for ; Thu, 30 Mar 2000 20:44:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA01081 for ietf-openpgp-bks; Thu, 30 Mar 2000 17:25:49 -0800 (PST) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01077 for ; Thu, 30 Mar 2000 17:25:48 -0800 (PST) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA11964; Thu, 30 Mar 2000 17:27:53 -0800 (PST) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA11960; Thu, 30 Mar 2000 17:27:52 -0800 (PST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: <20000329192904.B12300@sobolev.rhein.de> Date: Thu, 30 Mar 2000 17:27:42 -0800 To: Ian Bell , ietf-openpgp@imc.org From: Jon Callas Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:09 AM +0100 3/30/00, Ian Bell wrote: >2. PGP data formats > > PGP can generate either ASCII armor (described in [3]) or 8-bit > binary output when encrypting data, generating a digital signature, > or extracting public key data. The ASCII armor output is the > REQUIRED method for data transfer. > >So binary-mode signatures are forbidden, and remain so in the new draft. > I don't think so. There are two issues here -- the "mode" of the signature and the format of the output. The mode of the signature takes into account whitespace and line-end issues. The format of the output is whether the OpenPGP packets are put in raw binary, or are ASCII armored. What this is saying is that you have to use ASCII armor in OpenPGP/MIME. It's not saying that you can't have a binary mode signature. If you are using OpenPGP/MIME to sign a zip file (for example), you do it in binary mode, but you armor the output. Clear as mud? Jon From owner-ietf-openpgp@mail.imc.org Fri Mar 31 04:56:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11464 for ; Fri, 31 Mar 2000 04:56:46 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA26795 for ietf-openpgp-bks; Fri, 31 Mar 2000 01:36:16 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26771 for ; Fri, 31 Mar 2000 01:36:03 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id E32A212771; Fri, 31 Mar 2000 11:38:07 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 80892F259; Fri, 31 Mar 2000 11:33:36 +0200 (MEST) Date: Fri, 31 Mar 2000 11:33:36 +0200 From: Thomas Roessler To: Jon Callas Cc: Ian Bell , ietf-openpgp@imc.org Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000331113336.T5716@sobolev.rhein.de> Mail-Followup-To: Jon Callas , Ian Bell , ietf-openpgp@imc.org References: <20000329192904.B12300@sobolev.rhein.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.10i In-Reply-To: ; from jon@callas.org on Thu, Mar 30, 2000 at 05:27:42PM -0800 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-30 17:27:42 -0800, Jon Callas wrote: > What this is saying is that you have to use ASCII armor > in OpenPGP/MIME. It's not saying that you can't have a > binary mode signature. If you are using OpenPGP/MIME to > sign a zip file (for example), you do it in binary > mode, but you armor the output. Not necessarily. Since the zip file will be MIME-encoded before signing, you can also use a text-mode signature for this. ;-) -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Fri Mar 31 06:15:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12619 for ; Fri, 31 Mar 2000 06:15:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01272 for ietf-openpgp-bks; Fri, 31 Mar 2000 02:51:16 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01268 for ; Fri, 31 Mar 2000 02:51:14 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA14309; Fri, 31 Mar 2000 11:53:48 +0100 (BST) Message-ID: Date: Fri, 31 Mar 2000 11:51:00 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. References: <20000329192904.B12300@sobolev.rhein.de> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 30 Mar 2000, Jon Callas wrote: >At 11:09 AM +0100 3/30/00, Ian Bell wrote: > >>2. PGP data formats >> >> PGP can generate either ASCII armor (described in [3]) or 8-bit >> binary output when encrypting data, generating a digital signature, >> or extracting public key data. The ASCII armor output is the >> REQUIRED method for data transfer. >> >>So binary-mode signatures are forbidden, and remain so in the new draft. >> > >I don't think so. > >There are two issues here -- the "mode" of the signature and the format of >the output. I realize that now from Thomas' reply! >The mode of the signature takes into account whitespace and line-end issues. >If you are >using OpenPGP/MIME to sign a zip file (for example), you do it in binary >mode, but you armor the output. It is a requirement that in PGP/MIME messages the signature is calculated over the canonicalized and encoded data. By the time you calculate the signature, the zip file data is base64 with CRLF line endings. So: * Is it still possible to use a binary mode signature (I think the answer is "yes")? If so, * Is there any point in using a binary-mode signature over data which by this point is CRLF-terminated lines of us-ascii characters? * Can this (unnecessary) use of binary-mode lead to backwards-compatibility problems? * If there are compatibility problems, shouldn't there be a "SHOULD NOT use binary mode signatures" in the openPGP/MIME draft? Turnpike is not an openPGP client (we use the PGP sdk itself for our cryptographic operations) - hence there may be more things here that I have overlooked. My interest in openPGP primarily concerns interoperability and new extensions (like the multiple signature draft). -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Fri Mar 31 19:03:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19645 for ; Fri, 31 Mar 2000 19:03:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA25166 for ietf-openpgp-bks; Fri, 31 Mar 2000 15:45:47 -0800 (PST) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25162 for ; Fri, 31 Mar 2000 15:45:46 -0800 (PST) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA13245; Fri, 31 Mar 2000 15:47:56 -0800 (PST) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA13241; Fri, 31 Mar 2000 15:47:55 -0800 (PST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: <20000329192904.B12300@sobolev.rhein.de> Date: Fri, 31 Mar 2000 15:47:56 -0800 To: Ian Bell , ietf-openpgp@imc.org From: Jon Callas Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:51 AM +0100 3/31/00, Ian Bell wrote: >>The mode of the signature takes into account whitespace and line-end issues. > >>If you are >>using OpenPGP/MIME to sign a zip file (for example), you do it in binary >>mode, but you armor the output. > >It is a requirement that in PGP/MIME messages the signature is >calculated over the canonicalized and encoded data. By the time you >calculate the signature, the zip file data is base64 with CRLF line >endings. So: > >* Is it still possible to use a binary mode signature (I think the > answer is "yes")? > I would think yes. Thomas's comment notwithstanding, if you encrypt and sign a binary file, you want to use binary mode. If you can't encrypt and sign a binary file, then PGP/MIME is mostly worthless. >If so, > >* Is there any point in using a binary-mode signature over data which by > this point is CRLF-terminated lines of us-ascii characters? > Maybe. It depends on the semantic comment of the file. >* Can this (unnecessary) use of binary-mode lead to > backwards-compatibility problems? > >* If there are compatibility problems, shouldn't there be a "SHOULD NOT > use binary mode signatures" in the openPGP/MIME draft? > Consider this to be pretty much the same as text mode VS binary mode in FTP. If you send a binary file in text mode, you can end up with problems, depending on what the sender and receiver think constitutes a line end. This ends up essentially being data corruption and an interoperability problem. For example, if you send a binary file in text mode from a unix system to an NT system, then the NT system will replace all 0x10 (pseudo-LFs) with 0x1310 (pseudo-CRLF). If you then pull it back to a unix system in text mode, this will be undone. But if you transfer it in binary mode, you have garbage added bytes. If you were really unlucky and you then got the file in text mode on a Mac, then the 0x1310s will all become 0x13s. If you send a text file in binary mode, then it might end up on another system with the wrong flavor of line ends. Needless to say, if you do this in a signature, this will cause the signature to not match. Other interesting forms of corruption are left as an exercise for the reader. Amuse yourself by looking at all the text on canonicalization. This isn't a standards problem. This is an implementation/user problem. It's all related to the very idea of text mode. Arguably, text mode is a broken concept. However, it's there for a reason, and that reason is that there's no global agreement on what constitutes text, and that a binary transfer of text will *also* cause "data corruption." So, popping back to your questions, no, we have to have binary mode signatures, or else PGP/MIME can't sign a binary file cross-platform. If all parties are using the same rules of what text is, then it doesn't matter what mode you use, as long as you use the same mode. If you want to cross a text-rule boundary, you have to use the right mode. Jon Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA25166 for ietf-openpgp-bks; Fri, 31 Mar 2000 15:45:47 -0800 (PST) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA25162 for ; Fri, 31 Mar 2000 15:45:46 -0800 (PST) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA13245; Fri, 31 Mar 2000 15:47:56 -0800 (PST) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA13241; Fri, 31 Mar 2000 15:47:55 -0800 (PST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: <20000329192904.B12300@sobolev.rhein.de> Date: Fri, 31 Mar 2000 15:47:56 -0800 To: Ian Bell , ietf-openpgp@imc.org From: Jon Callas Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:51 AM +0100 3/31/00, Ian Bell wrote: >>The mode of the signature takes into account whitespace and line-end issues. > >>If you are >>using OpenPGP/MIME to sign a zip file (for example), you do it in binary >>mode, but you armor the output. > >It is a requirement that in PGP/MIME messages the signature is >calculated over the canonicalized and encoded data. By the time you >calculate the signature, the zip file data is base64 with CRLF line >endings. So: > >* Is it still possible to use a binary mode signature (I think the > answer is "yes")? > I would think yes. Thomas's comment notwithstanding, if you encrypt and sign a binary file, you want to use binary mode. If you can't encrypt and sign a binary file, then PGP/MIME is mostly worthless. >If so, > >* Is there any point in using a binary-mode signature over data which by > this point is CRLF-terminated lines of us-ascii characters? > Maybe. It depends on the semantic comment of the file. >* Can this (unnecessary) use of binary-mode lead to > backwards-compatibility problems? > >* If there are compatibility problems, shouldn't there be a "SHOULD NOT > use binary mode signatures" in the openPGP/MIME draft? > Consider this to be pretty much the same as text mode VS binary mode in FTP. If you send a binary file in text mode, you can end up with problems, depending on what the sender and receiver think constitutes a line end. This ends up essentially being data corruption and an interoperability problem. For example, if you send a binary file in text mode from a unix system to an NT system, then the NT system will replace all 0x10 (pseudo-LFs) with 0x1310 (pseudo-CRLF). If you then pull it back to a unix system in text mode, this will be undone. But if you transfer it in binary mode, you have garbage added bytes. If you were really unlucky and you then got the file in text mode on a Mac, then the 0x1310s will all become 0x13s. If you send a text file in binary mode, then it might end up on another system with the wrong flavor of line ends. Needless to say, if you do this in a signature, this will cause the signature to not match. Other interesting forms of corruption are left as an exercise for the reader. Amuse yourself by looking at all the text on canonicalization. This isn't a standards problem. This is an implementation/user problem. It's all related to the very idea of text mode. Arguably, text mode is a broken concept. However, it's there for a reason, and that reason is that there's no global agreement on what constitutes text, and that a binary transfer of text will *also* cause "data corruption." So, popping back to your questions, no, we have to have binary mode signatures, or else PGP/MIME can't sign a binary file cross-platform. If all parties are using the same rules of what text is, then it doesn't matter what mode you use, as long as you use the same mode. If you want to cross a text-rule boundary, you have to use the right mode. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01272 for ietf-openpgp-bks; Fri, 31 Mar 2000 02:51:16 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA01268 for ; Fri, 31 Mar 2000 02:51:14 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA14309; Fri, 31 Mar 2000 11:53:48 +0100 (BST) Message-ID: Date: Fri, 31 Mar 2000 11:51:00 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. References: <20000329192904.B12300@sobolev.rhein.de> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.00 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 30 Mar 2000, Jon Callas wrote: >At 11:09 AM +0100 3/30/00, Ian Bell wrote: > >>2. PGP data formats >> >> PGP can generate either ASCII armor (described in [3]) or 8-bit >> binary output when encrypting data, generating a digital signature, >> or extracting public key data. The ASCII armor output is the >> REQUIRED method for data transfer. >> >>So binary-mode signatures are forbidden, and remain so in the new draft. >> > >I don't think so. > >There are two issues here -- the "mode" of the signature and the format of >the output. I realize that now from Thomas' reply! >The mode of the signature takes into account whitespace and line-end issues. >If you are >using OpenPGP/MIME to sign a zip file (for example), you do it in binary >mode, but you armor the output. It is a requirement that in PGP/MIME messages the signature is calculated over the canonicalized and encoded data. By the time you calculate the signature, the zip file data is base64 with CRLF line endings. So: * Is it still possible to use a binary mode signature (I think the answer is "yes")? If so, * Is there any point in using a binary-mode signature over data which by this point is CRLF-terminated lines of us-ascii characters? * Can this (unnecessary) use of binary-mode lead to backwards-compatibility problems? * If there are compatibility problems, shouldn't there be a "SHOULD NOT use binary mode signatures" in the openPGP/MIME draft? Turnpike is not an openPGP client (we use the PGP sdk itself for our cryptographic operations) - hence there may be more things here that I have overlooked. My interest in openPGP primarily concerns interoperability and new extensions (like the multiple signature draft). -- Ian Bell T U R N P I K E Ltd Received: by ns.secondary.com (8.9.3/8.9.3) id BAA26795 for ietf-openpgp-bks; Fri, 31 Mar 2000 01:36:16 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA26771 for ; Fri, 31 Mar 2000 01:36:03 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id E32A212771; Fri, 31 Mar 2000 11:38:07 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 80892F259; Fri, 31 Mar 2000 11:33:36 +0200 (MEST) Date: Fri, 31 Mar 2000 11:33:36 +0200 From: Thomas Roessler To: Jon Callas Cc: Ian Bell , ietf-openpgp@imc.org Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000331113336.T5716@sobolev.rhein.de> Mail-Followup-To: Jon Callas , Ian Bell , ietf-openpgp@imc.org References: <20000329192904.B12300@sobolev.rhein.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.10i In-Reply-To: ; from jon@callas.org on Thu, Mar 30, 2000 at 05:27:42PM -0800 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-30 17:27:42 -0800, Jon Callas wrote: > What this is saying is that you have to use ASCII armor > in OpenPGP/MIME. It's not saying that you can't have a > binary mode signature. If you are using OpenPGP/MIME to > sign a zip file (for example), you do it in binary > mode, but you armor the output. Not necessarily. Since the zip file will be MIME-encoded before signing, you can also use a text-mode signature for this. ;-) -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id RAA01081 for ietf-openpgp-bks; Thu, 30 Mar 2000 17:25:49 -0800 (PST) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA01077 for ; Thu, 30 Mar 2000 17:25:48 -0800 (PST) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA11964; Thu, 30 Mar 2000 17:27:53 -0800 (PST) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA11960; Thu, 30 Mar 2000 17:27:52 -0800 (PST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: <20000329192904.B12300@sobolev.rhein.de> Date: Thu, 30 Mar 2000 17:27:42 -0800 To: Ian Bell , ietf-openpgp@imc.org From: Jon Callas Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:09 AM +0100 3/30/00, Ian Bell wrote: >2. PGP data formats > > PGP can generate either ASCII armor (described in [3]) or 8-bit > binary output when encrypting data, generating a digital signature, > or extracting public key data. The ASCII armor output is the > REQUIRED method for data transfer. > >So binary-mode signatures are forbidden, and remain so in the new draft. > I don't think so. There are two issues here -- the "mode" of the signature and the format of the output. The mode of the signature takes into account whitespace and line-end issues. The format of the output is whether the OpenPGP packets are put in raw binary, or are ASCII armored. What this is saying is that you have to use ASCII armor in OpenPGP/MIME. It's not saying that you can't have a binary mode signature. If you are using OpenPGP/MIME to sign a zip file (for example), you do it in binary mode, but you armor the output. Clear as mud? Jon Received: by ns.secondary.com (8.9.3/8.9.3) id EAA17140 for ietf-openpgp-bks; Thu, 30 Mar 2000 04:17:52 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17136 for ; Thu, 30 Mar 2000 04:17:46 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id 55D1B128BA; Thu, 30 Mar 2000 14:19:47 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 97704F259; Thu, 30 Mar 2000 14:19:28 +0200 (MEST) Date: Thu, 30 Mar 2000 14:19:27 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: PGP/MIME interop, new test data Message-ID: <20000330141927.B30730@sobolev.rhein.de> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.10i Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --ghzN8eJ9Qlbqn3iT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The script I used to generate the test data triggered a bug in the PGP version installed here (over-eager addition of carriage returns, *grrrr*). I've just uploaded new test data. --=20 http://www.guug.de/~roessler/ --ghzN8eJ9Qlbqn3iT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOONGTNImKUTOasbBAQFChQf8DeVEns4sHuP+azKrE3FeQBwWctwZCx1e NVlRhwTIiRAKtkSDnFQHJG2ClXX7fzrqP05RI6oJ1pYoUqNBT04aWmbLu8f88Mbq lhXGjjeYEe7XACuOzeR47cj3gN6WuJW3XfCxIMbOV0WCFFADskmO18GtSe5+ROUl MfwQlYBo18oOvIjzs46q8HBpvKA8YGRIqmzLFeFOrIsHP+ANHh2uGZ8W0Yh8gVbU lNpCyc73eux9MIOLd7rQE2vz1ZFF18qpOOhwyOZZ8g4xS2btVTaZ8BbxPkQ/JN1c LEnCybdrpPsmdi+yBf17SrXmxZ7rhAzUNUC4JqQ22kLjyg966a0OVA== =75hk -----END PGP SIGNATURE----- --ghzN8eJ9Qlbqn3iT-- Received: by ns.secondary.com (8.9.3/8.9.3) id CAA11577 for ietf-openpgp-bks; Thu, 30 Mar 2000 02:35:33 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA11572 for ; Thu, 30 Mar 2000 02:35:29 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id D571B1278C; Thu, 30 Mar 2000 12:37:19 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 2BF92F259; Thu, 30 Mar 2000 12:36:07 +0200 (MEST) Date: Thu, 30 Mar 2000 12:36:06 +0200 From: Thomas Roessler To: Ian Bell Cc: ietf-openpgp@imc.org Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000330123606.F27865@sobolev.rhein.de> Mail-Followup-To: Ian Bell , ietf-openpgp@imc.org References: <20000329192904.B12300@sobolev.rhein.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.10i In-Reply-To: ; from ianbell@turnpike.com on Thu, Mar 30, 2000 at 11:09:56AM +0100 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-30 11:09:56 +0100, Ian Bell wrote: > PGP can generate either ASCII armor (described in > [3]) or 8-bit binary output when encrypting data, > generating a digital signature, or extracting > public key data. The ASCII armor output is the > REQUIRED method for data transfer. > So binary-mode signatures are forbidden, and remain so > in the new draft. We are talking about different things here. What you are quoting concerns PGP's _output_ format. The test is about signature types 0 (binary document) and 1 (canonical text document), see section 5.2.1 of RFC 2440. The point here is that, with type 0 signatures, any PGP/MIME implemenation must make sure that the proper line endings are passed to the PGP back-end, while, with type 1 signatures in mind, one may be tempted to short-cut this requirement from the PGP/MIME document and leave line-end con versions to the back-end. (Note that this should actually work nicely when _generating_ signatures. Actually, I don't even know whether any existing implementation really generates type 0 signatures with PGP/MIME.) -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id CAA10711 for ietf-openpgp-bks; Thu, 30 Mar 2000 02:10:22 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10707 for ; Thu, 30 Mar 2000 02:10:20 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA15113; Thu, 30 Mar 2000 11:12:36 +0100 (BST) Message-ID: Date: Thu, 30 Mar 2000 11:09:56 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. References: <20000329192904.B12300@sobolev.rhein.de> In-Reply-To: <20000329192904.B12300@sobolev.rhein.de> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.00 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Mar 2000, Thomas Roessler wrote: >- Binary and text-mode signatures. The PGP/MIME text > doesn't specify what to send, and actually both types > are valid and should work neatly. However, this should > be verified. From RFC2015: 2. PGP data formats PGP can generate either ASCII armor (described in [3]) or 8-bit binary output when encrypting data, generating a digital signature, or extracting public key data. The ASCII armor output is the REQUIRED method for data transfer. So binary-mode signatures are forbidden, and remain so in the new draft. -- Ian Bell T U R N P I K E Ltd Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08445 for ietf-openpgp-bks; Wed, 29 Mar 2000 14:42:03 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA08436 for ; Wed, 29 Mar 2000 14:41:58 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id ECFEF12835; Thu, 30 Mar 2000 00:43:54 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id F1D62F259; Thu, 30 Mar 2000 00:29:13 +0200 (MEST) Date: Thu, 30 Mar 2000 00:29:13 +0200 From: Thomas Roessler To: Tom Zerucha Cc: Rodney Thayer , ietf-openpgp@imc.org Subject: Re: Zerucha's OPGP? Message-ID: <20000330002913.C19932@sobolev.rhein.de> Mail-Followup-To: Tom Zerucha , Rodney Thayer , ietf-openpgp@imc.org References: <4.2.0.58.20000329055643.0234be40@216.240.42.209> <20000329165633.A27338@deimos.mw.mediaone.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <20000329165633.A27338@deimos.mw.mediaone.net>; from tz@execpc.com on Wed, Mar 29, 2000 at 04:56:33PM -0500 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tom, would you mind to check out http://cryptome.org/bernstein-bxa.org? I think you can now legally make your implementation accessible to the general public, even outside the United States, so we can use it as a reference module for some of the interoperability testing. Thanks. -- http://www.guug.de/~roessler/ Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA07777 for ietf-openpgp-bks; Wed, 29 Mar 2000 13:57:08 -0800 (PST) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA07773 for ; Wed, 29 Mar 2000 13:57:07 -0800 (PST) Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id QAA22523; Wed, 29 Mar 2000 16:59:26 -0500 (EST) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id QAA27342; Wed, 29 Mar 2000 16:56:33 -0500 Date: Wed, 29 Mar 2000 16:56:33 -0500 From: Tom Zerucha To: Rodney Thayer Cc: ietf-openpgp@imc.org Subject: Re: Zerucha's OPGP? Message-ID: <20000329165633.A27338@deimos.mw.mediaone.net> References: <4.2.0.58.20000329055643.0234be40@216.240.42.209> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.0.58.20000329055643.0234be40@216.240.42.209>; from rodney@tillerman.to on Wed, Mar 29, 2000 at 05:57:29AM -0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Mar 29, 2000 at 05:57:29AM -0800, Rodney Thayer wrote: > anyone actually found a copy of Zerucha's code lately? www.cryptography.org > seens to not have it (an 'opgp', that is) http://cryptography.org/crypto/[RANDOM]/pgp/palmopgp/ has an openssl version, though it might be a little datd. http://cryptography.org/crypto/[RANDOM]/pgp/opgp/ has the 0.99x version If anyone else wants to host it, feel free to do so. Here is a (OOPS, REVERSED) patch against 0.99x for OpenSSL 0.9.4: diff -Bbur opgp-1.0a/libopgp.doc opgp99x/libopgp.doc --- opgp-1.0a/libopgp.doc Wed Mar 29 16:45:06 2000 +++ opgp99x/libopgp.doc Mon Aug 24 01:12:01 1998 @@ -1,4 +1,4 @@ -PGPlib 1.00 Free Open PGP toolkit +PGPlib 1.00 (prerelease) Open PGP toolkit opgplib is a set of routines designed to implement OpenPGP according to the IETF specification using SSLeay and zlib. @@ -42,8 +42,7 @@ MAIN -opgp is a command line program that allows easy script (batch) access -for encryption and signature functions within the library. +opgp is a not-quite compatible version of PGP5.0. See opgp -q usage for updates, but briefly, opgp without encryption parameters will process until it gets text or a literal packet, and thus duplicates most diff -Bbur opgp-1.0a/opgplib/getkey.c opgp99x/opgplib/getkey.c --- opgp-1.0a/opgplib/getkey.c Wed Mar 29 16:44:35 2000 +++ opgp99x/opgplib/getkey.c Sat Jul 18 00:07:12 1998 @@ -186,7 +186,7 @@ continue; rsatmp->d = PGP_mpiBN(&bp); rsatmp->q = PGP_mpiBN(&bp), rsatmp->p = PGP_mpiBN(&bp); - BN_mul(temp = BN_new(), rsatmp->q, rsatmp->p, ctx); /* n=pq? */ + BN_mul(temp = BN_new(), rsatmp->q, rsatmp->p); /* n=pq? */ if (BN_cmp(temp, rsatmp->n) != 0) { RSA_free(rsatmp); BN_free(temp); diff -Bbur opgp-1.0a/opgplib/pkdec.c opgp99x/opgplib/pkdec.c --- opgp-1.0a/opgplib/pkdec.c Wed Mar 29 16:44:37 2000 +++ opgp99x/opgplib/pkdec.c Sat Jul 18 00:07:12 1998 @@ -29,13 +29,13 @@ if (j == 16 || j == 20) { u8_t cbuf[1024]; /* size of key */ BN_CTX *ctx = BN_CTX_new(); - BIGNUM *a, *b, *c = BN_new(); + BIGNUM *a, *b, *c; DH *dhkey = deckey; a = PGP_mpiBN(&bp); b = PGP_mpiBN(&bp); BN_mod_exp(a, a, dhkey->priv_key, dhkey->p, ctx); - BN_mod_inverse(c, a, dhkey->p, ctx); + c = BN_mod_inverse(a, dhkey->p, ctx); BN_mod_mul(a, c, b, dhkey->p, ctx); DH_free(dhkey), BN_clear_free(b), BN_clear_free(c), BN_CTX_free(ctx); j = BN_bn2bin(a, cbuf); diff -Bbur opgp-1.0a/opgplib/sigchk.c opgp99x/opgplib/sigchk.c --- opgp-1.0a/opgplib/sigchk.c Wed Mar 29 16:44:40 2000 +++ opgp99x/opgplib/sigchk.c Mon Aug 24 01:13:04 1998 @@ -10,10 +10,10 @@ u8_t * hash, int hlen) { BN_CTX *ctx = BN_CTX_new(); - BIGNUM *t1 = BN_new(), *t2 = BN_new(), *t3 = BN_new(), *u2 = BN_new(); + BIGNUM *t1 = BN_new(), *t2 = BN_new(), *t3 = BN_new(), *u2 = NULL; int ret; - BN_mod_inverse(u2, u1, dsakey->q, ctx); + u2 = BN_mod_inverse(u1, dsakey->q, ctx); BN_bin2bn(hash, hlen, t3); BN_mod_mul(t3, t3, u2, dsakey->q, ctx); BN_mod_mul(u2, r, u2, dsakey->q, ctx); diff -Bbur opgp-1.0a/opgplib/sigmak.c opgp99x/opgplib/sigmak.c --- opgp-1.0a/opgplib/sigmak.c Wed Mar 29 16:44:41 2000 +++ opgp99x/opgplib/sigmak.c Mon Aug 24 01:13:04 1998 @@ -62,9 +62,9 @@ BN_mod_exp(u1, ((DSA *) seckey)->g, u2, ((DSA *) seckey)->p, ctx); BN_mod(r, u1, ((DSA *) seckey)->q, ctx); /* Compute u1 = inv(u2) (t2 + xr) mod q */ - BN_mul(u1, ((DSA *) seckey)->priv_key, r, ctx); + BN_mul(u1, ((DSA *) seckey)->priv_key, r); BN_add(u1, u1, t2); - BN_mod_inverse(t1, u2, ((DSA *) seckey)->q, ctx); + t1 = BN_mod_inverse(u2, ((DSA *) seckey)->q, ctx); BN_mod_mul(u1, u1, t1, ((DSA *) seckey)->q, ctx); DSA_free(((DSA *) seckey)); } else diff -Bbur opgp-1.0a/paths.mak opgp99x/paths.mak --- opgp-1.0a/paths.mak Wed Mar 29 16:44:27 2000 +++ opgp99x/paths.mak Mon Jun 8 11:28:33 1998 @@ -1,6 +1,6 @@ SSLPATH = /usr/local/ssl LIBPATH = -L$(SSLPATH)/lib -INCLUDE = -I$(SSLPATH)/include/openssl -I$(SSLPATH)/include +INCLUDE = -I$(SSLPATH)/include CFLAGS = -Wall $(INCLUDE) -O6 -s #where to put the files Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02529 for ietf-openpgp-bks; Wed, 29 Mar 2000 09:27:42 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02524 for ; Wed, 29 Mar 2000 09:27:36 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id B19811287D; Wed, 29 Mar 2000 19:29:29 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 75032F259; Wed, 29 Mar 2000 19:29:05 +0200 (MEST) Date: Wed, 29 Mar 2000 19:29:05 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000329192904.B12300@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , ietf-openpgp@imc.org Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've started work on a suite of test messages which are intended to help verify the correctness of the receiving end of a PGP/MIME implementation. Currently, I'm using PGP 2.6.3in and RSA/MD5 for the underlying encryption and signature creation, however, this can easily be changed to a more modern version of PGP or GnuPG - the messages are generated by a shell script, which does all the MIME stuff "by hand", so no actual MUA is involved with the creation of these messages. The set of messages I have so far is quite simple. Generally, I try to poke a bit at the interaction between the MIME and PGP layers, and at crucial features which should better be present on the PGP layer if PGP/MIME should work. - Problems I encountered in the past with the interaction of MIME and PGP/MIME engines - this includes things like quotes around boundary parameters where they aren't needed and positions of parameters (I've chosen a hopefully sufficiently strange order to expose eventual bugs here; we may wish to check all permutations in the future). - Binary and text-mode signatures. The PGP/MIME text doesn't specify what to send, and actually both types are valid and should work neatly. However, this should be verified. - Trailing whitespace. I've seen this break some back-ends. - Unterminated last lines. It seems that there has been some confusion about how this should be handled in the past. Those who are interested in trying this, please have a look at: ftp://riemann.iam.uni-bonn.de/pub/users/roessler/pgpmime-interop/ This directory contains 5 files: - forms.txt is a first take at a report form. - interop.maildir.tar is a tar archive which contains a maildir folder with the 36 test messages. Essentially, this is a directory structure where every message is stored in a file of it's own. - interop.mbox is an mbox folder which contains the 36 test messages. - interop.pgp.tar contains the pubring.pgp and secring.pgp files with the key I use for testing. The pass phrase is "none". - interop.src.tar contains the shell script and a small C helper program I use to create the messages. Comments are highly welcome. Also, please notify me immediately if my script is generating illegal messages (although I hope not to do this). -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id FAA28166 for ietf-openpgp-bks; Wed, 29 Mar 2000 05:55:17 -0800 (PST) Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28162 for ; Wed, 29 Mar 2000 05:55:15 -0800 (PST) Received: from road-warrior (mg128-055.ricochet.net [204.179.128.55]) by rgate2.ricochet.net (8.9.3/8.9.3) with ESMTP id HAA24580 for ; Wed, 29 Mar 2000 07:57:31 -0600 (CST) Message-Id: <4.2.0.58.20000329055643.0234be40@216.240.42.209> X-Sender: rodney@216.240.42.209 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 29 Mar 2000 05:57:29 -0800 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Zerucha's OPGP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: anyone actually found a copy of Zerucha's code lately? www.cryptography.org seens to not have it (an 'opgp', that is) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA25796 for ietf-openpgp-bks; Wed, 29 Mar 2000 04:06:01 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA25791 for ; Wed, 29 Mar 2000 04:06:00 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aHO4-00061N-00; Wed, 29 Mar 2000 14:15:52 +0200 Date: Wed, 29 Mar 2000 14:15:52 +0200 From: Werner Koch To: ietf-openpgp@imc.org Cc: Thomas Roessler Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329141552.O20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org, Thomas Roessler References: <200003290302.TAA21182@ns.secondary.com> <20000329123135.K20405@djebel.gnupg.de> <20000329132817.L25646@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <20000329132817.L25646@sobolev.rhein.de>; from roessler@guug.de on Wed, Mar 29, 2000 at 01:28:17PM +0200 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Mar 2000, Thomas Roessler wrote: > > a) Tom Zerucha's OPGP (ftp.cryptography.org?) > > Is this, BTW, available outside the United States now? An unamed person from outside the U.S. sent me a copy some time ago. A small problem with 0.99x is that it does not link against OpenSSL. -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25713 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:59:43 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25709 for ; Wed, 29 Mar 2000 03:59:42 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aHHy-00060x-00; Wed, 29 Mar 2000 14:09:34 +0200 Date: Wed, 29 Mar 2000 14:09:34 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329140934.N20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200003282006.PAA12308@domains.invweb.net> <20000329124335.L20405@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: ; from ddt@openpgp.net on Wed, Mar 29, 2000 at 03:19:54AM -0800 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Mar 2000, Dave Del Torto wrote: > I am hoping you'll also implement our two newest drafts, OpenPGP/MIME > and OpenPGP/MIME Multipart Signatures. Both could be extremely useful > in a scriptable UNIX GnuPG version. I'll provide any low level function when needed; however everything else can be done with a little bit of scripting. -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25476 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:46:17 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25470 for ; Wed, 29 Mar 2000 03:45:44 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id A45341282F; Wed, 29 Mar 2000 13:47:38 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id EF0FAF259; Wed, 29 Mar 2000 13:45:52 +0200 (MEST) Date: Wed, 29 Mar 2000 13:45:52 +0200 From: Thomas Roessler To: Dave Del Torto Cc: Werner Koch , ietf-openpgp@imc.org, William H Geiger III Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329134552.O25646@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , Dave Del Torto , Werner Koch , ietf-openpgp@imc.org, William H Geiger III References: <200003282006.PAA12308@domains.invweb.net> <20000329124335.L20405@djebel.gnupg.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: ; from ddt@openpgp.net on Wed, Mar 29, 2000 at 03:19:54AM -0800 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-29 03:19:54 -0800, Dave Del Torto wrote: > I am hoping you'll also implement our two newest > drafts, OpenPGP/MIME and OpenPGP/MIME Multipart > Signatures. Both could be extremely useful in a > scriptable UNIX GnuPG version. I think that, for Unix use, a perl script based on, say, the MIME::Tools (3pm) package would be better suited. Everything else would mean code duplication when GnuPG is used with any reasonable Mail User Agent which has a decent MIME parser itself. -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25310 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:34:25 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25293 for ; Wed, 29 Mar 2000 03:34:07 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id 202C712799; Wed, 29 Mar 2000 13:35:50 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id 82D77F259; Wed, 29 Mar 2000 13:28:17 +0200 (MEST) Date: Wed, 29 Mar 2000 13:28:17 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329132817.L25646@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , ietf-openpgp@imc.org References: <200003290302.TAA21182@ns.secondary.com> <20000329123135.K20405@djebel.gnupg.de> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <20000329123135.K20405@djebel.gnupg.de>; from wk@gnupg.org on Wed, Mar 29, 2000 at 12:31:35PM +0200 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-29 12:31:35 +0200, Werner Koch wrote: > a) Tom Zerucha's OPGP (ftp.cryptography.org?) Is this, BTW, available outside the United States now? -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25305 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:34:23 -0800 (PST) Received: from postfix.rhein.de (postfix.rhein.de [193.175.27.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25300 for ; Wed, 29 Mar 2000 03:34:21 -0800 (PST) Received: by postfix.rhein.de (Postfix, from userid 5) id 52F8D12787; Wed, 29 Mar 2000 13:35:49 +0200 (MET DST) >Received: by sobolev.rhein.de (Postfix, from userid 200) id B70B2F259; Wed, 29 Mar 2000 13:23:54 +0200 (MEST) Date: Wed, 29 Mar 2000 13:23:54 +0200 From: Thomas Roessler To: "William H. Geiger III" Cc: Jon Callas , ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329132354.K25646@sobolev.rhein.de> Mail-Followup-To: Thomas Roessler , "William H. Geiger III" , Jon Callas , ietf-openpgp@imc.org References: <200003282006.PAA12308@domains.invweb.net> Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.1.9i In-Reply-To: <200003282006.PAA12308@domains.invweb.net>; from whgiii@openpgp.net on Tue, Mar 28, 2000 at 02:06:36PM -0600 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-28 14:06:36 -0600, William H. Geiger III wrote: > Yes but there is no reason why not to include PGP/MIME > test data. One can document that this part of the data > is for a seperate yet related RFC. Most 2440 > applications will also want to be PGP/MIME compliant. I tend to disagree. For instance, code signing with OpenPGP certainly has no use for the PGP/MIME framework. Additionally, PGP/MIME is essentially just about MIME encapsulation of PGP messages, so a test suite for this could be quite restricted, and would mostly have to handle MIME encoding issues and pitfalls, plus some playing around with micalg parameters and their effect. -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25158 for ietf-openpgp-bks; Wed, 29 Mar 2000 03:31:00 -0800 (PST) Received: from atanda.com (abel.intermag.com [209.31.7.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25154 for ; Wed, 29 Mar 2000 03:30:58 -0800 (PST) Received: from [192.168.248.7] (216.100.248.78) by atanda.com with ESMTP (Eudora Internet Mail Server 1.2.1); Wed, 29 Mar 2000 03:33:57 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <20000329124335.L20405@djebel.gnupg.de> References: <200003282006.PAA12308@domains.invweb.net> <20000329124335.L20405@djebel.gnupg.de> X-Sender: Date: Wed, 29 Mar 2000 03:19:54 -0800 To: Werner Koch From: Dave Del Torto Subject: Re: DRAFT status and Compatibility testing Cc: ietf-openpgp@imc.org, William H Geiger III 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:43 pm +0200 2000-03-29, Werner Koch wrote: >On Tue, 28 Mar 2000, William H. Geiger III wrote: > > > Most 2440 applications will also want to be PGP/MIME compliant. > >I don't think so, it is good Unix practise to do layering and MIME is >something you need in MUAs and not in an encryption tool. Werner, I am hoping you'll also implement our two newest drafts, OpenPGP/MIME and OpenPGP/MIME Multipart Signatures. Both could be extremely useful in a scriptable UNIX GnuPG version. I've asked Will Price at PGP Security if they plan to support the drafts, but I'm not sure they plan to do so. If both were interoperable, that would of course be ideal. :) dave Received: by ns.secondary.com (8.9.3/8.9.3) id CAA19316 for ietf-openpgp-bks; Wed, 29 Mar 2000 02:33:46 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA19310 for ; Wed, 29 Mar 2000 02:33:44 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aFwl-0005xa-00; Wed, 29 Mar 2000 12:43:35 +0200 Date: Wed, 29 Mar 2000 12:43:35 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329124335.L20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200003282006.PAA12308@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <200003282006.PAA12308@domains.invweb.net>; from whgiii@openpgp.net on Tue, Mar 28, 2000 at 02:06:36PM -0600 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 28 Mar 2000, William H. Geiger III wrote: > Most 2440 applications will also want to be PGP/MIME compliant. I don't think so, it is good Unix practise to do layering and MIME is something you need in MUAs and not in an encryption tool. > The second part would be the "outbound" generation of RFC 2440 packets. We > should be able to have a set of "skeleton" packets that the tester could > use for compairison while ignoring the raw data (ie MPI's) that may be It is not possible to simply compare the packets for a couple of reasons: You should have random data in it, an implemenation has several choices to encode the packet length and and the order of subpackets is not regulated. Doing some clever diffs over the output of a packet dumping tools would be possible. > different. As an example the application being tested needs to generate a > v3 RSA public key. The tests could use the "skeleton" test packet to (OpenPGP implementations SHOULD generate V4 keys (see 5.5.2)) IMHO, tTest scripts are the way to go; this is a lot of work unless we agree on a common commandline interface and each implementation comes with a wrapper for this interface. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id CAA18653 for ietf-openpgp-bks; Wed, 29 Mar 2000 02:21:47 -0800 (PST) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA18645 for ; Wed, 29 Mar 2000 02:21:45 -0800 (PST) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12aFl9-0005xB-00; Wed, 29 Mar 2000 12:31:35 +0200 Date: Wed, 29 Mar 2000 12:31:35 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Message-ID: <20000329123135.K20405@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200003290302.TAA21182@ns.secondary.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <200003290302.TAA21182@ns.secondary.com>; from lindsay@powerup.com.au on Wed, Mar 29, 2000 at 03:02:33AM +0000 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Mar 2000, Lindsay Mathieson wrote: > Is there a public freeware implementation of rfc 2440 ? I know these implementations: a) Tom Zerucha's OPGP (ftp.cryptography.org?) b) GnuPG (ftp.gnupg.org/gcrypt/gnupg) I don't know whether PGP 7 is going to implement OpenPGP correctly, at least they are using deprecated features (pubkey algos 2 and 3). -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH i.G. tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02396 for ietf-openpgp-bks; Tue, 28 Mar 2000 21:58:17 -0800 (PST) Received: from enigma.cyphers.net (IDENT:root@enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02391 for ; Tue, 28 Mar 2000 21:58:08 -0800 (PST) Received: from cyphers.net (blowfish.cyphers.net [205.178.102.84]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id WAA20791 for ; Tue, 28 Mar 2000 22:02:07 -0800 Message-ID: <38E19BF7.7FCA67D7@cyphers.net> Date: Tue, 28 Mar 2000 22:00:37 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: OpenPGP mailing list Subject: Re: DRAFT status and Compatibility testing References: <200003281619.LAA21187@domains.invweb.net> <4.2.0.58.20000328212041.00b9ece0@216.240.42.209> 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: SHA1 Rodney Thayer wrote: > > I think that products should be built with "test points" in them, > to allow such things as interoperability testing. This is how > we've had to do things in the IPsec and TLS worlds, and in other > places. I think we should be able to "dump the keys", and I > realize that means one > has to (gasp) have code that reveals the keys. IPsec and TLS are hundreds of times more complicated to interop test than OpenPGP should be. IPsec and TLS are extremely complex, OpenPGP is fairly straight forward. Dumping keys is an obscure debug scenario used to figure out why two implementations do not interop. Frankly, I expect the OpenPGP testing will have very few cases of interop failure, and that such cases will be reasonably explainable with things like "we didn't implement that optional algorithm." > On the other hand, if we run in "trust me, it's ok" mode, we're > degenerating into security by obscurity. If I were auditing an > implementation, I'd want to see the keys to validate it myself. A main part of the point I'm making is that we are NOT auditing implementations. This is not a security review for each of our products. This is an interop test. If some other product uses a session key of 0, it's not the job of the interop tests to discover that. If I can read the other guy's messages/keys and he can read mine, we're set to go. > Remember, there's nothing stopping someone from revealing the keys > anyway -- you can't inhibit someone from saving copies of their > key material, or even publishing it. So this is a previously > existing non-problem. As I said, the tests must be able to be run by any user sitting at each of our products without debug tools or special code. Going beyond that gets into a security review which is not what we're doing here. Hal Finney wrote: > I am inclined to think that traditional interoperability testing is > a better way to approach this problem. At least with openpgp we > don't all have to get together, it can all be done online. > > We would define a specific set of message/key types to create, and > everyone who wanted to participate would create messages/keys of > those types (or whatever subset they support), then everyone else > would try to read them. Thanks for the correction Hal. That sounds like an efficient approach. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 145 Alpha) iQA/AwUBOOGac6y7FkvPc+xMEQI9wgCg3OzL+yq5b4sK+OeZiQohxpwvtIAAnjob TdXKhEBO0bYmI73uRKwfjWvV =S5P6 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA01321 for ietf-openpgp-bks; Tue, 28 Mar 2000 21:21:46 -0800 (PST) Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA01310 for ; Tue, 28 Mar 2000 21:21:34 -0800 (PST) Received: from road-warrior (mg134-043.ricochet.net [204.179.134.43]) by rgate2.ricochet.net (8.9.3/8.9.3) with ESMTP id XAA21132 for ; Tue, 28 Mar 2000 23:23:42 -0600 (CST) Message-Id: <4.2.0.58.20000328212041.00b9ece0@216.240.42.209> X-Sender: rodney@216.240.42.209 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 28 Mar 2000 21:23:26 -0800 To: OpenPGP mailing list From: Rodney Thayer Subject: Re: DRAFT status and Compatibility testing In-Reply-To: <38E14D68.CA703ABC@cyphers.net> References: <200003281619.LAA21187@domains.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think that products should be built with "test points" in them, to allow such things as interoperability testing. This is how we've had to do things in the IPsec and TLS worlds, and in other places. I think we should be able to "dump the keys", and I realize that means one has to (gasp) have code that reveals the keys. On the other hand, if we run in "trust me, it's ok" mode, we're degenerating into security by obscurity. If I were auditing an implementation, I'd want to see the keys to validate it myself. Remember, there's nothing stopping someone from revealing the keys anyway -- you can't inhibit someone from saving copies of their key material, or even publishing it. So this is a previously existing non-problem. At 04:25 PM 3/28/00 -0800, Will Price wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Some of the discussion I've seen thus far has gone a bit too far it >seems. > >Proposals such as using pre-determined session keys or other >low-level crypto items may require ripping apart the software >packages being subjected to the testing and writing new code in order >to perform the test. This is not going to prove anything other than >the fact that the new code (which isn't necessarily part of the >product) enabled a piece of software to complete an obscure low-level >test, and will lengthen the testing cycle from something that could >be done in a couple of weeks to something that will likely take many >months to agree upon, design, write, perform testing, repeat. > >Any test designed to prove interoperability should adhere stricly to >the principle that interoperability between OpenPGP products is a >high-level operation basically limited to the following: > >* Public/Private Key import/export >* Encrypted and/or signed message interop in its various forms > >Things like PGP/MIME, and low-level testing of crypto algorithms are >irrelevant to this task except insofar as they have an effect on the >above two items (which for instance PGP/MIME does not -- that >document will require its own separate interop testing). We're not >doing a FIPS crypto test on every product here, we're just testing >interop of the items generated by our common products which apply >directly to RFC 2440. > >Making a test suite of messages and keys which use an array of >algorithms and variations should be a simple task any user can >perform sitting at any of our products without rewriting code, >turning on debug features, recompiling, etc... > >This set of data would be termed the OpenPGP Compatibility Suite, and >each vendor could perform the testing on their own product, submit >that to the list, and any other vendor could use that same data to >verify the results. > >- -- Will > >Will Price, Director of Engineering >PGP Security, Inc. >a division of Network Associates, Inc. > > > >-----BEGIN PGP SIGNATURE----- >Version: PGP 7.0 (Build 144 Alpha) > >iQA/AwUBOOFNMKy7FkvPc+xMEQJtdQCfTzZrTm9faAlZRfrgpSGfQjEbrqcAniGR >9NHfkzlUee6nCdrK+Nr/DrIO >=5URX >-----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21191 for ietf-openpgp-bks; Tue, 28 Mar 2000 19:02:23 -0800 (PST) Received: from enterprise.powerup.com.au (IDENT:qmailr@enterprise.powerup.com.au [203.32.8.37]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21182 for ; Tue, 28 Mar 2000 19:02:20 -0800 (PST) Message-Id: <200003290302.TAA21182@ns.secondary.com> Received: (qmail 29646 invoked from network); 29 Mar 2000 03:04:23 -0000 Received: from unknown (HELO lindsay) (203.147.172.62) by enterprise.powerup.com.au with SMTP; 29 Mar 2000 03:04:23 -0000 Date: 29 Mar 2000 3:2:33 GMT From: Lindsay Mathieson Mime-Version: 1.0 Subject: Re: DRAFT status and Compatibility testing To: ietf-openpgp@imc.org X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.8 Preview 4 Content-Transfer-Encoding: 8bit Content-Type: text/plain;charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is there a public freeware implementation of rfc 2440 ? -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.8 Preview 4, on March 29, 2000, in Win95 4.10 http://www.blackpaw.com/ Received: by ns.secondary.com (8.9.3/8.9.3) id SAA17631 for ietf-openpgp-bks; Tue, 28 Mar 2000 18:28:43 -0800 (PST) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA17625 for ; Tue, 28 Mar 2000 18:28:41 -0800 (PST) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id SAA25713 for ietf-openpgp@imc.org; Tue, 28 Mar 2000 18:31:30 -0800 Date: Tue, 28 Mar 2000 18:31:30 -0800 Message-Id: <200003290231.SAA25713@finney.org> To: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The problem with a "test suite" is that it would allow a software creator to test that his software READS openpgp compliant data, but not that it CREATES compliant data. The latter testing is more difficult because as Jon Callas pointed out there is a lot of randomness in what is created and so you can't just compare against a "known good" output. I am inclined to think that traditional interoperability testing is a better way to approach this problem. At least with openpgp we don't all have to get together, it can all be done online. We would define a specific set of message/key types to create, and everyone who wanted to participate would create messages/keys of those types (or whatever subset they support), then everyone else would try to read them. See the S/MIME page at http://www.rsasecurity.com/standards/smime/interop_center.html for an example. They did it differently by comparing with a reference implementation, but since we have only a few implementations I think it is feasible to have N by N comparisons. Hal Finney Received: by ns.secondary.com (8.9.3/8.9.3) id QAA12477 for ietf-openpgp-bks; Tue, 28 Mar 2000 16:25:53 -0800 (PST) Received: from enigma.cyphers.net (IDENT:root@enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12473 for ; Tue, 28 Mar 2000 16:25:52 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [205.178.102.83]) by enigma.cyphers.net (8.9.3/8.8.7) with ESMTP id QAA19861; Tue, 28 Mar 2000 16:29:45 -0800 Message-ID: <38E14D68.CA703ABC@cyphers.net> Date: Tue, 28 Mar 2000 16:25:12 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: John W Noerenberg II , OpenPGP mailing list Subject: Re: DRAFT status and Compatibility testing References: <200003281619.LAA21187@domains.invweb.net> 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: SHA1 Some of the discussion I've seen thus far has gone a bit too far it seems. Proposals such as using pre-determined session keys or other low-level crypto items may require ripping apart the software packages being subjected to the testing and writing new code in order to perform the test. This is not going to prove anything other than the fact that the new code (which isn't necessarily part of the product) enabled a piece of software to complete an obscure low-level test, and will lengthen the testing cycle from something that could be done in a couple of weeks to something that will likely take many months to agree upon, design, write, perform testing, repeat. Any test designed to prove interoperability should adhere stricly to the principle that interoperability between OpenPGP products is a high-level operation basically limited to the following: * Public/Private Key import/export * Encrypted and/or signed message interop in its various forms Things like PGP/MIME, and low-level testing of crypto algorithms are irrelevant to this task except insofar as they have an effect on the above two items (which for instance PGP/MIME does not -- that document will require its own separate interop testing). We're not doing a FIPS crypto test on every product here, we're just testing interop of the items generated by our common products which apply directly to RFC 2440. Making a test suite of messages and keys which use an array of algorithms and variations should be a simple task any user can perform sitting at any of our products without rewriting code, turning on debug features, recompiling, etc... This set of data would be termed the OpenPGP Compatibility Suite, and each vendor could perform the testing on their own product, submit that to the list, and any other vendor could use that same data to verify the results. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 (Build 144 Alpha) iQA/AwUBOOFNMKy7FkvPc+xMEQJtdQCfTzZrTm9faAlZRfrgpSGfQjEbrqcAniGR 9NHfkzlUee6nCdrK+Nr/DrIO =5URX -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA12072 for ietf-openpgp-bks; Tue, 28 Mar 2000 16:05:08 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA12068 for ; Tue, 28 Mar 2000 16:05:07 -0800 (PST) Received: from [169.208.192.29] (vpnap-g1-012013.qualcomm.com [10.13.12.13]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA25700; Tue, 28 Mar 2000 16:07:22 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200003281619.LAA21187@domains.invweb.net> References: <200003281619.LAA21187@domains.invweb.net> X-Mailer: Eudora [Macintosh version 4.3.1] 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: Wed, 29 Mar 2000 09:34:46 +0930 To: "William H. Geiger III" From: John W Noerenberg II Subject: Re: DRAFT status and Compatibility testing Cc: OpenPGP mailing list , "Jeffrey I. Schiller" 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 10:03 AM -0600 3/28/00, William H. Geiger III wrote: > >IMHO what we need to do is put together a suite of test data that conforms >to RFC 2440. Sounds like a good idea. We'll need some data and specifications on what the data tests. The message I proposed isn't an exhaustive test. But at least it demonstrates some level of interoperability. That's a first step. Are you volunteering to write the specs and build the test data? > >Additionally data sets should be divided into MUST, SHOULD, and OPTIONAL >catagories. First step here is to create the matrix I have in mind a la 1123. > >Testing should be done to see if the products are able to generate & >process the various packet types. > >Some of the non-RFC2440 packets should be included (X.509, PhotoID, >...ect) so vendors can test that their software can properly handle >non-RFC2440 packets without crashing (this has been a problem with the pks >software). We can bear that in mind. It certainly has impact on what we do. If there are non-2440 packets we need to consider, I'd entertain the idea of an new draft to incorporate them into 2440's successor. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- But now I know our world is no more permanent than a wave rising on the ocean. -- Arthur Golden, "Memoirs of a Geisha", 1997 ---------------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08723 for ietf-openpgp-bks; Tue, 28 Mar 2000 12:05:05 -0800 (PST) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08717 for ; Tue, 28 Mar 2000 12:04:56 -0800 (PST) Received: from whgiii.geiger.local (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id PAA12308; Tue, 28 Mar 2000 15:06:46 -0500 Message-Id: <200003282006.PAA12308@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 28 Mar 2000 14:06:36 -0600 To: Jon Callas In-Reply-To: Cc: ietf-openpgp@imc.org Subject: Re: DRAFT status and Compatibility testing X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.10a c10 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In , on 03/28/00 at 12:51 PM, Jon Callas said: >I think this is an excellent idea. 2440 is a data format standard, and >consequently, the test suite mostly should consist of data. The only real >comment I have on your list is that PGP/MIME isn't part of 2440, it's a >separate RFC. (And in my opinion, this is a feature, not a bug. It's >called layering.) Yes but there is no reason why not to include PGP/MIME test data. One can document that this part of the data is for a seperate yet related RFC. Most 2440 applications will also want to be PGP/MIME compliant. >There's a related issue that I want to bring up, though. Well I see the testing of the application as 2 part. The 1st part would be the "inbound" processing of RFC 2440 packets. I don't see any risks involved with using a fixed data set for this part of the testing. The second part would be the "outbound" generation of RFC 2440 packets. We should be able to have a set of "skeleton" packets that the tester could use for compairison while ignoring the raw data (ie MPI's) that may be different. As an example the application being tested needs to generate a v3 RSA public key. The tests could use the "skeleton" test packet to compair that all of the parts are generated and formated properly while ignoring that data contained in MPI(1) and MPI(2) is different. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA07164 for ietf-openpgp-bks; Tue, 28 Mar 2000 10:50:23 -0800 (PST) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07159 for ; Tue, 28 Mar 2000 10:50:22 -0800 (PST) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id KAA27958; Tue, 28 Mar 2000 10:52:15 -0800 (PST) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id KAA27954; Tue, 28 Mar 2000 10:52:08 -0800 (PST) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200003281619.LAA21187@domains.invweb.net> References: <200003281619.LAA21187@domains.invweb.net> Date: Tue, 28 Mar 2000 10:51:09 -0800 To: "William H. Geiger III" , ietf-openpgp@imc.org From: Jon Callas Subject: Re: DRAFT status and Compatibility testing Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: DRAFT status and Compatibility testing", shown on 3/28/00), William H. Geiger III said: >IMHO what we need to do is put together a suite of test data that conforms >to RFC 2440. > [...] >Some of the non-RFC2440 packets should be included (X.509, PhotoID, >...ect) so vendors can test that their software can properly handle >non-RFC2440 packets without crashing (this has been a problem with the pks >software). > I think this is an excellent idea. 2440 is a data format standard, and consequently, the test suite mostly should consist of data. The only real comment I have on your list is that PGP/MIME isn't part of 2440, it's a separate RFC. (And in my opinion, this is a feature, not a bug. It's called layering.) There's a related issue that I want to bring up, though. Many messages, when generated require random numbers to be used. In a non-security environment, we'd have no objections to saying, "Here are the inputs, here is the final data, make sure you generate this." Do we have an objection to saying, "With a session key of K, encrypt message M, and your result should look like R"? I don't -- I consider this to be the equivalent of a crypto test vector. On the other hand, it still gives me a small shudder, and I think this is one of those things on which gentlepersons can disagree. An alternative is to come up with a test suite where an implementation generates a message with known keys, and then writes out the session keys and signature randoms, so that they can be verified. But on this one, I don't see it's any better. The problem, as I see it, is that if an implementation has a test mode in which a random can be specified, then that's potentially a way to create a hacked version with bad or known keys. But on the other hand, if an implementation has a test mode in which the randoms can be leaked, then that's a way to make a hacked version with a covert channel. If I have to pick between one of those risks, I pick the former. On the third hand, if we just say "non serviam" to that, then we run the risk that a hacked version could pass all compliance tests and no one would know otherwise. I don't like measuring compliance when we aren't specifying the inputs, either. I think my opinion (yes, I'm tentative here) is that 2440 is a data format standard. We already have been wise enough to not get it into the whole mess of crypto engineering in it. Our goal in advancing this is to make sure that given a set of inputs, an implementation produces the proper results. Those inputs may be finished messages that must be decoded, or they may be plaintext, ciphers, randoms, etc. that should generate a fixed message. There's an engineering problem in making an implementation testable and secure. But that's a problem that the implementors have to solve. Opinions? Jon Received: by ns.secondary.com (8.9.3/8.9.3) id IAA04649 for ietf-openpgp-bks; Tue, 28 Mar 2000 08:17:10 -0800 (PST) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04645 for ; Tue, 28 Mar 2000 08:17:08 -0800 (PST) Received: from whgiii.geiger.local (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id LAA21187; Tue, 28 Mar 2000 11:19:07 -0500 Message-Id: <200003281619.LAA21187@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 28 Mar 2000 10:03:59 -0600 To: John W Noerenberg II In-Reply-To: Cc: OpenPGP mailing list , "Jeffrey I. Schiller" Subject: Re: DRAFT status and Compatibility testing X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.10a c10 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In , on 03/27/00 at 06:41 PM, John W Noerenberg II said: >Towards 1, I propose the following: We'll exchange encrypted, signed >objects exercising the various modes described in 2440. I'll keep >score, and publish the results for the WG. To participate, send me a >note with subject: IMHO what we need to do is put together a suite of test data that conforms to RFC 2440. Envelope -------- Ascii-armor PGP/MIME Algorithms ---------- Compresion Symetric encryption Public Key encryption Hash Signatures ---------- Signature Types Version 3 Version 4 -- Hashed Subpackets -- Non-Hashed Subpackets Keys ---- Private Keys Public Keys Version 3 Version 4 -- Subkeys (NOTE: This is not a complete list) Additionally data sets should be divided into MUST, SHOULD, and OPTIONAL catagories. Testing should be done to see if the products are able to generate & process the various packet types. Some of the non-RFC2440 packets should be included (X.509, PhotoID, ...ect) so vendors can test that their software can properly handle non-RFC2440 packets without crashing (this has been a problem with the pks software). IIRC someone had a partal data set available but I do not know if it is still around nor if it has been updated. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA19207 for ietf-openpgp-bks; Mon, 27 Mar 2000 16:22:14 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA19203 for ; Mon, 27 Mar 2000 16:22:13 -0800 (PST) Received: from [169.208.192.29] (vpnap-g1-012018.qualcomm.com [10.13.12.18]) by mage.qualcomm.com (8.9.3/8.9.3/1.0) with ESMTP id QAA07219; Mon, 27 Mar 2000 16:24:26 -0800 (PST) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com (Unverified) Message-Id: X-Mailer: Eudora [Macintosh version 4.3.1] 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: Tue, 28 Mar 2000 09:41:01 +0930 To: OpenPGP mailing list From: John W Noerenberg II Subject: DRAFT status and Compatibility testing Cc: "Jeffrey I. Schiller" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We've talked about moving 2440 to DRAFT for a while now. We need to do this. There are really two things we need: 1) two interoperable implementations, and 2) verification of the requirements of the protocol. Even though we're not meeting in Adelaide, I thought kicking off some interoperability testing during the week would be an IETF'ish thing to do. Towards 1, I propose the following: We'll exchange encrypted, signed objects exercising the various modes described in 2440. I'll keep score, and publish the results for the WG. To participate, send me a note with subject: OpenPGP Compatibility Test 1 with directions on where to find a public key you'd like me to use. I will send an object encrypted with the keys I have and signed with mine on Thursday, Mar 30, 1500+930, at the conclusion of the SAAG meeting. When you receive the message, decrypt the object, validate the signature, and send me back the results signed with your key. Your response needs to include: the plaintext, what algorithms were used and evidence you've validated my signature. My key is available on the MIT key server. For 2, we'll need to build a compliance matrix to verify that all the required elements of 2440 have been treated (or not). If we find features that have not been used, or are disputed, I will propose eliminating them unless resolution is desired, and found. I'll start on 2, but I'll be looking for help. Remember, the subject of the message is: OpenPGP Compatibility Test 1. I'm filtering messages by the subject to get your entry. If you don't use this subject, I might miss you. The message will go out at the end of the SAAG meeting on Thursday. best, -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- But now I know our world is no more permanent than a wave rising on the ocean. -- Arthur Golden, "Memoirs of a Geisha", 1997 ---------------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id FAA17656 for ietf-openpgp-bks; Wed, 22 Mar 2000 05:18:12 -0800 (PST) Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA17652 for ; Wed, 22 Mar 2000 05:18:11 -0800 (PST) Received: from [216.209.49.114] (HSE-Toronto-ppp93181.sympatico.ca [216.209.49.114]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id IAA14129; Wed, 22 Mar 2000 08:23:03 -0500 (EST) Mime-Version: 1.0 X-Sender: b1vihi16@pop2.sympatico.ca Message-Id: Date: Wed, 22 Mar 2000 08:17:43 -0500 To: Recipient List Suppressed:; From: Robert Guerra Subject: Fwd: [PGP-Discussion] PGP-Users List is Operational Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --- begin forwarded text Date: Wed, 22 Mar 2000 06:48:50 -0600 From: Chuck44@goin.missouri.org Subject: [PGP-Discussion] PGP-Users List is Operational From: Chuck44@goin.missouri.org Hello everyone, Dave Del Torto has announced that the new, permanent PGP Users list is officially open. This is the list that he and Fred were working on setting up when Fred disappeared. To find out more, including how to subscribe go to: http://cryptorights.org/pgp-users/ Chuck in Missouri -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.2 Comment: Digital Signatures ensure message authenticity iQA/AwUBONjH7cKdCsHMpdeSEQLeqwCgnt09VFuvjM3/EGe59izMlCigVJAAoOsH pJ3DFs8Ennum9zu6j2Ffm18M =NI1o -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA19843 for ietf-openpgp-bks; Sat, 18 Mar 2000 11:16:42 -0800 (PST) Received: from tomts3-srv.bellnexxia.net (tomts3.bellnexxia.net [209.226.175.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA19839 for ; Sat, 18 Mar 2000 11:16:39 -0800 (PST) Received: from [216.209.53.81] by tomts3-srv.bellnexxia.net (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20000318191741.IBPJ3031.tomts3-srv.bellnexxia.net@[216.209.53.81]>; Sat, 18 Mar 2000 14:17:41 -0500 Mime-Version: 1.0 X-Sender: rguerra@cryptorights.org (Unverified) Message-Id: In-Reply-To: <4.3.0.20000216114317.01b27df0@mail.well.com> References: <4.3.0.20000216114317.01b27df0@mail.well.com> Date: Sat, 18 Mar 2000 14:17:05 -0500 To: rguerra@cryptorights.org From: Robert Guerra Subject: CFP2000 Conference - PGP Keysigning Session Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi: I'll be attending the CFP2000 conference being held in Toronto the first week in April. If you are attending also, I'd like to extend an invitation to participate in the conference pgp keysigning I am organizing The conference is shaping up to be one of the primier meetings of the year and presents a unique opportunity not only personally meet the numerous key people in the field but also to extend and interweave the existing pgp global web of trust. I've set-up a web page (http://pgp.greatvideo.com) which i'll be updating latter this week with details on and about the numerous formal & informal web of trust/keysigning which i'll be organizing. If you attending the conference, I look forward to meeting you. If you'd like to exchange pgp signatures, but can't make the keysigning please let me know so I might be able to meet you ay another time. Yours Sincerely, -- --- Robert Guerra WWW Page