Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA15895 for ietf-open-pgp-bks; Sun, 30 Nov 1997 20:08:10 -0800 (PST) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA15891 for ; Sun, 30 Nov 1997 20:08:05 -0800 (PST) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id WAA15723; Sun, 30 Nov 1997 22:08:57 -0600 (CST) Received: from lax-ca69-20.ix.netcom.com(207.223.161.148) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma015419; Sun Nov 30 22:07:05 1997 Message-ID: <348237DD.36E237E3@sternlight.com> Date: Sun, 30 Nov 1997 20:06:58 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Lindsay Mathieson CC: IETF OpenPGP Subject: Re: 25 Million S/MIME Users References: <199711302348.PAA13362@mail.proper.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lindsay Mathieson wrote: > > >about its business, and has by far the most massively installed base > >on the > >Internet, > >in terms of both Netscape and Microsoft, as well as by far the > >broadest > >capital > > Ok, I'll react to this, so as to resolve one myth: > > 1. The 25 million+ installed user base of Netscape/MS counts as a user base > for S/MIME > > Bollocks - how many of those people know, care or use the S/MIME integration > in Microsoft/Netscapes Mailers. I have IE & Communicator & Netscape 3.0 > installed, but I don't use the S/MIME features in any of them. Given the > weak state of US export encryption this side of the pacific (Australia) I > doubt many people use S/MIME at all. > The point to which I was responding was "installed base". My response was accurate. If you're going to discount installed base for usage, PGP's figures must be similarly discounted. So gross or net, apples and apples, please. I suggest that pursuing this topic further is likely off-purpose for this list. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA14618 for ietf-open-pgp-bks; Sun, 30 Nov 1997 17:55:49 -0800 (PST) Received: from erebus.mcmurdo.gov (erebus-107.mcmurdo.gov [157.132.107.52]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA14605; Sun, 30 Nov 1997 17:55:37 -0800 (PST) Received: from gere (gere-106.mcmurdo.gov [157.132.106.243]) by erebus.mcmurdo.gov (8.8.5/8.8.5) with SMTP id BAA25809; Mon, 1 Dec 1997 01:54:55 GMT Message-Id: <199712010154.BAA25809@erebus.mcmurdo.gov> X-Sender: cds@pop.io.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Release Candidate 3 Date: Mon, 01 Dec 1997 01:47:54 +0000 To: david@sternlight.com, James Howard From: Chris Liljenstolpe Subject: Let it die (was: Re: David, get stuffed.) Cc: ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org In-Reply-To: <3481E360.EF324C67@sternlight.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Folks - This is not going anywhere in getting the work done on this spec. This kind of discussion is political, and, by now, is way out of the charter of these lists. There is a job to do here, and a job to do on the s/mime working group. Let's deal with the technical stuff and debate the politics later. Maybe we need a list for these discussions, say: mail-crypto-sniveling Chris At 1997-11-30 22:06 , David Sternlight wrote: > > >James Howard wrote: > >> Please take your borderline paranoia and correspondence-school >> legalese back to the alt groups where it belongs. Your continued >> posts to this list under forged headers is simply the icing on the cake. > >I do not post under forged headers and any charge I do so is a lie. > >David > mailto: cds@io.com http://www.io.com/~cds "If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home from us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you. May your chains set lightly upon you; and may posterity forget that ye were our countrymen." -- Samuel Adams Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA14535 for ietf-open-pgp-bks; Sun, 30 Nov 1997 17:46:15 -0800 (PST) Received: from server1.efga.org (anon@server1.efga.org [207.15.209.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA14531; Sun, 30 Nov 1997 17:46:10 -0800 (PST) Received: (from anon@localhost) by server1.efga.org (8.8.5/8.8.5) id UAA22350; Sun, 30 Nov 1997 20:48:59 -0500 Date: Sun, 30 Nov 1997 20:48:59 -0500 Message-ID: <2a09d92b722183c08607107eb8ebe78f@anon.efga.org> From: Anonymous Comments: This message did not originate from the Sender address above. It was remailed automatically by anonymizing remailer software. Please report problems or inappropriate use to the remailer administrator at . To: ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Stupid lying forger David Sternlight wrote: >James Howard wrote: > >> Please take your borderline paranoia and correspondence-school >> legalese back to the alt groups where it belongs. Your continued >> posts to this list under forged headers is simply the icing on the cake. > >I do not post under forged headers and any charge I do so is a lie. Stupid lying forger David Sternlight is lying again, as usual. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA14024 for ietf-open-pgp-bks; Sun, 30 Nov 1997 16:52:15 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA14019 for ; Sun, 30 Nov 1997 16:52:10 -0800 (PST) Received: from s20.term1.sb.rain.org (s01.term2.sb.rain.org [198.68.144.161]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id QAA10983 for ; Sun, 30 Nov 1997 16:55:12 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id NAA02181 for ietf-open-pgp@imc.org; Sun, 30 Nov 1997 13:32:14 -0800 Date: Sun, 30 Nov 1997 13:32:14 -0800 From: Hal Finney Message-Id: <199711302132.NAA02181@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: expedience, consensus and editing Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ned Freed, , writes: > Existing facilities can be used to do detached MIME signaturues. Specifically, > one constructs a message/external-body MIME object that contains a > content-md5 field describing the external data. One then signs this > part. The result is a detached signature that also contains a pointer > to the actual data which has been signed. Yes, this is similar to a PGP detached signature. For some applications, it is superior since it includes a direct reference to the data being signed. However although it is functionally similar it is not a MIME encoding of a PGP detached signature. As I wrote earlier, PGP/MIME can be thought of as an alternative protocol to PGP, with similar functionality but different ways of achieving it. > If you don't want the pointer then the right answer is to define a > MIME type for a existing PGP detached signature object. Yes, and likewise we could define MIME types for other PGP objects, like binary signed objects. I wonder if it wouldn't make more sense though to define a general MIME type for a base64 encoded PGP object. This would ***NOT*** be an alternative or replacement for PGP/MIME. That protocol is used to protect MIME body parts, and would still be the protocol of choice for email and similar appliations. This proposal would simply be a transport layer for a binary PGP message. It would be an alternative/replacement for PGP's existing ascii armor. We'd add a couple of parameters to encode the small amount of data we currently have in the ascii armor headers and header line. Something like: Content-Type: application/pgp; pgp-data-type="SIGNATURE"; pgp-version="PGP for Personal Privacy 5.0" Content-Transfer-Encoding: base64 iQA/AwUBNIHX9cDh8jnv1nHwEQKPigCfe+AIn3e7ij8BG6UYFhCHXaIJZZ4An3Ad bZC17Lo0/Yt/GH02/lVgDTYD The pgp-data-type represents the data from the normal "-----BEGIN PGP" line. It could be "SIGNATURE", "MESSAGE", "PUBLIC KEY BLOCK", or whatever others get defined. The pgp-version has the version info from the PGP ascii armor. We could have a pgp-comment as well. (Including "PUBLIC KEY BLOCK" would mean that this would subsume the application/pgp-keys content type from RFC2015.) Then we have the base64 encoded PGP data, just like in a regular ascii armor block, except that we don't have a checksum. Application/pgp had been considered and rejected for PGP/MIME, because they wanted to exploit the MIME security multiparts from RFC1847. I think that is a good decision for that purpose. Having solved that (modulo improvements) there still may be a role for a simple transfer encoding to allow transport of general PGP objects. It would even be possible to translate between the ascii armor format and this encoding, except for the checksum. (We could think about making the checksum be an additional optional parameter.) This would allow MIME compliant mail readers to automatically launch PGP on messages containing PGP objects. Hal Finney hal@pgp.com hal@rain.org -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNIHbUsDh8jnv1nHwEQLHlQCgkHXdb/XNy5k/Pl02LtQXn+cx2MYAoJ4z o+aIj47UCChStXyYatvO6SvC =AjNX -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13466 for ietf-open-pgp-bks; Sun, 30 Nov 1997 15:57:54 -0800 (PST) Received: from dfw-ix3.ix.netcom.com (dfw-ix3.ix.netcom.com [206.214.98.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13449; Sun, 30 Nov 1997 15:57:31 -0800 (PST) Received: (from smap@localhost) by dfw-ix3.ix.netcom.com (8.8.4/8.8.4) id RAA09766; Sun, 30 Nov 1997 17:55:03 -0600 (CST) Received: from lax-ca66-25.ix.netcom.com(207.223.161.89) by dfw-ix3.ix.netcom.com via smap (V1.3) id rma009760; Sun Nov 30 17:54:42 1997 Message-ID: <3481FCBD.80FD4F68@sternlight.com> Date: Sun, 30 Nov 1997 15:54:53 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Gunther Schadow CC: crocker@cybercash.com, galvin@tis.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, murphy@tis.com, ned@innosoft.com Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? References: <199711302241.XAA02114@nepumuk.ether.schadow.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gunther Schadow wrote: > > Sorry for the massive cross-post, I just didn't know which e-mail list > David's reply came about... It was posted to all the groups your original post went to. I simply did a "reply" in my mailer. ;-) > First I'll summarize your points: (more like labelling, but let's assume readers are following this thread.) > > 1. The "userbase" > > 2. Trust "algorithms" > > 3. Either has "unique" advantages > > 4. Intellectual "property" > > 5. The "gift model" no longer holds today > > > Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge > > RSA-key PGP user base in free version 5.53, along with the web of > > signatures built up over several years. Again--never mind; the Open PGP > > working group must simply insure that that cannot happen again with Open > > PGP. > > 6. David, you are obviously from the S/MIME camp, and you keep > fighting against PGP, even though I did not raise my voice for PGP > vs. S/MIME. There is a misunderstanding to my open letter. I am a user of both. I was one of the first users of PGP until I found it infringed. I then mounted a campaign behind the scenes (I wasn't looking for credit, and I wasn't the only one) with Bidzos to license RSA for PGP. In the event, Phil's intransigence (see Garfinkel's book) got in the way for a very long time, but this wasn't because of any lack of my efforts, Eric Hughes' efforts, or the goodwill of Jim Bidzos (see Garfinkel). When MIT PGP came out as street-legal I was one of the first users, and both Jeff Schiller and Derek Atkins signed my key. I have also helped beta test various versions, including two US/Canada ones and FileCrypt. I find each of PGP and S/MIME-X509-Netscape/Explorer have their unique and non-substituable uses, mainly revolving around distinctions between their trust models. As for your claim that you weren't raising your voice for PGP, if you reread your post perhaps you will see why I thought in places you were. Never mind--it's not worth sidetracking a discussion of principles and objectives for that. > > 7. Either standards are not a reduction of choice and optionality, or > you are against the standardization. There are two distinct trust models and systems involved. Each has a non-substitutable and important place. Thus two standards are appropriate and a reductionist argument isn't. Such cases are common in standards work. Eventually the marketplace may choose one over the other, or each may be viable for its purpose. We're not writing the Decalogue here. > > If yor S/MIME has the "user base" and is self sufficient in that, why > are you seeking for the blessings of being called an Internet > standard? It sounds to me as if you're arguing It is probably an abuse > of the term "standard" not being an end in itself but a marketing tool. Do you have a question about substance here rather than an accusation? > > > > I have a strong personal distaste with S/MIME, as the PKCS specs > > > require ASN.1, X500 and other OSI stuff that does not merge very well > > > with the rest of the Internet infrastructure. > > > > Like the bumblebee, S/MIME is out there in millions (well over 25 million) > > of installed base copies of Netscape and Explorer. Perhaps if there is a > > problem with the "internet infrastructure" it is that which needs > > adjustment. > > What I meant by "infrastructure" is design and technology. The IETF > has early enough opened itself up to OSI concepts and ASN.1. However, > these keep to not really fit into the rest of the internet > infrastructure. One good example is that X500 needed LDAP to be > deployed within the Internet infrastructure. Sounds like you're arguing for some combination of the status quo and the easy way out. > > > Thus far I've not heard of the Internet crashing down because > > of the particular crypto protocols in, say, Netscape. There are far more > > I am not talking about crashes -- these happened to me back in the > times when I used "userbase" and "marketplace" software :-). I am > talking about interoperability on an open an equal basis. I speak your > language, you speak mine. Esperanto has not caught on in the marketplace, and for good reason. > most innovations have been achieved by governamntal funding and *not* > on industry on a competitional basis. That isn't accurate. "Some" would be more apt. But you weren't arguing for that in any case, since government funding for the Internet is mostly over. You were arguing for the free "gift" model rather than the intellectual property model. > > There is not much to be > theoretically developed in security today, all knowledge is there for > more than ten years. I leave that statement for readers to contemplate, with my jaw hanging down in amazement. >The problem is deployment. Companies seem to be > too involved with patent rights and marketing that they are unable to > deploy knowledge and standards that do exist since many many > years. That's also one for the readers to consider. Hint--there are well over 25 million copies of complete mail/news/browser software packages deployed using S/MIME, and more copies are downloaded by the day--at a massive rate heretofore not seen. > > > 2. Trust "algorithms" > > PGP is already on its way towards trusted third parties. And it is > useful. Conversely, I have heard S/MIME and SSL to be used without > real TTPs, but with a locally base of certificates. You are right, > both methods have its uses. But you are badly wrong in pointing out > that both methods require mutually non-interoperable software. I didn't say "require". I said each trust model would become corrupted if it attempted to encompass the other. > > 3. Either has "unique" advantages > > see above. If they had, why not listing them and join all advantages > into one standard? Perhaps I should have said "unique and mutually exclusive" to drive the point home, though I thought I had done that with my examples. For instance it is mutually exclusive to allow anyone to be a signer and to allow only those meeting certain standards to be signers. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13372 for ietf-open-pgp-bks; Sun, 30 Nov 1997 15:48:36 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA13364 for ; Sun, 30 Nov 1997 15:48:26 -0800 (PST) Message-Id: <199711302348.PAA13364@mail.proper.com> Received: (qmail 28881 invoked from network); 30 Nov 1997 23:49:55 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 30 Nov 1997 23:49:55 -0000 Date: 1 Dec 1997 0:39:56 GMT From: Lindsay Mathieson Subject: Re: expedience, consensus and editing To: Hal Finney , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > For example, I could request that someone send me a signature >on some data I received earlier. They could create a signature on >the >data and send it to me, without having to re-send the data itself. My mistake, I see what you mean now. That would be very useful for software distribution - perhaps a mime type as for certifcate distribution would be useful, e.g. Content-Type: application/pgp-signature -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on December 1, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13371 for ietf-open-pgp-bks; Sun, 30 Nov 1997 15:48:32 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA13362 for ; Sun, 30 Nov 1997 15:48:23 -0800 (PST) Message-Id: <199711302348.PAA13362@mail.proper.com> Received: (qmail 28868 invoked from network); 30 Nov 1997 23:49:52 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 30 Nov 1997 23:49:52 -0000 Date: 1 Dec 1997 0:39:56 GMT From: Lindsay Mathieson Subject: 25 Million S/MIME Users To: IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >about its business, and has by far the most massively installed base >on the >Internet, >in terms of both Netscape and Microsoft, as well as by far the >broadest >capital Ok, I'll react to this, so as to resolve one myth: 1. The 25 million+ installed user base of Netscape/MS counts as a user base for S/MIME Bollocks - how many of those people know, care or use the S/MIME integration in Microsoft/Netscapes Mailers. I have IE & Communicator & Netscape 3.0 installed, but I don't use the S/MIME features in any of them. Given the weak state of US export encryption this side of the pacific (Australia) I doubt many people use S/MIME at all. I doubt their is a high take of S/MIME in the US either. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on December 1, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA12878 for ietf-open-pgp-bks; Sun, 30 Nov 1997 14:38:11 -0800 (PST) Received: from Mail.ZEDAT.FU-Berlin.DE (mail.zedat.fu-berlin.de [160.45.2.8]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA12874; Sun, 30 Nov 1997 14:38:05 -0800 (PST) Received: by Mail.ZEDAT.FU-Berlin.DE (Smail3.2.0.98) from nepumuk.ether.schadow.net (160.45.216.109) with esmtp id ; Sun, 30 Nov 1997 23:38:13 +0100 (MET) Received: (from gunther@localhost) by nepumuk.ether.schadow.net (8.8.5/8.6.12) id XAA02114; Sun, 30 Nov 1997 23:41:54 +0100 (MET) Date: Sun, 30 Nov 1997 23:41:54 +0100 (MET) From: Gunther Schadow Message-Id: <199711302241.XAA02114@nepumuk.ether.schadow.net> To: david@sternlight.com Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Cc: crocker@cybercash.com, galvin@tis.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, murphy@tis.com, ned@innosoft.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Sorry for the massive cross-post, I just didn't know which e-mail list David's reply came about... > > I am a member of a EDI standards organization currently preparing a > > recommendation for their members on applying Internet E-Mail > > standards. Of course, security is a major issue here. Our observation > > is that the field is everything else than clear while PGP and S/MIME > > camps are fighting each other. First I'll summarize your points: > Actually, my perception is somewhat different. It is that S/MIME is > simply going about its business, and has by far the most massively > installed base on the Internet, in terms of both Netscape and > Microsoft, as well as by far the broadest capital investment, in 1. The "userbase" > terms of its consortium. I use both, think each has its place, and > think the difference is in trust algorithms. I believe each trust > algorithm has important uses and neither should try to subsume the > other because it will lose unique advantages for the things it is > well suited. 2. Trust "algorithms" 3. Either has "unique" advantages > My own observation is that most such conflicts (other than religious wars) > stem from the unwillingness on the part of PGP fans to acknowledge that > S/MIME involves intellectual property--a fact--which is entitled to a fair > return. This is most odd, since PGP is also a commercial product which is > sold in the marketplace. 4. Intellectual "property" > There is also a deeper issue involved. The Internet was originally built > with a significant component of the "gift" model. Software was free for the > taking, and a rich uncle, the US taxpayer, provided for much that had to be > paid for. This is no longer the case, and > the Internet is well and truly a free-market commercial proposition > although some users are subsidized to this day, mostly academics and > students. It is exactly these users who seem most vociferous about "free". > This is both inappropriate and maladaptive. 5. The "gift model" no longer holds today > Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge > RSA-key PGP user base in free version 5.53, along with the web of > signatures built up over several years. Again--never mind; the Open PGP > working group must simply insure that that cannot happen again with Open > PGP. 6. David, you are obviously from the S/MIME camp, and you keep fighting against PGP, even though I did not raise my voice for PGP vs. S/MIME. There is a misunderstanding to my open letter. > > As much as I am confident > > in the IETF to stick to its former policy propagating open, freely > > available, simple and effective standards, I am nevertheless concerned > > that industry is on the edge to do a lot of harm in that field. It > > seems already that the "Internet Mail Consortium" will have a strong > > impact in IETF standardization, and as the IMC is an industry > > consortium, is not committed to the IETF policy. > > One must face the reality of both existence and choice in the marketplace. 7. Either standards are not a reduction of choice and optionality, or you are against the standardization. If yor S/MIME has the "user base" and is self sufficient in that, why are you seeking for the blessings of being called an Internet standard? It is probably an abuse of the term "standard" not being an end in itself but a marketing tool. > > I have a strong personal distaste with S/MIME, as the PKCS specs > > require ASN.1, X500 and other OSI stuff that does not merge very well > > with the rest of the Internet infrastructure. > > Like the bumblebee, S/MIME is out there in millions (well over 25 million) > of installed base copies of Netscape and Explorer. Perhaps if there is a > problem with the "internet infrastructure" it is that which needs > adjustment. What I meant by "infrastructure" is design and technology. The IETF has early enough opened itself up to OSI concepts and ASN.1. However, these keep to not really fit into the rest of the internet infrastructure. One good example is that X500 needed LDAP to be deployed within the Internet infrastructure. > Thus far I've not heard of the Internet crashing down because > of the particular crypto protocols in, say, Netscape. There are far more I am not talking about crashes -- these happened to me back in the times when I used "userbase" and "marketplace" software :-). I am talking about interoperability on an open an equal basis. I speak your language, you speak mine. That is O.K. Any ideolect for the sake of "intellectual property" (what a term after all!) is impeding interoperability. You raised the points about RC2 elsewhere. And, was it you, who used the term "fascist" for the people who claim that internet standards be openly specified and freely useable from that specification? (If it was not you, it was an other David -- but your points where so similar) > Actors are entitled to a return from their investment in intellectual > property. In this case the ultimate beneficiary are the assignees of the > inventors, e.g. MIT. You are appealing to a model here which has long been > discredited as a basis for the stimulation and preservation of innovation.. Oops? I think I am hearing wrong. "A model which has long been discredited as a basis for the stimulation and preservation of innovation". Now tell me, who invented the Internet that Microsoft is so proud of today (at last, once they became aware of it)? It was developed at universities, funded by DARPA. This is why I think that most innovations have been achieved by governamntal funding and *not* on industry on a competitional basis. Think of the NASA for an other example. But back to the internet. Tell me, who invented it? Industry was in fact not really interested in it before some Physicists at CERN (again a governmentally founded research organization) invented the WWW. The industry discovered the WWW as a perfect marketing tool, and helped spread the HTTP/TCP/IP as the most important informational revolution since the Television. But did they add any technological benefit to these protocols? Tell me? So how can you say that anything else "discredits" itself as a basis for innovation? I have been repeatedly frustrated by the intellectual poorness of software industry, and I would long have quit informatics if there was not the other side: inspiring researchers that live the freedom of speech and intellectual sharing! > It was RSADSI who, in effect, brought RSA and many other algorithms to the > marketplace, including two used in PGP. Similarly, it was IDEA which also > (as a commercial product via ASCOM AG) contributed to PGP. RSA Laboratories > continues to be one source for much of the world's crypto research outside > of government. That isn't an eelymosynary gift but must ultimately draw on First of all it was not RSADSI. It was Rivest, Shamir and Adleman, who worked at MIT founded by governmental grants (a fact that -- in your voice -- should discredit the innovative nature of the RSA algorithm). As much as five (5!) years later, the patent was claimed. This patent was then sold to RSADSI. Since then, RSADSI together with US crypto legislation and NSA is effectively fighting against the wide spread use of security standards in the name of some "intellectual property" (and anti-kommunist paranoia at the side of US govt. and NSA). It is the scandal that the discovery of asymmetric ciphers is only about 10 years olter than that of packet switched networking. While the latter succeeded revolutionizing the informational world, the world of security still suffers from the new advocates of the "intellectual property" construct. > payment for intellectual property. The notion that the Internet should use > only free crypto is a guaranteed formula to kill such innovation except in > the glacial corridors of academe, and force the successful commercial > actors to "tunnel" rather than benefitting the entire net. And even those > magisterial academic confines lead to things like RSA and RSADSI; to patent > licensing and charging for intellectual property. This is rubbish, and you know it. There is not much to be theoretically developed in security today, all knowledge is there for more than ten years. The problem is deployment. Companies seem to be too involved with patent rights and marketing that they are unable to deploy knowledge and standards that do exist since many many years. This is the kind of "anti-innovative" behavior that is discrediting the software industry as being oriented towards commerce, profit at first, and not towards intellectual innovations, not even towards their user's needs: as interoperability is one of the most important user-need being sacrificed for the sake of "intellectual property". > Of course if you want guaranteed old technology, don't use anything until > the patent has expired. Diffie-Hellman is luckily out of that margin. It is good old technology! > that was in fact my main point. But you seem to love fighting against PGP. So, here goes ... > > Why don't they sit together, listing their > > I believe this would be a major blunder. Boy, can you explain me how in the world reconciliation can ever be a blunder? The "world of difference" is speaking here. I would stop here, did I not start with listing your arguments in a few points. 1. The "userbase" The userbase that you cite comes easily by having Netscape and Microsoft select S/MIME. But don't ask how many S/MIME installations do exist, but how many of them are actually *used*. I'd be interested in a good statistics that compares actual *users* not posessors of S/MIME vs. PGP software. 2. Trust "algorithms" PGP is already on its way towards trusted third parties. And it is useful. Conversely, I have heard S/MIME and SSL to be used without real TTPs, but with a locally base of certificates. You are right, both methods have its uses. But you are badly wrong in pointing out that both methods require mutually non-interoperable software. The interesting point is that the only real algorithmical difference between traditional PGP vs. RSADSI was the use of IDEA vs. RC4. MOSS -- here I am at my point -- shows clearly how easy it is to just use these algorithms at will in a modular and interoperable way. They are both so similar and the differences are so ridiculously unimportant that it is a scandal that there is no common open Internet security standard yet. 3. Either has "unique" advantages see above. If they had, why not listing them and join all advantages into one standard? It is blunder? It is the only intellectual work that is missing in the field. See how the world suffers from commerce which is obviously unable to bring this little reconciliation while loosing the slight "difference" which they are all so proud of. 4. Intellectual "property" It is a term that has to be discussed. But not now. The interesting point is to study the intellectual revolution that spread from the invention of Gutenberg's technology to spread ideas and compare it with the recently raised issue of "property". Ridicoulous if Einstein, Heisenberg, Zuse, Watson, or whoever you name, had insist on their "intellectual property". 5. The "gift model" no longer holds today I showed you the opposit above. Again tell me, who invented the internet and what did "the industry" do about it? 6. David, you are obviously from the S/MIME camp, and you keep fighting against PGP, even though I did not raise my voice for PGP vs. S/MIME. There is a misunderstanding to my open letter. My claim was to preach reconciliation on an open basis. I am sorry for this thread to fall into a flamewar. regards -Gunther Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin. gusw@zedat.fu-berlin.de http://userpage.fu-berlin.de/~gusw ----------------------------------#include ----------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA12695 for ietf-open-pgp-bks; Sun, 30 Nov 1997 14:05:51 -0800 (PST) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA12686; Sun, 30 Nov 1997 14:05:45 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id QAA26661; Sun, 30 Nov 1997 16:06:41 -0600 (CST) Received: from lax-ca66-25.ix.netcom.com(207.223.161.89) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma026650; Sun Nov 30 16:06:29 1997 Message-ID: <3481E360.EF324C67@sternlight.com> Date: Sun, 30 Nov 1997 14:06:34 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: James Howard CC: ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org Subject: Re: David, get stuffed. References: Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk James Howard wrote: > Please take your borderline paranoia and correspondence-school > legalese back to the alt groups where it belongs. Your continued > posts to this list under forged headers is simply the icing on the cake. I do not post under forged headers and any charge I do so is a lie. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA12190 for ietf-open-pgp-bks; Sun, 30 Nov 1997 13:14:58 -0800 (PST) Received: from rtp1.intrex.net (rtp1.intrex.net [209.42.192.253]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA12185; Sun, 30 Nov 1997 13:14:53 -0800 (PST) Received: from BOX1.none (unverified [209.42.199.241]) by rtp1.intrex.net (EMWAC SMTPRS 0.83) with SMTP id ; Sun, 30 Nov 1997 16:16:31 -0500 Message-ID: X-Sender: jbhoward@rtp1.intrex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Release Candidate 3 Date: Sun, 30 Nov 1997 16:16:01 -0500 To: ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org From: James Howard Subject: David, get stuffed. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Please take your borderline paranoia and correspondence-school legalese back to the alt groups where it belongs. Your continued posts to this list under forged headers is simply the icing on the cake. You refuse to acknowledge that people simply dont give a rat's ass about what you have to say, and now you're making an effort to render our sternlight-filters inoperable. The only other group to use such tactics are the bulk-emailers. Nice company you're keeping. You've said it all before. We understand your position. You think it is perfectly OK that the underlying crypto routines used throughout the net should be required to pay RSA a royalty. This group does not. There is no middle ground in this argument, so why waste your breath trying to convince us? Please, and I mean this in the nicest possible way, get the hell out of here and don't come back. cheers, james Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA12154 for ietf-open-pgp-bks; Sun, 30 Nov 1997 13:10:36 -0800 (PST) Received: from dfw-ix12.ix.netcom.com (dfw-ix12.ix.netcom.com [206.214.98.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA12150 for ; Sun, 30 Nov 1997 13:10:32 -0800 (PST) Received: (from smap@localhost) by dfw-ix12.ix.netcom.com (8.8.4/8.8.4) id PAA28956 for ; Sun, 30 Nov 1997 15:11:29 -0600 (CST) Received: from lax-ca66-25.ix.netcom.com(207.223.161.89) by dfw-ix12.ix.netcom.com via smap (V1.3) id rma028947; Sun Nov 30 15:11:06 1997 Message-ID: <3481D665.513845CA@sternlight.com> Date: Sun, 30 Nov 1997 13:11:09 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: Helpful References: <199711301533.HAA28177@sirius.infonex.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk An anonymous coward forwarded a discussion from another newsgroup to the Open PGP mailing list in an attempt to inflame the discussion here. The comments were in the context of the discussion and tone in the newsgroups to which they were originally posted, but are both inflammatory and off-topic for the style and tone of the Open PGP mailing list. I ask readers to disregard it, though the issues of concern may be appropriate to another venue. David Mix wrote: > Subject: Re: RSA Blows Standards (S/MIME) Smoke > From: david@sternlight.com (David Sternlight) > Date: 1997/11/06 > Message-ID: > Newsgroups: alt.security.pgp,comp.security.pgp.discuss,alt.security,talk.politics.crypto,alt.privacy > > In article <63t0q3$rkq@clarknet.clark.net>, gsh@clark.net (Greg Hennessy) wrote: Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12021 for ietf-open-pgp-bks; Sun, 30 Nov 1997 12:59:13 -0800 (PST) Received: from archduke.torgo.net (archduke.torgo.net [207.229.134.19]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA12017 for ; Sun, 30 Nov 1997 12:59:07 -0800 (PST) Received: from zug.li by archduke.torgo.net (AppleShare IP Mail Server 5.0.1) id 54801 via TCP with SMTP; Sun, 30 Nov 1997 15:01:23 -0600 Message-Id: <3.0.3.32.19971130150012.006dbe94@schloss.li> X-Sender: unicorn@schloss.li X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 30 Nov 1997 15:00:12 -0600 To: ietf-open-pgp@imc.org From: Black Unicorn Subject: Re: Helpful In-Reply-To: <199711301533.HAA28177@sirius.infonex.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>If RSADSI chooses to release RC2 because they think the benefit of >>having S/MIME be an internet standard outweighs the benefit of having >>RC2 be a trade secret, that is RSADSI's decision to make. >> >>They can continue to push S/MIME without being an internet standard. > >You are flying in the face of many years of court rulings on such topics >as country club discrimination. Think it through. Oh, please. Return the law degree you got from your box of frosted flakes, please. You are making a mockery even of that. I can see I'm going to have to beef up my Sternlight filter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA11928 for ietf-open-pgp-bks; Sun, 30 Nov 1997 12:52:11 -0800 (PST) Received: from dfw-ix1.ix.netcom.com (dfw-ix1.ix.netcom.com [206.214.98.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA11901; Sun, 30 Nov 1997 12:51:06 -0800 (PST) Received: (from smap@localhost) by dfw-ix1.ix.netcom.com (8.8.4/8.8.4) id OAA20658; Sun, 30 Nov 1997 14:48:09 -0600 (CST) Received: from lax-ca66-25.ix.netcom.com(207.223.161.89) by dfw-ix1.ix.netcom.com via smap (V1.3) id rma020527; Sun Nov 30 14:47:27 1997 Message-ID: <3481D0C8.2259A24D@sternlight.com> Date: Sun, 30 Nov 1997 12:47:12 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Gunther Schadow CC: crocker@cybercash.com, galvin@tis.com, murphy@tis.com, ned@innosoft.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, mime-msp@imc.org Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? References: <199711301339.OAA28260@nepumuk.ether.schadow.net> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gunther Schadow wrote: > TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY. > > I am a member of a EDI standards organization currently preparing a > recommendation for their members on applying Internet E-Mail > standards. Of course, security is a major issue here. Our observation > is that the field is everything else than clear while PGP and S/MIME > camps are fighting each other. Actually, my perception is somewhat different. It is that S/MIME is simply going about its business, and has by far the most massively installed base on the Internet, in terms of both Netscape and Microsoft, as well as by far the broadest capital investment, in terms of its consortium. I use both, think each has its place, and think the difference is in trust algorithms. I believe each trust algorithm has important uses and neither should try to subsume the other because it will lose unique advantages for the things it is well suited. My own observation is that most such conflicts (other than religious wars) stem from the unwillingness on the part of PGP fans to acknowledge that S/MIME involves intellectual property--a fact--which is entitled to a fair return. This is most odd, since PGP is also a commercial product which is sold in the marketplace. There is also a deeper issue involved. The Internet was originally built with a significant component of the "gift" model. Software was free for the taking, and a rich uncle, the US taxpayer, provided for much that had to be paid for. This is no longer the case, and the Internet is well and truly a free-market commercial proposition although some users are subsidized to this day, mostly academics and students. It is exactly these users who seem most vociferous about "free". This is both inappropriate and maladaptive. As I understand it, the real Internet policy about intellectual property is NOT "unencumbered" but rather something like "'freely available on non-discriminatory--or perhaps "reasonable"--terms"'. Internet policy is supposed to be (if my understanding is correct) "intellectual property neutral" and not hostile to intellectual property. If that is correct, much recent pressure on RSADSI with respect to S/MIME was from a few small actors with loud voices throwing their Internet weight around. Never mind--we now have an S/MIME 3 working group with certain ground rules and that's where we're proceeding from. Similarly, we've seen the sight of PGP Inc. disenfranchinsing a huge RSA-key PGP user base in free version 5.53, along with the web of signatures built up over several years. Again--never mind; the Open PGP working group must simply insure that that cannot happen again with Open PGP. > Unfortunately, marketing interests > seem to play the major role in that fight. I have observed this entirely as: 1. Attempts to restrict S/MIME intellectual property and disadvantage RSADSI and 2. Attempts to tilt the playing field to the advantage of PGP Inc. by taking advantage of the fact that originally PGP had little intellectual property of its own but used the intellectual property of others and some of that intellectual property of others has now come off patent protection. 3. Attempts to make wrong the actions of RSADSI in protecting their intellectual property and pursuing their legal right to insure that licensees honor their agreements. From my perspective it has looked like a crooked dice game. When the above is brought to attention, we often see ad hominem responses indicative of the weaknesses of those proponents' intellectual positions. > As much as I am confident > in the IETF to stick to its former policy propagating open, freely > available, simple and effective standards, I am nevertheless concerned > that industry is on the edge to do a lot of harm in that field. It > seems already that the "Internet Mail Consortium" will have a strong > impact in IETF standardization, and as the IMC is an industry > consortium, is not committed to the IETF policy. One must face the reality of both existence and choice in the marketplace. The IMC represents successful actors in that marketplace. Some of the smaller ones support PGP but the most successful support S/MIME. The largest supporter of PGP in that group is Qualcomm and if you strip out their non-crypto business they are relatively small. Thus complaints about the IMC read like more pro-PGP partisanship. The facts are that Ford, GM, and Toyota make the cars, not MIT or DeLorean, and any realistic standard has to take account of what is out there in the marketplace. An attempt to impose the desires of a small self-appointed elite is doomed to fail under the current massively public Internet model. > I have a strong personal distaste with S/MIME, as the PKCS specs > require ASN.1, X500 and other OSI stuff that does not merge very well > with the rest of the Internet infrastructure. Like the bumblebee, S/MIME is out there in millions (well over 25 million) of installed base copies of Netscape and Explorer. Perhaps if there is a problem with the "internet infrastructure" it is that which needs adjustment. Thus far I've not heard of the Internet crashing down because of the particular crypto protocols in, say, Netscape. There are far more serious threats to worry about. My fear of S/MIME creating problems for "the rest of the internet infrastructure" is 47th on my list of fears, just below the fear of aliens taking over my computer. I do not mean to make light of your concerns, but given the huge installed base of S/MIME applications out there now, some acknowledgement of the realities of the marketplace is in order. > Of course the use of > patent encumbered algorithms is a deleterious "feature" of S/MIME -- > this also shows whose only real interest Here you move from a laudable discussion of principles and objectives to the imputation of motives and make-wrong. It does not add to the discussion. > it is to have S/MIME. It is > not common sense, it is the profit of one company: RSA Data Security, > Inc. Actors are entitled to a return from their investment in intellectual property. In this case the ultimate beneficiary are the assignees of the inventors, e.g. MIT. You are appealing to a model here which has long been discredited as a basis for the stimulation and preservation of innovation.. It was RSADSI who, in effect, brought RSA and many other algorithms to the marketplace, including two used in PGP. Similarly, it was IDEA which also (as a commercial product via ASCOM AG) contributed to PGP. RSA Laboratories continues to be one source for much of the world's crypto research outside of government. That isn't an eelymosynary gift but must ultimately draw on payment for intellectual property. The notion that the Internet should use only free crypto is a guaranteed formula to kill such innovation except in the glacial corridors of academe, and force the successful commercial actors to "tunnel" rather than benefitting the entire net. And even those magisterial academic confines lead to things like RSA and RSADSI; to patent licensing and charging for intellectual property. Of course if you want guaranteed old technology, don't use anything until the patent has expired. > On the other hand PGP is doing a definite cut in its tradition in > order to move away from patent encumbered algorithms. However, PGP > uses an ad-hoc binary format as well. Even though it is simpler than > ASN.1/DER, it is still unnecessarily obscure, when applied in the > world of MIME. You seem to forget that although PGP would like its royalty costs to be "free", it charges for its commercial products. One cannot make a case here for anything other than self-interest. It is true that PGP gives away crippled non-commercial versions that won't affect what it sees as its self interest. RSADSI gives away RSAREF and RSAREF2 as well, so that one is a wash. > Anyway, what I refuse to accept is that the two camps (PGP and S/MIME) > do not try to collaborate. The two working groups are, as I understand it, under instructions to collaborate when areas of commonality are involved. What is more, MIME provides an overarching structure that could bring both under at least a common "envelope" structure if desired. Let us hope such cooperation is more than grudging lip service. > Why don't they sit together, listing their > features in an abstract manner, independent from any format like ASN.1 > or PGP's or any technology like X509? These feature-lists could be > merged, in order to come up with an abstract security specification > that includes both approaches. I believe this would be a major blunder. The advantages of web of trust are that anyone may be his own certifier, with whatever rules he wishes to make and perhaps publish. The advantages of rigid-heirarchical are that nobody but audited, known-standard certifiers with particular published rule-sets are valid. The first is extremely useful among small, mutually known groups in which members are willing to investigate each certifier's standards. The second is essential for arms-length and commercial interaction in which users must rely on standardized, known, supervised assurances with respect to trust procedures and cannot personally investigate each certifier. Trying to make either model do the job of the other will corrupt it such that it will lose some of its own advantages. I note that most action in this direction is with respect to PGP trying to get some of S/MIME's "market share". I think this to be a very bad idea. In the end, unless there are versions of PGP software which will, hard-wired, accept only rigid-heirarchical trust, this will corrupt both trust models with respect to PGP. What I am saying is that although much focus has been on particular algorithms in the past, the "openness" of Open PGP reveals that this is really a distraction (fundamental principle-wise), and the real crux of the matter is trust models. > This abstract specification could then > be mapped to concrete technologies, whether MIME (=> MOSS), ASN.1 (=> > PKCS) or the PGP-style. Conversion software could be used as gateways > between these protocols. > > If this where done, the IMC or any other involved party could show, > whether their work in the IETF is for the sake of the community or > just for their own market share. Again a specious dichotomy is being set up between "the sake of the community" and "commercial viability". The two are inextricably intertwined. > Get back to common sense, now! Get > the Internet back into people's hands! "Power to me and my friends!" uh, er, um, oops, "Power to the People!" David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA09756 for ietf-open-pgp-bks; Sun, 30 Nov 1997 07:43:11 -0800 (PST) Received: from sirius.infonex.com (sirius.infonex.com [206.170.114.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA09752 for ; Sun, 30 Nov 1997 07:43:07 -0800 (PST) Received: (from mix@localhost) by sirius.infonex.com (8.8.8/8.7.3) id HAA28177 for ietf-open-pgp@imc.org; Sun, 30 Nov 1997 07:33:08 -0800 (PST) Date: Sun, 30 Nov 1997 07:33:08 -0800 (PST) Message-Id: <199711301533.HAA28177@sirius.infonex.com> From: Mix Comments: This message did not originate from the address above. It was remailed by an anonymous remailing service. If you have questions or complaints, please direct them to To: ietf-open-pgp@imc.org Subject: Helpful Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Subject: Re: RSA Blows Standards (S/MIME) Smoke From: david@sternlight.com (David Sternlight) Date: 1997/11/06 Message-ID: Newsgroups: alt.security.pgp,comp.security.pgp.discuss,alt.security,talk.politics.crypto,alt.privacy In article <63t0q3$rkq@clarknet.clark.net>, gsh@clark.net (Greg Hennessy) wrote: >>Phil took RSA and deprived RSADSI of their patent rights in PGP 1.x. The >>IETF area chairman has been widely reported to be trying to do something >>analogous for S/MIME. > >Cite. Already published here by Stone. > >This constant slandering of the IETF is really getting old. It will continue until we have an explanation. And it isn't "slander" but criticism. You DO know the difference, don't you? In fact I'm told that the IEG's policy is that standards should be "intellectual-property-neutral". If true it seems to me the IETF area chairman is in violation of that principle by refusing materials which are the intellectual property of the inventors in favor of materials in which intellectual property rights are conveyed. > >>saying that you can't be one Internet standard among several unless you >>surrender your hard-earned intellectual property is thuggery, pure and >>simple. > >It is not "thuggery" to insist that any internet standard NOT be a >trade secret of a company. RSADSI is under no obligation to to >surrender trade secret status of RC2. The IETF is under no obligation >to certify S/MIME as an internet standard. It is thuggery to use what market power the unelected, unrepresentative IETF area group has to insist on the surrender of property rights in aid of an ideological axe to grind on that matter. I see it as little different, in principle, from blackmail, particularly if the report of the IEG's intellectual-property-neutral policy is accurate. There is nothing wrong with adopting a proprietary standard (especially such a widespread de facto one into which so much hard work has gone by some of the best and brightest companies in the world). as long as it is not an exclusive standard. The whole character of MIME is to allow diverse formats. Let the market decide. I am surprised that those who ordinarily make ringing cries for individual freedom and choice should be on the side of the seeming fascists on this one. > >If RSADSI chooses to release RC2 because they think the benefit of >having S/MIME be an internet standard outweighs the benefit of having >RC2 be a trade secret, that is RSADSI's decision to make. > >They can continue to push S/MIME without being an internet standard. You are flying in the face of many years of court rulings on such topics as country club discrimination. Think it through. > >>Who do these people think they are, anyway? > >The Internet Engineering Task Force. They are unelected and unrepresentative. Most users not only didn't get a vote, but their market power vote is being taken away by practices such as those reportedly going on. If the IETF cannot practice fairness, and instead allow an area chairman to seemingly pursue a personal ideology about intellectual property when a context of choice is available, perhaps it is time the government or the courts took away their power over the public information highway. Assuming the reports are accurate, if Schiller doesn't like the patent laws he should talk to Congress, not beat RSADSI up about it by unfairly using powers granted to him on everyone's behalf. If the reports aren't accurate we are long overdue for a full explanation. It is OUR internet, not Jeff Schiller's, and continued silence shows an arrogance toward users. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA09175 for ietf-open-pgp-bks; Sun, 30 Nov 1997 06:37:39 -0800 (PST) Received: from vguard.com (sunex.elementrix.co.il [199.203.125.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA09171 for ; Sun, 30 Nov 1997 06:37:25 -0800 (PST) Received: from network ([199.203.125.24] (may be forged)) by vguard.com (8.8.6/8.6.12) with SMTP id QAA03154; Sun, 30 Nov 1997 16:43:16 +0200 (IST) Received: by localhost with Microsoft MAPI; Sun, 30 Nov 1997 16:42:49 +0200 Message-ID: From: Raviv Reply-To: "raviv@vguard.com" To: "'Hanan - Vanguard'" , "'ietf-open-pgp@imc.org'" Cc: "'sdp8@vguard.com'" , "'ruth@vguard.com'" Subject: test56 Date: Sun, 30 Nov 1997 16:43:07 +0200 Organization: Vanguard security technologies Ltd. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCFDAE.FE78D5C0" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk ------ =_NextPart_000_01BCFDAE.FE78D5C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit test56 Raviv Karnieli CTO Vanguard Security Technologies Ltd. Tel. 972-4-855-1410 Fax 972-4-855-1411 www.vguard.com raviv@vguard.com ------ =_NextPart_000_01BCFDAE.FE78D5C0 Content-Type: text/plain; name="topsecret.txt" Content-Transfer-Encoding: quoted-printable Blue Sky Airlines Top Secret! =20 Use secure data pipelines only! Proposal and=20 Marketing Plan Blue Sky's Best Opportunity For East Region Expansion Chapter 1 Blue Sky Marketing Plan Blue Sky's Best Opportunity For Expansion Changing the airline industry forever=09 New proprietary technology has opened new opportunities for Blue Sky. = Moving quickly to adopt and implement this technology will give Blue Sky = a leading position in the industry after years of being in third place. = Read the following carefully and ensure its confidentiality by using = secure data pipelines only!. 1) Insert your company name and address in place of the text on the = cover page by clicking once and typing. 2) Choose File Save As. At the bottom of the menu, choose Document = Template in the Save File as Type: box. Save the file under a new name = to protect the original version, or use the same template name to = replace the existing version. How To Create a Report To create a report from your newly saved template, select File New to = re-open your template as a document. (Your company information should = appear in place.) . For the body of your report, use Styles such as = Heading 1-5, Body Text, Block Quotation, List Bullet, and List Number = from the Style control on the Formatting toolbar. How To Create Bullets and Numbered Lists * To create a bulleted list like this, select one or more paragraphs and = choose the List Bullet style from the Style drop-down list on the = formatting toolbar. To create a numbered list like the numbered = paragraphs above, select one or more paragraphs and choose the List = Number style from the Style drop-down list. This Style-the Block Quotation-can be used for quotes, notes or = paragraphs of special interest. To use the Block Quotation Style, = highlight any paragraph and choose Block Quotation from the style = drop-down list on the Formatting toolbar. How To Create a Table of Contents To create a Table of Contents for this report, position your cursor on = the blank TOC page. From the Insert menu choose Index and Tables. Click = on the Table of Contents tab. Be sure to user the Custom Style format. More Template Tips There are three ways to view the various style names of template text: 1) In Normal view, choose Tools Options. Click the View tab. In the = Style Area Width box, dial up a number such as "1" and click OK. Observe = the style name next to each paragraph; or 2) In Page Layout view, click on any paragraph. View the style name on = the Formatting toolbar; or 3) From the Format menu choose Style Gallery. In the Preview section = click on Example or Style Samples. How To Create a Table Choose Insert from the Table menu. Be sure to choose the Professional = AutoFormat if you are using a Professional style template. To modify an existing table, such as the table below, position your = cursor in any cell. To modify the table, access the Table menu to select = the desired action and/or result. Competitor Ranking Current Share Share in 3 Yrs. Largest competitor 50% 30% Second largest competitor 25% 20% Third largest competitor 15% 12% * Table. Projected growth of competitors over 3 years. How to Edit Table Text Table text can be edited and formatted like regular text. Simply select = text and type to replace, and use the Format menu to change the font = and/or paragraph attributes. How To Change a Header or Footer In Page Layout view, choose Header or Footer from the View menu. Once = activated, you can change or delete the text just like regular text. = When done, click Close to exit. To delete a ruling line in the Header or Footer, from the Format menu = choose Borders and Shading. Choose None from the Preset section, and = click OK. ?? (footnote continued) 2 3 =20 =20 ------ =_NextPart_000_01BCFDAE.FE78D5C0-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA09070 for ietf-open-pgp-bks; Sun, 30 Nov 1997 06:14:23 -0800 (PST) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA09037; Sun, 30 Nov 1997 06:12:34 -0800 (PST) Received: by callandor.cybercash.com; id JAA07849; Sun, 30 Nov 1997 09:00:59 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma007839; Sun, 30 Nov 97 09:00:43 -0500 Received: from by cybercash.com (4.1/SMI-4.1) id AB28562; Sun, 30 Nov 97 09:15:10 EST Message-Id: <3.0.32.19971130091151.00730f14@cybercash.com> X-Sender: crocker@cybercash.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 30 Nov 1997 09:11:57 -0500 To: galvin@commerce.net, ietf-open-pgp@imc.org, murphy@tis.com, ned@innosoft.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-smime@imc.org, mime-msp@imc.org From: Steve Crocker (by way of Steve Crocker ) Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Cc: crocker@cybercash.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk [This is a resend of my previous message with corrected addresses for Jim Galvin and the ietf-open-pgp working group. Please discard my previous message.] Gunther, Thanks for your kind words about MOSS. Let me offer a bit of perspectrive about MOSS in relation to S/MIME. MOSS was designed to take full advantage of MIME. It uses the MIME facilities for hnadling multiple parts and for encoding binary information. Although MIME is enormously successful, it does have some technical wrinkles that complicated the design of MOSS and make the resulting design less elegant than we would have liked. I'm referring specifically to MIME's requirement that everything be encoded in a 7bit format and that the encoding be only in the atomic parts of the structure. Meanwhile, S/MIME adherents usually take the position that MOSS cannot be implemented easily unless one has a complete MIME implementation already. S/MIME, on the other hand, is designed to make maximum use of PKCS formats. It implements enough MIME to be compatible with MIME format, but doesn't use MIME mechanisms internally. Let me also comment on one technical detail. You suggest that messages in the MOSS forat could be transliterated easily into other formats. While it is true that the text and structure of a MOSS message could be transliterated into other formats, signatures are specific to the precise encoding of a message and cannot be transliterated. At the time MOSS was designed, PGP was not compatible with MIME and there was no clear path for bringing PGP into the standards arena. That's since changed. Steve Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA09046 for ietf-open-pgp-bks; Sun, 30 Nov 1997 06:12:43 -0800 (PST) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA09038 for ; Sun, 30 Nov 1997 06:12:34 -0800 (PST) Received: by callandor.cybercash.com; id JAA07848; Sun, 30 Nov 1997 09:01:00 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma007836; Sun, 30 Nov 97 09:00:41 -0500 Received: from crockerdec.cybercash.com ([172.16.2.228]) by cybercash.com (4.1/SMI-4.1) id AA28562; Sun, 30 Nov 97 09:15:07 EST Message-Id: <3.0.32.19971130090739.0070efec@cybercash.com> X-Sender: crocker@cybercash.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 30 Nov 1997 09:11:55 -0500 To: galvin@commerce.net, ietf-open-pgp@imc.org From: Steve Crocker Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Forwarding Gunther's Schadow's message. >Return-Path: >Date: Sun, 30 Nov 1997 14:39:03 +0100 (MET) >From: Gunther Schadow >To: crocker@cybercash.com, galvin@tis.com, murphy@tis.com, ned@innosoft.com >Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS? >Cc: ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, > ietf-smime@imc.org, mime-msp@imc.org > >TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY. > >I am a member of a EDI standards organization currently preparing a >recommendation for their members on applying Internet E-Mail >standards. Of course, security is a major issue here. Our observation >is that the field is everything else than clear while PGP and S/MIME >camps are fighting each other. Unfortunately, marketing interests >seem to play the major role in that fight. As much as I am confident >in the IETF to stick to its former policy propagating open, freely >available, simple and effective standards, I am nevertheless concerned >that industry is on the edge to do a lot of harm in that field. It >seems already that the "Internet Mail Consortium" will have a strong >impact in IETF standardization, and as the IMC is an industry >consortium, is not committed to the IETF policy. > >I have a strong personal distaste with S/MIME, as the PKCS specs >require ASN.1, X500 and other OSI stuff that does not merge very well >with the rest of the Internet infrastructure. Of course the use of >patent encumbered algorithms is a deleterious "feature" of S/MIME -- >this also shows whose only real interest it is to have S/MIME. It is >not common sense, it is the profit of one company: RSA Data Security, >Inc. The other industry that present itself as deciples of RSA D.S. >Inc. is there to serve as distributors of patent license royalties. >This is a very similar marketing strategy as we all know far too much >from Bill Gates. Do you really want such attitudes to influence the >Internet? > >On the other hand PGP is doing a definite cut in its tradition in >order to move away from patent encumbered algorithms. However, PGP >uses an ad-hoc binary format as well. Even though it is simpler than >ASN.1/DER, it is still unnecessarily obscure, when applied in the >world of MIME. > >Unfortunately, the MOSS specification RFC1848 seems to have been >forgotten. MOSS beats both S/MIME and PGP in terms of being open and >straight forward. It fits very well into the MIME world and does not >require any other technology than MIME. And most important, it is not >engaged in any way to a certain set of algorithms. MOSS can be >translated from and to S/MIME as well as traditional or Open PGP. It >transcends the specifics of any of these technology. > >I really much like to see MOSS having a future in the Internet >community. I would myself write a concise implementation of a flexible >multi-algorithm MOSS that would be freely available. And I think, >others would do so as well. > >Anyway, what I refuse to accept is that the two camps (PGP and S/MIME) >do not try to collaborate. Why don't they sit together, listing their >features in an abstract manner, independent from any format like ASN.1 >or PGP's or any technology like X509? These feature-lists could be >merged, in order to come up with an abstract security specification >that includes both approaches. This abstract specification could then >be mapped to concrete technologies, whether MIME (=> MOSS), ASN.1 (=> >PKCS) or the PGP-style. Conversion software could be used as gateways >between these protocols. > >If this where done, the IMC or any other involved party could show, >whether their work in the IETF is for the sake of the community or >just for their own market share. Get back to common sense, now! Get >the Internet back into people's hands! > >regards >-Gunther > >Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany >Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin. >gusw@zedat.fu-berlin.de http://userpage.fu-berlin.de/~gusw >----------------------------------#include ----------- > > ---------------------------------- Steve Crocker Desk: +1 703 716 5214 CyberCash, Inc. Main: +1 703 620 4200 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 20191 crocker@cybercash.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA08919 for ietf-open-pgp-bks; Sun, 30 Nov 1997 05:57:42 -0800 (PST) Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA08897; Sun, 30 Nov 1997 05:57:24 -0800 (PST) Received: by callandor.cybercash.com; id IAA07679; Sun, 30 Nov 1997 08:45:29 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma007676; Sun, 30 Nov 97 08:45:28 -0500 Received: from crockerdec.cybercash.com ([172.16.2.228]) by cybercash.com (4.1/SMI-4.1) id AA28493; Sun, 30 Nov 97 08:59:53 EST Message-Id: <3.0.32.19971130085637.00737310@cybercash.com> X-Sender: crocker@cybercash.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 30 Nov 1997 08:56:41 -0500 To: Gunther Schadow From: Steve Crocker Subject: Re: Why do people fight about S/MIME vs. PGP rather than use MOSS? Cc: crocker@cybercash.com, galvin@tis.com, murphy@tis.com, ned@innosoft.com, ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, mime-msp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gunther, Thanks for your kind words about MOSS. Let me offer a bit of perspectrive about MOSS in relation to S/MIME. MOSS was designed to take full advantage of MIME. It uses the MIME facilities for hnadling multiple parts and for encoding binary information. Although MIME is enormously successful, it does have some technical wrinkles that complicated the design of MOSS and make the resulting design less elegant than we would have liked. I'm referring specifically to MIME's requirement that everything be encoded in a 7bit format and that the encoding be only in the atomic parts of the structure. Meanwhile, S/MIME adherents usually take the position that MOSS cannot be implemented easily unless one has a complete MIME implementation already. S/MIME, on the other hand, is designed to make maximum use of PKCS formats. It implements enough MIME to be compatible with MIME format, but doesn't use MIME mechanisms internally. Let me also comment on one technical detail. You suggest that messages in the MOSS forat could be transliterated easily into other formats. While it is true that the text and structure of a MOSS message could be transliterated into other formats, signatures are specific to the precise encoding of a message and cannot be transliterated. At the time MOSS was designed, PGP was not compatible with MIME and there was no clear path for bringing PGP into the standards arena. That's since changed. Steve ---------------------------------- Steve Crocker Desk: +1 703 716 5214 CyberCash, Inc. Main: +1 703 620 4200 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 20191 crocker@cybercash.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA08842 for ietf-open-pgp-bks; Sun, 30 Nov 1997 05:41:41 -0800 (PST) Received: from Mail.ZEDAT.FU-Berlin.DE (mail.zedat.fu-berlin.de [160.45.2.8]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA08800; Sun, 30 Nov 1997 05:35:22 -0800 (PST) Received: by Mail.ZEDAT.FU-Berlin.DE (Smail3.2.0.98) from nepumuk.ether.schadow.net (160.45.216.109) with esmtp id ; Sun, 30 Nov 1997 14:35:33 +0100 (MET) Received: (from gunther@localhost) by nepumuk.ether.schadow.net (8.8.5/8.6.12) id OAA28260; Sun, 30 Nov 1997 14:39:03 +0100 (MET) Date: Sun, 30 Nov 1997 14:39:03 +0100 (MET) From: Gunther Schadow Message-Id: <199711301339.OAA28260@nepumuk.ether.schadow.net> To: crocker@cybercash.com, galvin@tis.com, murphy@tis.com, ned@innosoft.com Subject: Why do people fight about S/MIME vs. PGP rather than use MOSS? Cc: ietf-ediint@imc.org, ietf-open-pgp@imc.org, ietf-pgp-mime@imc.org, ietf-smime@imc.org, mime-msp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk TWO EVERYONE INTERESTED IN INTERNET MAIL SECURITY. I am a member of a EDI standards organization currently preparing a recommendation for their members on applying Internet E-Mail standards. Of course, security is a major issue here. Our observation is that the field is everything else than clear while PGP and S/MIME camps are fighting each other. Unfortunately, marketing interests seem to play the major role in that fight. As much as I am confident in the IETF to stick to its former policy propagating open, freely available, simple and effective standards, I am nevertheless concerned that industry is on the edge to do a lot of harm in that field. It seems already that the "Internet Mail Consortium" will have a strong impact in IETF standardization, and as the IMC is an industry consortium, is not committed to the IETF policy. I have a strong personal distaste with S/MIME, as the PKCS specs require ASN.1, X500 and other OSI stuff that does not merge very well with the rest of the Internet infrastructure. Of course the use of patent encumbered algorithms is a deleterious "feature" of S/MIME -- this also shows whose only real interest it is to have S/MIME. It is not common sense, it is the profit of one company: RSA Data Security, Inc. The other industry that present itself as deciples of RSA D.S. Inc. is there to serve as distributors of patent license royalties. This is a very similar marketing strategy as we all know far too much from Bill Gates. Do you really want such attitudes to influence the Internet? On the other hand PGP is doing a definite cut in its tradition in order to move away from patent encumbered algorithms. However, PGP uses an ad-hoc binary format as well. Even though it is simpler than ASN.1/DER, it is still unnecessarily obscure, when applied in the world of MIME. Unfortunately, the MOSS specification RFC1848 seems to have been forgotten. MOSS beats both S/MIME and PGP in terms of being open and straight forward. It fits very well into the MIME world and does not require any other technology than MIME. And most important, it is not engaged in any way to a certain set of algorithms. MOSS can be translated from and to S/MIME as well as traditional or Open PGP. It transcends the specifics of any of these technology. I really much like to see MOSS having a future in the Internet community. I would myself write a concise implementation of a flexible multi-algorithm MOSS that would be freely available. And I think, others would do so as well. Anyway, what I refuse to accept is that the two camps (PGP and S/MIME) do not try to collaborate. Why don't they sit together, listing their features in an abstract manner, independent from any format like ASN.1 or PGP's or any technology like X509? These feature-lists could be merged, in order to come up with an abstract security specification that includes both approaches. This abstract specification could then be mapped to concrete technologies, whether MIME (=> MOSS), ASN.1 (=> PKCS) or the PGP-style. Conversion software could be used as gateways between these protocols. If this where done, the IMC or any other involved party could show, whether their work in the IETF is for the sake of the community or just for their own market share. Get back to common sense, now! Get the Internet back into people's hands! regards -Gunther Gunther Schadow-----------Windsteiner Weg 54a, Berlin 14165, FR. Germany Dept. of Anaesthesia, Benjamin Franklin Univerity Hospital, Berlin. gusw@zedat.fu-berlin.de http://userpage.fu-berlin.de/~gusw ----------------------------------#include ----------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA07181 for ietf-open-pgp-bks; Sun, 30 Nov 1997 02:26:46 -0800 (PST) Received: from mx2.media3.net (root@[206.155.138.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA07177 for ; Sun, 30 Nov 1997 02:26:41 -0800 (PST) Received: from dialup414.serv.net (dialup414.serv.net [207.207.70.15]) by mx2.media3.net (8.8.5/8.6.9) with SMTP id FAA12354 for ; Sun, 30 Nov 1997 05:21:56 -0500 (EST) From: Erik Seaberg To: ietf-open-pgp@imc.org Subject: Re: expedience, consensus and editing Date: Sun, 30 Nov 1997 10:28:19 GMT Organization: J. Random Software Message-ID: <34862f0b.7568439@jrandom.com> References: <01IQLGFM46NW9TCNFH@INNOSOFT.COM> In-Reply-To: <01IQLGFM46NW9TCNFH@INNOSOFT.COM> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sat, 29 Nov 1997 20:54:29 -0800 (PST), Ned.Freed@innosoft.com wrote to ietf-open-pgp@imc.org: > If you don't want the [message/external-body] pointer then the right > answer is to define a MIME type for a existing PGP detached signature > object. Would RFC 2015 application/pgp-signature (outside a multipart/signed body) suit? Would this be a good way to support several signatures over the same content? (Possibly from different entities, or using different algorithms, or mixing OpenPGP/MIME and S/MIME....) Most application/pgp-signature examples I've seen put ASCII-armored sigs in the body part, but I hope we can move towards binary detached signatures that gateways could encode and decode at need to take advantage of cleaner transports and storage, and without redundant "-----BEGIN stuff" delimiters. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA03852 for ietf-open-pgp-bks; Sat, 29 Nov 1997 20:56:25 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA03848 for ; Sat, 29 Nov 1997 20:56:20 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IQLA9YOGGG9TCNFH@INNOSOFT.COM> for ietf-open-pgp@imc.org; Sat, 29 Nov 1997 20:56:42 PST Date: Sat, 29 Nov 1997 20:54:29 -0800 (PST) From: Ned Freed Subject: Re: expedience, consensus and editing In-reply-to: "Your message dated Sat, 29 Nov 1997 10:51:06 -0800" <199711291851.KAA00234@s20.term1.sb.rain.org> To: Hal Finney Cc: hal@rain.org, ietf-open-pgp@imc.org, lindsay@powerup.com.au Message-id: <01IQLGFM46NW9TCNFH@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > > Could you explain how the following detached signature would be > > > encoded using RFC1847/RFC2015? Would you use multipart/signed or > > > multipart/encrypted? > > multipart/signed, with no encoding for clear text. For opaque signing we > > could either encode it with base64 or sign & encrypt. > This is not what I meant by a detached signature. PGP supports the > concept of a signature which can be sent around independently of the data > it signs. For example, I could request that someone send me a signature > on some data I received earlier. They could create a signature on the > data and send it to me, without having to re-send the data itself. Existing facilities can be used to do detached MIME signaturues. Specifically, one constructs a message/external-body MIME object that contains a content-md5 field describing the external data. One then signs this part. The result is a detached signature that also contains a pointer to the actual data which has been signed. If you don't want the pointer then the right answer is to define a MIME type for a existing PGP detached signature object. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA20927 for ietf-open-pgp-bks; Sat, 29 Nov 1997 11:16:58 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA20923 for ; Sat, 29 Nov 1997 11:16:55 -0800 (PST) Received: from s20.term1.sb.rain.org (s07.term2.sb.rain.org [198.68.144.167]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id LAA08634; Sat, 29 Nov 1997 11:19:55 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA00234; Sat, 29 Nov 1997 10:51:06 -0800 Date: Sat, 29 Nov 1997 10:51:06 -0800 From: Hal Finney Message-Id: <199711291851.KAA00234@s20.term1.sb.rain.org> To: hal@rain.org, ietf-open-pgp@imc.org, lindsay@powerup.com.au Subject: Re: expedience, consensus and editing Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lindsay Mathieson, , writes, quoting Hal Finney: > >Could you explain how the following detached signature would be > >encoded using RFC1847/RFC2015? Would you use multipart/signed or > >multipart/encrypted? > > multipart/signed, with no encoding for clear text. For opaque signing we > could either encode it with base64 or sign & encrypt. This is not what I meant by a detached signature. PGP supports the concept of a signature which can be sent around independently of the data it signs. For example, I could request that someone send me a signature on some data I received earlier. They could create a signature on the data and send it to me, without having to re-send the data itself. I gave an example of a detached signature in my earlier message: -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 iQA/AwUBNH5DH7qVexb8FGk/EQKTagCg9NwSygbmXdVts7NbIyPkaX9p65QAn2Lu DTwZos6GWUDnplXYbZXolxLY =hgt3 -----END PGP SIGNATURE----- This signature could potentially sign a very large amount of data which we would not necessarily want to send along with the signature. Hal Finney hal@pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA20921 for ietf-open-pgp-bks; Sat, 29 Nov 1997 11:16:53 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA20917 for ; Sat, 29 Nov 1997 11:16:48 -0800 (PST) Received: from s20.term1.sb.rain.org (s07.term2.sb.rain.org [198.68.144.167]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id LAA08629 for ; Sat, 29 Nov 1997 11:19:53 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id LAA00248 for ietf-open-pgp@imc.org; Sat, 29 Nov 1997 11:02:28 -0800 Date: Sat, 29 Nov 1997 11:02:28 -0800 From: Hal Finney Message-Id: <199711291902.LAA00248@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: PGP/MIME is not an alternative to ascii armor Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The larger point I'd like to make with respect to PGP/MIME is that it is not just a transfer encoding which is applied on top of PGP. It is really a full protocol in itself, closely related to PGP, but with its own rules and formatting. If it were a transfer encoding, like PGP's ascii armor, it would allow you to take an arbitrary PGP binary message and encode it for transport. PGP/MIME does not do this. Instead, PGP/MIME enforces its own rules on the kinds of binary encoding which can be created. For example, it insists that the only data which can be encrypted or signed MUST be in MIME body part format, with a MIME header, blank line, and MIME body. It also requires that the data must be converted to 7-bit form before being signed, and it limits the kinds of PGP binary packets which can be sent around, eliminating detached signatures among others. These kinds of rules require the encryption/signature engine to know whether it is producing data that will be used for PGP/MIME or whether the data is for straight PGP, possibly with ascii armor. The rules for formatting the data and determining what kinds of inputs are allowed will be different in the two cases. Despite their superficial similarities, PGP/MIME is really not the equivalent of ascii armor. They are not alternatives which can substitute for each other. I think people are being misled by the fact that both produce ascii readable output and are assuming that it is an either/or situation. But that is not the best way to look at it. This is why I have been objecting all along to the notion that we could eliminate ascii armor in favor of PGP/MIME. It might make sense to make one or both of them be SHOULD or MUST, but they are not alternatives. The two should be considered independently. Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA01772 for ietf-open-pgp-bks; Fri, 28 Nov 1997 23:07:08 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id XAA01768 for ; Fri, 28 Nov 1997 23:07:01 -0800 (PST) Message-Id: <199711290707.XAA01768@mail.proper.com> Received: (qmail 9520 invoked from network); 29 Nov 1997 07:08:25 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 29 Nov 1997 07:08:25 -0000 Date: 29 Nov 1997 7:58:35 GMT From: Lindsay Mathieson Subject: Re: expedience, consensus and editing To: Hal Finney , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Could you explain how the following detached signature would be >encoded using RFC1847/RFC2015? Would you use multipart/signed or >multipart/encrypted? multipart/signed, with no encoding for clear text. For opaque signing we could either encode it with base64 or sign & encrypt. An example: From: Hal Finney To: Lindsay Mathieson Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar Content-Type: text/plain; charset=iso-8859-1 Lindsay Mathieson, , writes, quoting me: > > - There is no PGP/MIME encoding of a detached signature > > > > - There is no PGP/MIME encoding of a non-clear signed message > > ? Both points are clearly addressed (and doable) in RFC 1847 & RFC2015, which > are PGP/MIME (aren't they ?) Could you explain how the following detached signature would be encoded using RFC1847/RFC2015? Would you use multipart/signed or multipart/encrypted? --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.0 iQA/AwUBNH5DH7qVexb8FGk/EQKTagCg9NwSygbmXdVts7NbIyPkaX9p65QAn2Lu DTwZos6GWUDnplXYbZXolxLY =hgt3 -----END PGP MESSAGE----- --bar-- -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 29, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA01127 for ietf-open-pgp-bks; Fri, 28 Nov 1997 21:06:13 -0800 (PST) Received: from dfw-ix11.ix.netcom.com (dfw-ix11.ix.netcom.com [206.214.98.11]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA01122; Fri, 28 Nov 1997 21:06:08 -0800 (PST) Received: (from smap@localhost) by dfw-ix11.ix.netcom.com (8.8.4/8.8.4) id XAA01143; Fri, 28 Nov 1997 23:06:29 -0600 (CST) Received: from pax-ca13-24.ix.netcom.com(204.31.233.56) by dfw-ix11.ix.netcom.com via smap (V1.3) id rma001130; Fri Nov 28 23:05:54 1997 Message-Id: <3.0.3.32.19971126172402.007206fc@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 26 Nov 1997 17:24:02 -0800 To: Adam Back , ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: expedience, consensus and editing Cc: jon@pgp.com, dcrocker@imc.org In-Reply-To: <199711262108.VAA05371@server.test.net> References: <199711260240.SAA27773@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:08 PM 11/26/1997 GMT, Adam Back wrote: >I would like to see more rapid progress in this forum. We've been too busy fighting about important political issues to get done quickly, but I think we're near rough consensus. IETF-SMIME hasn't had this problem, because they're already doing MIME, and don't have a CMR feature to fight about. >1) armor MAY/SHOULD/MUST? SHOULD. >2) MIME as MAY/SHOULD/MUST? I'd prefer MAY, but won't object to SHOULD. >3) 32 bit int clean up shelved for OpenPGPv2, or discussed now Shelve it. It's nice, but not a big issue. The more important clean up that's related is making sure there's a mechanism for indefinite-length material so we can do things like streaming, which the older PGP formats appeared to support better than the new one. >4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2, Agree with your "define subpacket type 10 as reserved for future use". Dave Crocker writes: > Ok. So you implement armor and I implement MIME. How do we interoperate? Binary, and leave transport issues up to the user. Works fine. I think Armor needs to be a SHOULD to reduce this problem, especially for compatibility with the PGP 5.0 and 2.6.2 bases, and making MIME a SHOULD might also help with newer applications. The main reason for not making Armor a MUST is to keep things small for minimal environments like smartcards, though Some People just don't like it and have other agendas. :-) Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA27973 for ietf-open-pgp-bks; Fri, 28 Nov 1997 12:51:55 -0800 (PST) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA27969 for ; Fri, 28 Nov 1997 12:51:51 -0800 (PST) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id OAA03812; Fri, 28 Nov 1997 14:52:10 -0600 (CST) Received: from lax-ca66-29.ix.netcom.com(207.223.161.93) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma003776; Fri Nov 28 14:51:41 1997 Message-ID: <347F2EEB.D155D1D6@sternlight.com> Date: Fri, 28 Nov 1997 12:52:08 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: "Mark J. McArdle" , "ietf-open-pgp@imc.org" Subject: Re: The Web of Trust Has No Clothes References: <01BCFB81.7644BAE0@markm@pgp.com> <347F0561.3731D3E2@sternlight.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Sternlight wrote: At the risk of compounding the number of extra bits, apologies for the duplication of the text in my previous message. I let my fingers do the walking on my paste key once too often. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA26306 for ietf-open-pgp-bks; Fri, 28 Nov 1997 09:54:24 -0800 (PST) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA26301 for ; Fri, 28 Nov 1997 09:54:20 -0800 (PST) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id LAA23276; Fri, 28 Nov 1997 11:54:42 -0600 (CST) Received: from lax-ca66-29.ix.netcom.com(207.223.161.93) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma023268; Fri Nov 28 11:54:29 1997 Message-ID: <347F0561.3731D3E2@sternlight.com> Date: Fri, 28 Nov 1997 09:54:46 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: "Mark J. McArdle" CC: "ietf-open-pgp@imc.org" Subject: Re: The Web of Trust Has No Clothes References: <01BCFB81.7644BAE0@markm@pgp.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Mark J. McArdle wrote: I have no wish to post off-topic to this group. Mark's misrepresentation of my concern is what is off-topic. Fairness and a setting of the record straight requires a response. To put it simply and directly, by negating RSA in PGP 5.53, PGP invalidated all the prior RSA web of trust signatures and keys for users of the new version and created either a split in the web of trust or a situation of forced conversion and re-signing for those who wish to use the latest version. This seems both incontrovertible and unarguable, and ad hominem attacks on those who ask about it are non-responsive. My concern is to see that Open PGP is robust over such "improvements" to algorithms. The current worked example by PGP Inc. is relevant to understanding the issue. As to the lies which have gained strong currency, I need to say a word to clear the air and in fairness. I am a PGP user. I was one of the earliest PGP users until I found it was infringing. I then worked behind the scenes (as Jim Bidzos will confirm) to try to get him to license RSA for PGP. That effort initially failed apparently because of what Simson Garfinkel describes in his book on PGP as Phil's intransigence, not because of any lack of effort on my part or Eric Hughes part or even Jim Bidzos' goodwill. Subsequently I was one of the first adopters of MIT PGP and both Jeff Schiller and Derek Atkins signed my key. I believe PGP has its strong place when web of trust is appropriate to the circumstances, and rigid heirarchical (as practiced with S/MIME and CAs such as Verisign in Netscape and Microsoft Explorer) has its place. I believe there is no all-purpose solution to trust models that won't either lose some of the advantages of web of trust, or some of the advantages of rigid heirarchical. Some discussion on this point by all-or-nothing fans has also led to attempts at demonization and marginalization when substantive counter-arguments were unavailable to the proponents. In particular, I believe we need two solutions for the Internet--one of each trust model, and I understand this group and the S/MIME 3 group are under instructions to coordinate in areas of commonality. I remain a PGP user as well as an S/MIME user. I take strong exception to some acts of PGP Inc. and PRZ but those have nothing to do with this group except as they affect such things as the robustness of Open PGP over algorithmic improvements--an important topic--or as they might affect true IETF configuration control. I do not plan to raise prior concerns here except as they may be relevant to Open PGP. Some who hold either Phil or PGP Inc. as an avatar have used my criticisms of some acts of PRZ or PGP Inc. elsewhere as an occasion to demonize or marginalize me when they were unable to respond to such substantive criticisms with rational counter-arguments. Shoot the messenger remains a popular sport in some quarters. Finally, with respect to this group my interest is solely in making what contribution I can to Open PGP's robustness and independence. I take very seriously the concept of IETF configuration control, and if it IS going to be a pacing principle, it must be complete and effective, and not window-dressing for competitive advantage-seeking by PGP Inc. (in the case of Open PGP) or RSADSI (in the case of S/MIME 3). David Sternlight, Ph.D. Mark J. McArdle wrote: I have no wish to post off-topic to this group. Mark's misrepresentation of my concern is what is off-topic. Fairness and a setting of the record straight requires a response. To put it simply and directly, by negating RSA in PGP 5.53, PGP invalidated all the prior RSA web of trust signatures and keys for users of the new version and created either a split in the web of trust or a situation of forced conversion and re-signing for those who wish to use the latest version. This seems both incontrovertible and unarguable, and ad hominem attacks on those who ask about it are non-responsive. My concern is to see that Open PGP is robust over such "improvements" to algorithms. The current worked example by PGP Inc. is relevant to understanding the issue. As to the lies which have gained strong currency, I need to say a word to clear the air and in fairness. I am a PGP user. I was one of the earliest PGP users until I found it was infringing. I then worked behind the scenes (as Jim Bidzos will confirm) to try to get him to license RSA for PGP. That effort initially failed apparently because of what Simson Garfinkel describes in his book on PGP as Phil's intransigence, not because of any lack of effort on my part or Eric Hughes part or even Jim Bidzos' goodwill. Subsequently I was one of the first adopters of MIT PGP and both Jeff Schiller and Derek Atkins signed my key. I believe PGP has its strong place when web of trust is appropriate to the circumstances, and rigid heirarchical (as practiced with S/MIME and CAs such as Verisign in Netscape and Microsoft Explorer) has its place. I believe there is no all-purpose solution to trust models that won't either lose some of the advantages of web of trust, or some of the advantages of rigid heirarchical. Some discussion on this point by all-or-nothing fans has also led to attempts at demonization and marginalization when substantive counter-arguments were unavailable to the proponents. In particular, I believe we need two solutions for the Internet--one of each trust model, and I understand this group and the S/MIME 3 group are under instructions to coordinate in areas of commonality. I remain a PGP user as well as an S/MIME user. I take strong exception to some acts of PGP Inc. and PRZ but those have nothing to do with this group except as they affect such things as the robustness of Open PGP over algorithmic improvements--an important topic--or as they might affect true IETF configuration control. I do not plan to raise prior concerns here except as they may be relevant to Open PGP. Some who hold either Phil or PGP Inc. as an avatar have used my criticisms of some acts of PRZ or PGP Inc. elsewhere as an occasion to demonize or marginalize me when they were unable to respond to such substantive criticisms with rational counter-arguments. Shoot the messenger remains a popular sport in some quarters. Finally, with respect to this group my interest is solely in making what contribution I can to Open PGP's robustness and independence. I take very seriously the concept of IETF configuration control, and if it IS going to be a pacing principle, it must be complete and effective, and not window-dressing for competitive advantage-seeking by PGP Inc. (in the case of Open PGP) or RSADSI (in the case of S/MIME 3). David Sternlight, Ph.D. -----BEGIN PGP SIGNATURE----- Version: 2.6.3 Charset: noconv iQCVAwUBNH8FEkwgH+NYrQ81AQEE6AQAg1NJ2qJilE98sqY40xgX8zsZDxuFL+09 S1OnDiz9TR4kgz3j8IX0caE2jJpEbdRM4mu53FP4cNwCVXW4zUNHBQIZ0VT45NzQ 0Xs0ucJcRqu06p5Epj9/rHNy2x3JIMhvNBEpHK0ZeLyTTYrfEIghUoB7CeigTxi0 tXVJk3YPM0A= =8qJq -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA14729 for ietf-open-pgp-bks; Thu, 27 Nov 1997 22:14:44 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA14725 for ; Thu, 27 Nov 1997 22:14:40 -0800 (PST) Received: from endor (mg131-056.ricochet.net [204.179.131.56]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id WAA07095; Thu, 27 Nov 1997 22:15:46 -0800 (PST) Received: by localhost with Microsoft MAPI; Thu, 27 Nov 1997 22:11:51 -0800 Message-ID: <01BCFB81.7644BAE0@markm@pgp.com> From: "Mark J. McArdle" To: "'david@sternlight.com'" , "ietf-open-pgp@imc.org" Subject: RE: The Web of Trust Has No Clothes Date: Thu, 27 Nov 1997 22:11:50 -0800 Organization: Pretty Good Privacy, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4025 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk [annoyingly formatted message from D. Sternlight removed] Notwithstanding David Sternlight's interest in scrutinizing the Web of Trust, perhaps we could terminate this thread. Thankfully, most people are ignoring it. If David Sternlight will acknowledge that this group functioned before his arrival, and will continue to do so after his departure, we'll have a standard that much quicker. Discussing the features of 5.x with someone who (possibly sarcastically) expects signatures from one key to be magically moved over to a new key is not germane to the mandate of this group. I believe Hal has clearly and correctly explained how this implementation works. David, calling Hal non-responsive is inappropriate, as he is working hard on this standard. I've observed your PGP-related contributions to usenet in the past, and IMHO, you are rarely trying to be constructive. You are certainly not a PGP advocate, and this group consists of people who are interested/motivated/impassioned to take PGP to a new level. This isn't censorship, it's a question of basic respect and manners. Please respect our wish to work on this standard with people who are legitimately interested in evolving PGP. I am hoping the others on this list will agree to focus on the many other issues we have before us. I shudder to think about the collective amount of time spent reading and responding to these posts. I know it's 15 minutes of my Thanksgiving I'll never get back ;) Sincerely, Mark Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA14277 for ietf-open-pgp-bks; Thu, 27 Nov 1997 21:06:53 -0800 (PST) Received: from dfw-ix4.ix.netcom.com (dfw-ix4.ix.netcom.com [206.214.98.4]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA14273 for ; Thu, 27 Nov 1997 21:06:48 -0800 (PST) Received: (from smap@localhost) by dfw-ix4.ix.netcom.com (8.8.4/8.8.4) id XAA01732 for ; Thu, 27 Nov 1997 23:07:39 -0600 (CST) Received: from lax-ca66-01.ix.netcom.com(207.223.161.65) by dfw-ix4.ix.netcom.com via smap (V1.3) id rma001728; Thu Nov 27 23:07:16 1997 Message-ID: <347E518F.FA074FA4@sternlight.com> Date: Thu, 27 Nov 1997 21:08:23 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: The Web of Trust Has No Clothes Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > > > From OpenPGP list: > > > > Date: Mon, 24 Nov 1997 22:08:00 -0800 > > From: Hal Finney > > To: ietf-open-pgp@imc.org > > Subject: Re: The web of trust has no clothes. > > Sender: owner-ietf-open-pgp@imc.org > > > > PGP 5.X implements an extension to the trust model to address the issue > > raised by David Sternlight. > > > > > Another flaw in the web of trust and PGP is now revealed and comes home > > > to roost. Now that PGP Inc. has deep-sixed RSA in new free versions, > > > not only does everyone with an old RSA key have to generate a new key > > > but also a complete new set of signatures and web of trust must be built > > > if they wish to use the "better" algorithms. And the new keys must be > > > distributed to correspondents, either directly or by "pull" from > > > servers. This took years the first time--perhaps the second time it will > > > be a bit faster. > > > > The way it works is as follows. If you have two keys with identical > > userids, and the first key signs the second userid, then validity from > > the signatures on the first user ID gets propagated to the second userid. > > The effect is that if you generate a new DSA key with the same name > > as your old RSA key, and sign it with your old key, then your new key > > inherits the validity from the old key. (This propagation happens > > irrespective of whether the old key is marked as a trusted introducer.) > > > > In effect, the signatures on your old key automatically get applied to > > your new key. This is an easy way to inherit the signatures from the old > > web of trust. The new keys do not have to start from scratch, as implied > > above. I have now tried this and either Hal's response is non-responsive to my concern or I did something wrong. With Eudora PGP 5.0 and the pay RSA addition for Eudora PGP 5.0, I ran PGP keys. I generated a new ElGamal key pair with the same name and internet address as my 1024 bit RSA key that had been signed by Schiller et al. I then made the old key the default key and signed the new key with it. The signatures were NOT transferred to the new key, as I had thought on reading Hal Finney's solution to the issue I raised. Perhaps Hal intended to be taken literally. Perhaps the VALIDITY of my old key is transferred to my new key in the isolation of my own keyring. The signatures certainly were not, in effect or otherwise. And none of the signatures on other people's keys could be transferred in this way. My new key did not carry the old signatures, and if I then send it to a keyserver it doesn't carry the signatures on the old key. As I at first said, the web of trust (as represented by signatures on keys) and all the signatures on the old RSA key has been lost to the new key structure. What is more, this transfer of trust doesn't apply to any keys not my own on my own key ring. Thus any web of trust, signatures, etc. on the old RSA key are lost as far as any usefulness is concerned once I switch to Free PGP 5.53. As I said before Hal's response, PGP Inc HAS disenfranchised all the old web of trust, the old network of signatures, and the old network of keys in PGP 5.53. Everyone has to get new keys and to restore any semblance of the old web of trust has to get new keys from all their correspondents in order to communicate, and the correspondents (namely everyone) all have to get new signatures on their keys, etc. for the transitive character of the web of trust to work. I cannot believe Hal (of whom I have a high opinion) would be so non-responsive and misdirective to the concern I had raised. I must have misunderstood him and done something wrong. Please tell me what it was. As for Open PGP, if I didn't misunderstand Hal this would certainly not be a way to preserve signature and key structure in the presence of algorithmic change or updating. David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA13945 for ietf-open-pgp-bks; Thu, 27 Nov 1997 20:22:48 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA13941 for ; Thu, 27 Nov 1997 20:22:43 -0800 (PST) Received: from s20.term1.sb.rain.org (s28.term2.sb.rain.org [198.68.144.188]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id UAA16920; Thu, 27 Nov 1997 20:25:31 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id UAA03658; Thu, 27 Nov 1997 20:07:53 -0800 Date: Thu, 27 Nov 1997 20:07:53 -0800 From: Hal Finney Message-Id: <199711280407.UAA03658@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, lindsay@powerup.com.au Subject: Re: expedience, consensus and editing Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lindsay Mathieson, , writes, quoting me: > > - There is no PGP/MIME encoding of a detached signature > > > > - There is no PGP/MIME encoding of a non-clear signed message > > ? Both points are clearly addressed (and doable) in RFC 1847 & RFC2015, which > are PGP/MIME (aren't they ?) Could you explain how the following detached signature would be encoded using RFC1847/RFC2015? Would you use multipart/signed or multipart/encrypted? -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 iQA/AwUBNH5DH7qVexb8FGk/EQKTagCg9NwSygbmXdVts7NbIyPkaX9p65QAn2Lu DTwZos6GWUDnplXYbZXolxLY =hgt3 -----END PGP SIGNATURE----- Thanks, Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA12342 for ietf-open-pgp-bks; Thu, 27 Nov 1997 16:10:03 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA12327 for ; Thu, 27 Nov 1997 16:09:56 -0800 (PST) Message-Id: <199711280009.QAA12327@mail.proper.com> Received: (qmail 29721 invoked from network); 28 Nov 1997 00:11:16 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 28 Nov 1997 00:11:16 -0000 Date: 28 Nov 1997 1:1:26 GMT From: Lindsay Mathieson Subject: Re: PGP/MIME2 To: Ian Brown , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 X-Priority: 3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >This is an interesting point. RFC 1847 is elegant, but it seems that >no-one else is following it. If S/MIME isn't S/MIME is, and also some email apps implement it >However, for simply wrapping >PGP data, we could have an application/pgp-data type. I would strongly protest the use of application/pgp-data type or application/anything. The trouble with using the MIME application type is that is limits you to a string of binary octets, which basically restricts us to plain text *or* a file. Whereas multipart/encrypted (RFC 1847) contains a single MIME object, and that MIME object can contain anything - plain text *and* rich text *and* file attachments. And they can all be collectively signed. Having said this I also believe specifying a transport protocol is out of the scope of this spec. Its a complex enough subject that it requires a group of its own. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 28, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA12333 for ietf-open-pgp-bks; Thu, 27 Nov 1997 16:10:00 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id QAA12324 for ; Thu, 27 Nov 1997 16:09:54 -0800 (PST) Message-Id: <199711280009.QAA12324@mail.proper.com> Received: (qmail 29716 invoked from network); 28 Nov 1997 00:11:13 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 28 Nov 1997 00:11:13 -0000 Date: 28 Nov 1997 1:1:26 GMT From: Lindsay Mathieson Subject: Re: Long term contracts To: Ian Grigg , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian, usage of MIME RFC 1847 (multipart/signed) could probably fit your needs for human readable clear signed documents, that fit in a single file. Contrary to what people have been saying, MIME messages can be stored in a single file - in fact thats a natural storage medium for them. One of MIME's purposes was to flatten out multipart messages (text & attachments) so they can be streamed over a connection. The MIME stream (or file) contains formatting information which makes it easy to break out the original components. Included below is a example of a clear text signed message: Example message: From: Michael Elkins To: Michael Elkins Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =A1Hola! Did you know that talking to yourself is a sign of senility? It's generally a good idea to encode lines that begin with From=20because some mail transport agents will insert a greater- than (>) sign, thus invalidating the signature. Also, in some cases it might be desirable to encode any =20 trailing whitespace that occurs on lines in order to ensure =20 that the message signature is not invalidated when passing =20 a gateway that modifies such whitespace (like BITNET). =20 me --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC// jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn HOxEa44b+EI= =ndaj -----END PGP MESSAGE----- --bar-- In this example the text is quoted printable encoded, but it could be left unencoded. QP is recommended for 7 bit transport over the internet though. However this is not an issue if you are storing locally. I'm no expert on cryptography, but I do have considerable experience in implementing MIME. Feel free to grill me on the subject. Cheers - Linz -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 28, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA11615 for ietf-open-pgp-bks; Thu, 27 Nov 1997 14:09:54 -0800 (PST) Received: from dfw-ix8.ix.netcom.com (dfw-ix8.ix.netcom.com [206.214.98.8]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA11611 for ; Thu, 27 Nov 1997 14:09:51 -0800 (PST) Received: (from smap@localhost) by dfw-ix8.ix.netcom.com (8.8.4/8.8.4) id QAA04334 for ; Thu, 27 Nov 1997 16:10:41 -0600 (CST) Received: from lax-ca69-33.ix.netcom.com(207.223.161.161) by dfw-ix8.ix.netcom.com via smap (V1.3) id rma004328; Thu Nov 27 16:10:20 1997 Message-ID: <347DEFD3.39271D4F@sternlight.com> Date: Thu, 27 Nov 1997 14:11:08 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: The web of trust has no clothes. Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms7CA68B5A3370106763E0EEAF" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms7CA68B5A3370106763E0EEAF Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Ed Stone wrote in comp.security.pgp.discuss: > I believe this is a definitive response to the unsupported assertion that the > web of trust is "broken" by new versions of PGP. I respond to Finney, not Stone. I copy this to the open pgp list not only because Finney's post appeared there (in response to mine--I throw no stones by that remark), but also because there may be some valuable lessons here for Open PGP development. > > > From OpenPGP list: > > Date: Mon, 24 Nov 1997 22:08:00 -0800 > From: Hal Finney > To: ietf-open-pgp@imc.org > Subject: Re: The web of trust has no clothes. > Sender: owner-ietf-open-pgp@imc.org > > PGP 5.X implements an extension to the trust model to address the issue > raised by David Sternlight. > > > Another flaw in the web of trust and PGP is now revealed and comes home > > to roost. Now that PGP Inc. has deep-sixed RSA in new free versions, > > not only does everyone with an old RSA key have to generate a new key > > but also a complete new set of signatures and web of trust must be built > > if they wish to use the "better" algorithms. And the new keys must be > > distributed to correspondents, either directly or by "pull" from > > servers. This took years the first time--perhaps the second time it will > > be a bit faster. > > The way it works is as follows. If you have two keys with identical > userids, and the first key signs the second userid, then validity from > the signatures on the first user ID gets propagated to the second userid. > The effect is that if you generate a new DSA key with the same name > as your old RSA key, and sign it with your old key, then your new key > inherits the validity from the old key. (This propagation happens > irrespective of whether the old key is marked as a trusted introducer.) > > In effect, the signatures on your old key automatically get applied to > your new key. This is an easy way to inherit the signatures from the old > web of trust. The new keys do not have to start from scratch, as implied > above. Since I've been somewhat critical of Jeff Schiller recently in the context of IETF actions toward RSADSI with respect to S/MIME and also the disabling of RSA key generation in MIT PGP 5.0, perhaps he'd not like to sign my newer keys and maybe even regrets he signed my earlier PGP key. WIth this feature , I can get him to "sign" my new keys iinvoluntarily. What is more, I can arrange that my new key, like my old one, has no expiration date, further locking Jeff in. (Nothing personal--this is a notional example with details to fix ideas.)The approach you adopted forces the entire user base to generate new keys if they wish the features of free 5.5x, and transfers trust in this somewhat disadvantageous way for free 5.0. It also cuts off first-time PGP users choosing 5.0 and all users of free 5.5x from two-way secure communication with those who wish to maintain their RSA keys for compatibility with what appears likely to be a much larger global user base for quite some time. It also allows the propagation of questionable signatures to the new web of trust at the option of the person with the signed key rather than the signer of the key. Finally, unless and until the new versions find their way somehow to international users at scale, it cuts that base off completely from even the possibility of two-way communication with first-time free 5.0 users and all free 5.5x users. I do not think this a very pretty picture, nor particularly considerate of the existing RSA-key user base which made your reputation. > There may be some concern that this would introduce certain kinds of > spoofing attacks. Let us assume that the old signatures are valid, they may have been originally but the signer may have wished subsequently to invalidate them for either substantive or personal reasons. Since old PGP keys have no expiration dates and there was no CRL mechanism originally, this is weak. Better if you're going to start a new key structure to require new signatures. I recognize that this seems to contradict my comment about obsoleting the old web to trust, but I'd argue PGP should have preserved compatibility with the old web via compatibility with the old keys, while making the new key structure possible in Free PGP, thus providing a graceful and user-driven upgrade path rather than an imposed one. The method described above is, instead, a kludge to attempt to avoid one of the more egregious consequences of what I think to have been a mistake in the first place. I believe the direction Open PGP is moving in allows for many agreed algorithms including "Classical" RSA-IDEA PGP, with appropriate flags to enable two-way usage, and a backwards compatible upgrade path. If this is both true and preserved as the group goes about its business, this would be a Good Thing. I would suggest both in light of the realities of the existing user base and on principle that Open PGP include Classical PGP as either a "should" or a "must". This would not violate what I understand to be the real ground rule: non-discriminatory access to intellectual property on reasonable terms. If there is some difficulty in negotiating such terms, the date of coming into effect of such a "must" provision could be the expiration date of the RSA patent (for example). GIven empirically-based time tables for the completion of the group's work, and likely implementation times thereafter, I think this could be a practical approach. > that the old key is in fact properly bound to the userid. (If the old > signatures are invalid, no one should trust them anyway, so they have no > impact on the web of trust.) Not so fast. See above. > Now, when that old key issues a signature > on the same userid on another key, it is in effect asserting that the > same keyholder controls this other key. > > If the other key actually does belong to the same keyholder, then there > is no danger in transferring validity from the signatures on the old > key over to the new one. The new key is in fact valid, and so measures > which show it as valid are proper. See above. Also, that PGP recognizes the importance of expiry is shown by the option to add an expiration date to newly generated keys > Hal Finney > hal@pgp.com While I've got you, Hal, why did PGP disable RSA key generation in free 5.0? Why did they omit RSA entirely in free 5.5x? Why is it an extra-cost option in pay 5.5? It it the intention to drop it completely in 6.x? It would be good to have an authoritative explanation. I think this would be of interest to all the groups in this distribution, since even the Open PGP folks can benefit from understanding PGP Inc.'s thinking and intentions with respect to its products. David --------------ms7CA68B5A3370106763E0EEAF Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKjQYJKoZIhvcNAQcCoIIKfjCCCnoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CIUwggPPMIIDOKADAgECAhAnuK6izE0BOIf7uTQQ8usCMA0GCSqGSIb3DQEBAgUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA4MjEwMDAw MDBaFw05ODA4MjEyMzU5NTlaMIIBEjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDIgLSBOZXRzY2FwZTEZMBcGA1UEAxMQRGF2aWQgU3Rlcm5saWdodDEjMCEGCSqGSIb3 DQEJARYUZGF2aWRAc3Rlcm5saWdodC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN09h1fHJlSiS54oM5YjKy9J6wMmjUFL58Xkwc6JiCBftinxpbm2ziTPSAn4TMhSVbZnuC1m oDZln2HSvkRS61+BwYL3yw9kus2/Tyoi4gparm1O+CRlRkudAP8w7cHax6AZXTr7KDQA/mOq nXSPERdO3XZIgvVRXvL7VIVt++F7AgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0gBIGn MIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24A AAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBAgUAA4GBAE8QvB3wHstP4Ggj +WuQRdIKOsO4U3F5mUjfle6hatqCA1fvD3Kzmrr4KSvBes2CH0BKV/Mmb/rRkkwXaspTkSIC 0ENT789yEuv/aoOVogJVaKYHz7bgNkSuwa6O8SKHkrGHdQRxl3J+GN1SEgOzkW7A15d702QM 0tR6rtxMvtxYMIICeTCCAeKgAwIBAgIQUNNSlJEvedMV4ysxrIVI8DANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3 MDAwMDAwWhcNOTgwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlk dWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+b yB2eT7R1731MMPOyqjS/mdtGxtSYxx1FDuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqt WhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCI cp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCG SAGG+EIBAQQEAwICBDANBgkqhkiG9w0BAQIFAAOBgQAN6OSPQTmZ8ouFAbfodckgYj0dsq43 RhipxsLh/k6LwgZbQUbv8sxw0AEqFp5AUak+wBPYFljrwLCW/qnQZbM1RsFBCP6IlPSbtgyv YbUZrIGeVCdsNpBTxypskPapJdjkip4YXyd8jdn10TX+OZmd7OjE9vRuXjCXTgiI0JmvnzCC AjEwggGaAgUCowAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFg a355LPoGDzqu9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fM CGw/PrNK/P9LbCPVUIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQAD gYEAe6+kHC/Amw47XPyo5tGWD0hySYXlrxojAOPpu4A0bLI/hKg8cnCzTN5z+nyE0pKlADcJ wgM0IwO37XaW3D5Phf1YF/QEvuxRHtx629uu6GF42mU4R6wdA3Bt6eO7oEqfQOq823O/Z01d xnwgXOfoogorwgl010z+2+lrAmNdOacxggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVy bmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQJ7iuosxNATiH+7k0EPLrAjAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTEy NzIyMTExMlowIwYJKoZIhvcNAQkEMRYEFK4jtql7Q+Eq1zzKHiEvAlflwltaMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAx/0NOA4O3KG28KfzLazR SbiFm2lsSOgQCPjvxkkwvQC6MFs53/LLcv8tjm2Xqrh4IiAUpNZY0kwdcZf9ChtpGB0Jnj0o 24SKVVKKGFDMl9VmBcxdbv/7QHyuqYInHtUDGqtaM20U0asmOi7/FPGmbg86MPS5zxmCLkHO Mx2fBXc= --------------ms7CA68B5A3370106763E0EEAF-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA10831 for ietf-open-pgp-bks; Thu, 27 Nov 1997 11:43:36 -0800 (PST) Received: from khms.westfalen.de (mail@khms.westfalen.de [195.52.199.20]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA10827 for ; Thu, 27 Nov 1997 11:43:31 -0800 (PST) Received: from root by khms.westfalen.de with bsmtp (Exim 1.73 #1) id 0xb9ri-0006jh-01 (Debian); Thu, 27 Nov 1997 20:44:46 +0100 Received: by khms.westfalen.de (CrossPoint v3.11 R/C435); 27 Nov 1997 20:42:27 +0200 Date: 27 Nov 1997 20:23:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf-open-pgp@imc.org Message-ID: <6ieFqiBHw-B@khms.westfalen.de> In-Reply-To: Subject: Re: The armour issue X-Mailer: CrossPoint v3.11 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? References: X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk frantz@netcom.com (Bill Frantz) wrote on 26.11.97 in : > The first piece of signed code I ever got was MacPGP 2.6.2. I like the > idea of detached signatures on executable files. One use I can see is > signing every executable on your system and storing the signatures > separately. Then you can periodically check the system for altered code. > (Too bad Mac code normally alters itself.) > > How do armor and MIME compare in their support of this application? You don't need either one for that functionality. Binary is quite ok. And as both do nearly exactly the same thing, you could easily use both. MfG Kai Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA10255 for ietf-open-pgp-bks; Thu, 27 Nov 1997 10:11:35 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA10247 for ; Thu, 27 Nov 1997 10:11:27 -0800 (PST) Received: from omni.imc.org (pm3-22.netgate.net [205.214.163.22]) by proper.com (8.8.7/8.7.3) with SMTP id KAA02938; Thu, 27 Nov 1997 10:09:21 -0800 (PST) Message-Id: <199711271809.KAA02938@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Release Candidate 3 Date: Thu, 27 Nov 1997 10:11:06 -0800 To: Ian Grigg From: Dave Crocker / IMC Subject: Re: Long term contracts Cc: ietf-open-pgp@imc.org, I.Brown@cs.ucl.ac.uk In-Reply-To: <347DACC4.13728473@systemics.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 05:24 PM 11/27/97 +0000, Ian Grigg wrote: >Ian: >> Ian Grigg's point in favour of armour is that clearsigned documents are ... >(I think it can be hacked into the MIME format, but thinking about it, >there is more to it than that.) I assume that 'clearsigned' means the text is kept in the clear? That is exactly the purpose behind multipart/signed. There is no 'hacking' needed. The MIME mechanism is already supplied. S/MIME uses is. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA09745 for ietf-open-pgp-bks; Thu, 27 Nov 1997 09:20:27 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA09737 for ; Thu, 27 Nov 1997 09:20:21 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id TAA03577; Thu, 27 Nov 1997 19:47:36 +0100 (MET) Message-ID: <347DACC4.13728473@systemics.com> Date: Thu, 27 Nov 1997 17:24:20 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org CC: I.Brown@cs.ucl.ac.uk Subject: Long term contracts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian: > Ian Grigg's point in favour of armour is that clearsigned documents are > useful. Fair enough; Ian can buy/write an application which includes > this functionality. It does not need to be a MUST. As Adam just said, it > would be simple to do the same with MIME. (I think it can be hacked into the MIME format, but thinking about it, there is more to it than that.) A contract is a self contained document that can be readily proven to be what it says it is. It uses embedded inline sigs because they cannot be lost over time, and it can survive many different copying techniques. Note how the preceeding comment holds for paper documents and pgp clearsigned messages, but not for attachments and separated sigs. One of the design criterion is that the method of cleartext signing must be ubiquitous. Under current world conditions the method used is, as pgp2.6 and pgp5.0 can read the clearsigned sigs. If however, armour is phased out, and MIME is not up to the job, then the application is broken. The reason for this is that you have to write a contract now, and validate it in the unforeseeable future, using independant software available anywhere. Just like on paper. We are trying to replace the eyeball, and this has rather tricky demands on software. When we designed the methods to do the contract, a reasonable assumption was that "pgp2.6 will be available for a long time." It was set up over worldwide net sites to defend itself from the worst ravages of governments. I never in my wildest dreams guessed that PRZ and Company would be the ones to .... Now, the alternative is to assume that PGP/MIME or S/MIME will take over. This is far to risky a bet, obviously, as there are already two choices there, and with the addition of the incumbent, that makes three. No rational business case can be made at this stage that either of these are strong enough to win. Add to that the decision of this group to abandon RSA sigs, along with the commercial activities of PGP Inc to deliver the coup de grace and I suspect the signing of long term commercial contracts is now a broken application. Which is ammusing as I just today submitted my paper to FC98 on how good an application this is (and received confirmation that it is in the post :-) Better I find out now than at the conference I suppose... -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA09404 for ietf-open-pgp-bks; Thu, 27 Nov 1997 08:57:28 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA09397 for ; Thu, 27 Nov 1997 08:57:02 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Nov 1997 16:58:08 +0000 Message-ID: <347DA601.73864E7B@cs.ucl.ac.uk> Date: Thu, 27 Nov 1997 16:55:29 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Bill Stewart CC: IETF OpenPGP Subject: Re: The armour issue References: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> <3.0.3.32.19971126162310.0070ce30@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > A typical Web-based PGP application requires the user to cut&paste a > PGP key or PGP-encrypted message into a web form and submit it. Have a look at RFC 1867: Form-based File Upload in HTML. I believe Netscape implements it, not sure about the rest. This would be great for uploading binary key files. > There's also the problem of sending PGP keys in email messages... > It's really much cleaner if you've got a format that can stay inlined Could we use application/pgp-keys inlined? Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA08263 for ietf-open-pgp-bks; Thu, 27 Nov 1997 07:19:50 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA08258 for ; Thu, 27 Nov 1997 07:19:44 -0800 (PST) Message-Id: <199711271519.HAA08258@mail.proper.com> Received: (qmail 12215 invoked from network); 27 Nov 1997 15:21:01 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 27 Nov 1997 15:21:01 -0000 Date: 28 Nov 1997 16:11:17 GMT From: Lindsay Mathieson Subject: Re: PGP/MIME2 To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Sorry. I also proposed to create text/pgp and >application/pgp-encrypted. Also the text type is usually used to indicate a text format as well, e.g. text/html or text/etf. text/pgp would effectively be limited to plain text. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 28, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA07650 for ietf-open-pgp-bks; Thu, 27 Nov 1997 06:27:42 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA07643 for ; Thu, 27 Nov 1997 06:27:34 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id PAA29256; Thu, 27 Nov 1997 15:28:46 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@belenus.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Armour Date: 27 Nov 1997 14:28:46 GMT Organization: IKS GmbH Jena Lines: 8 Message-ID: References: NNTP-Posting-Host: belenus.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * David Formosa wrote: >If this was so we could have a complient OPEN-PGP softwhere with no >'presentation layer'. This would not be able to interoperate with >anything and therefore in an internet context be useless. We MUST have a >MUST have some form of protection threw the vegeries of transport. ;-) Leave the presentation layer in the user agent and do the cryptographic work on raw binary. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA07262 for ietf-open-pgp-bks; Thu, 27 Nov 1997 05:50:35 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA07257 for ; Thu, 27 Nov 1997 05:50:28 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Nov 1997 13:51:31 +0000 Message-ID: <347D7A4A.7A9EB27E@cs.ucl.ac.uk> Date: Thu, 27 Nov 1997 13:48:58 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: IETF OpenPGP Subject: Re: PGP/MIME2 References: <347D4DA6.44C31B20@cs.ucl.ac.uk> <19971127214542T.kazu@Mew.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Kazu wrote: > If the discussion should be repeated, it would like to know how > situation is changed comparing one year ago. The difference this time is that armour is unlikely to be a MUST in OP. So it shouldn't be a MUST in a standard that OP references. > S/MIME is now coming and it does not use multipart/encrypted but > application/pkcs7-mime. So, the alignment of PGP/MIME becomes > meaningless from the implementation view of point. This is an interesting point. RFC 1847 is elegant, but it seems that no-one else is following it. If S/MIME isn't, I don't think there is an absolute need for us to do so. I may be at risk of starting a religious war even worse than the one over armour here ;-) but I can see many ways in which it would be useful NOT to follow that model. Particularly from the point of view of mailers which do not explicitly understand PGP/MIME, but do understand MIME - such as that 25 million base we keep hearing about. We need two things from MIME: the ability to send raw PGP binary data, and the ability to send clearsigned messages. It is also nice if, in the manner of PGP/MIME, we have a separate content-type for keys so that, as Peter Gutmann suggested, we can have separate key management programs if desired. We could keep the application/pgp-keys content-type, and use the multipart/signed mechanism largely as-is. However, for simply wrapping PGP data, we could have an application/pgp-data type. This would simply be data which, once the transfer encoding had been removed by the mailer, could be presented to an OP application which would then be able to process it. Then, *any* MIME-compliant mailer could be configured by its users so that when it receives an application/pgp-data bodypart, it removes the transfer encoding then executes a user-specified OP program with the data as input. A message could contain any number of such bodyparts. This obviously needs work, but I hope it's a gem of an idea. Comments? Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA06895 for ietf-open-pgp-bks; Thu, 27 Nov 1997 05:10:53 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA06836 for ; Thu, 27 Nov 1997 05:04:20 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id OAA27046; Thu, 27 Nov 1997 14:05:08 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@belenus.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: V4 Fingerprints Date: 27 Nov 1997 13:05:08 GMT Organization: IKS GmbH Jena Lines: 7 Message-ID: References: <19971125184910.42970@sobolev.rhein.de> NNTP-Posting-Host: belenus.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Thomas Roessler wrote: >This seems to imply that the fingerprint is always >generated as the hash over an old-style public key packet >with a two-byte length qualifier and the appropriate >packet tag. Is this correct and intended? Unfortunly: Yes. I documented it in the interim draft explicitly. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA06769 for ietf-open-pgp-bks; Thu, 27 Nov 1997 04:55:36 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA06765 for ; Thu, 27 Nov 1997 04:55:31 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id XAA09646; Thu, 27 Nov 1997 23:55:18 +1100 Received: from shirley (dformosa@dialin-29 [137.154.130.29]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id XAA15307; Thu, 27 Nov 1997 23:55:16 +1100 (EST) Date: Thu, 27 Nov 1997 22:39:15 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Adam Back cc: ietf-open-pgp@imc.org Subject: Re: Armour In-Reply-To: <199711262051.UAA05360@server.test.net> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Wed, 26 Nov 1997, Adam Back wrote: [...] > I think neither MIME nor Armor should be MUST. Both MAY. You could > argue for SHOULD for backwards compatibility. If this was so we could have a complient OPEN-PGP softwhere with no 'presentation layer'. This would not be able to interoperate with anything and therefore in an internet context be useless. We MUST have a MUST have some form of protection threw the vegeries of transport. Currently I'm favouring MUST mime for interoprabilty with the future and SHOULD for interoperablity with the present and past versons. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNH1b56QK0ynCmdStAQGWDwQA19MfD1WTgksLF8AUP6RotA3FPgq0qnDO FrNjDNIv6r4xUUAXm3P1ndwiWm3dSy8HuibUi9aONSl70DQcRuSweGQRzyCV/4EH mWcJ7OZgSsYeioMMYiLN5/Q98Q3L8jfCSn90XN2IOjN9EvoA9UWWD74fzfvFLKTG fbmdU6s3Bo8= =27pd -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA06675 for ietf-open-pgp-bks; Thu, 27 Nov 1997 04:44:46 -0800 (PST) Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA06671 for ; Thu, 27 Nov 1997 04:44:42 -0800 (PST) Received: from localhost (localhost.aist-nara.ac.jp [127.0.0.1]) by mine.aist-nara.ac.jp (8.8.5/8.8.5) with ESMTP id VAA13055 for ; Thu, 27 Nov 1997 21:45:43 +0900 (JST) To: ietf-open-pgp@imc.org Subject: Re: PGP/MIME2 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Thu, 27 Nov 1997 10:38:31 +0000" <347D4DA6.44C31B20@cs.ucl.ac.uk> References: <347D4DA6.44C31B20@cs.ucl.ac.uk> X-Mailer: Mew version 1.93b1 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19971127214542T.kazu@Mew.org> Date: Thu, 27 Nov 1997 21:45:42 +0900 X-Dispatcher: imput version 971106 Lines: 39 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk From: Ian Brown Subject: PGP/MIME2 Date: Thu, 27 Nov 1997 10:38:31 +0000 > Hal is right. PGP/MIME needs work on: > > - Removing the requirement for armor, if it is not going to be a MUST in > OP. Actually I proposed usage of MIME base64 instead of PGP armor on the ietf-pgp-mime ml before RFC 2015 was published. At that time, only one person supported my proposal. And many rejected it. I'm afraid that we are repeating the same discussion again. Also, I wonder why Dave Crocker did not support my proposal explicitly at that time. If the discussion should be repeated, it would like to know how situation is changed comparing one year ago. > - Defining new content-types for the types of OP data which are not > currently covered - detached signatures, non-clearsigned messages, maybe > others. Sorry. I also proposed to create text/pgp and application/pgp-encrypted. Since some guys arose objections against the proliferation of content type, this idea was not included in RFC 2015. The author of RFC 2015 was particular to alignment to security multipart. Multipart/encrypted was adopted though its first part is mostly empty. S/MIME is now coming and it does not use multipart/encrypted but application/pkcs7-mime. So, the alignment of PGP/MIME becomes meaningless from the implementation view of point. --Kazu Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA06646 for ietf-open-pgp-bks; Thu, 27 Nov 1997 04:40:09 -0800 (PST) Received: from grannus.iks-jena.de (grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA06633 for ; Thu, 27 Nov 1997 04:39:41 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id NAA26413; Thu, 27 Nov 1997 13:40:21 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@belenus.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: expedience, consensus and editing Date: 27 Nov 1997 12:40:21 GMT Organization: IKS GmbH Jena Lines: 18 Message-ID: References: <199711262108.VAA05371@server.test.net> NNTP-Posting-Host: belenus.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Adam Back wrote: >1) armor MAY/SHOULD/MUST? MAY be generated and SHOULD be read. >2) MIME as MAY/SHOULD/MUST? Has nothing to do with OpenPGP. OpenPGP deals with the application layer not with the presentation layer MIME is for. Same goes for Ascii Armor. >3) 32 bit int clean up shelved for OpenPGPv2, or discussed now 32bit is an unnecessary restriction. (640k are enough for everybody!) >4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2, Drop it completely but mark the subsignature ID as in use. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA06323 for ietf-open-pgp-bks; Thu, 27 Nov 1997 03:55:08 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA06319 for ; Thu, 27 Nov 1997 03:55:04 -0800 (PST) Message-Id: <199711271155.DAA06319@mail.proper.com> Received: (qmail 18306 invoked from network); 27 Nov 1997 11:56:18 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 27 Nov 1997 11:56:18 -0000 Date: 27 Nov 1997 12:46:33 GMT From: Lindsay Mathieson Subject: Re: expedience, consensus and editing To: Hal Finney , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > - There is no PGP/MIME encoding of a detached signature > > - There is no PGP/MIME encoding of a non-clear signed message ? Both points are clearly addressed (and doable) in RFC 1847 & RFC2015, which are PGP/MIME (aren't they ?) -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 27, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA04789 for ietf-open-pgp-bks; Thu, 27 Nov 1997 02:41:11 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA04785 for ; Thu, 27 Nov 1997 02:41:07 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Nov 1997 10:42:02 +0000 Message-ID: <347D4DA6.44C31B20@cs.ucl.ac.uk> Date: Thu, 27 Nov 1997 10:38:31 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org Subject: PGP/MIME2 References: <199711262254.OAA32742@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal is right. PGP/MIME needs work on: - Removing the requirement for armor, if it is not going to be a MUST in OP. - Defining new content-types for the types of OP data which are not currently covered - detached signatures, non-clearsigned messages, maybe others. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA04493 for ietf-open-pgp-bks; Thu, 27 Nov 1997 02:04:41 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA04484 for ; Thu, 27 Nov 1997 02:04:37 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Nov 1997 10:05:38 +0000 Message-ID: <347D4520.72C5D261@cs.ucl.ac.uk> Date: Thu, 27 Nov 1997 10:02:08 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Gavan Schneider CC: ietf-open-pgp Subject: Re: Armour References: <199711270237.NAA18679@magna.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk If you hadn't noticed, I am now trying to keep all my posts to around a page. A lot of people on this list seem to simply skip anything longer ;-) I agree with Gavin's points, and thought I would just quickly summarise them for said people: > O/PGP cannot define the contents of the file system at large, > but it can define a valid file for its own purposes. Nothing will ever > stop people from sometimes serving the wrong files to an application... > we still need to repack the file if we want to transmit it over the > internet and mime is the way to go in that area. > If it > has not been suggested already let's get multi byte alphabets built into > the standard from the ground up. No late add-on fixits to cater for the > Chinese, Hindu, Japanese... scripts. These are all huge markets and > getting bigger, and I believe there is already an ISO standard for these > alphabets. We don't have to invent this wheel. Just use it and make > O/PGP savvy with it. > >PGP/MIME does not provide methods to > >encapsulate some legal PGP packet structures which were expected not to > >be used for email. > > Propose the packets for inclusion. Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA03084 for ietf-open-pgp-bks; Thu, 27 Nov 1997 01:50:54 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id BAA03080 for ; Thu, 27 Nov 1997 01:50:50 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 27 Nov 1997 09:51:35 +0000 Message-ID: <347D41D6.AC6737AE@cs.ucl.ac.uk> Date: Thu, 27 Nov 1997 09:48:06 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Ng Pheng Siong CC: ietf-open-pgp@imc.org Subject: Re: Armour References: <199711212133.NAA17838@proper.com> <199711270531.NAA11838@pop2.pacific.net.sg> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ng Pheng Siong is right. Another example that Hal has brought up is FTP. As far as I was aware, this uses binary transfer. No need for armour or MIME. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA02010 for ietf-open-pgp-bks; Thu, 27 Nov 1997 00:26:39 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA02004; Thu, 27 Nov 1997 00:26:33 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id KAA02799; Thu, 27 Nov 1997 10:53:52 +0100 (MET) Message-ID: <347D2FAE.1CFBAE39@systemics.com> Date: Thu, 27 Nov 1997 08:30:38 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: dcrocker@imc.org CC: ietf-open-pgp@imc.org Subject: Re: expedience, consensus and editing References: <199711262307.XAA06367@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Crocker writes: > Ok. So you implement armor and I implement MIME. How do we interoperate? Assuming that we have reached a consensus that MIME is a MAY or SHOULD, but not a MUST, then how indeed do we cope? Here's some suggestions. 1. Binary. There is a compatible interoperability mode as long as 8-bit comms is in place. Of course, nobody is going to use it, but this mode at least suits the letter of the IETF dictum that there MUST be a compatibility mode accepted by all. 2. You implement Armour. As you have discussed, it is quite similar, not a technical difficulty at all. One might be able to get buy with a subset. I can probably hunt up some freeware code for you. If you've got to add PGP anyway... 3. Encourage the 4 million to somehow upgrade to MIME MUAs. This is no great difficulty, given the awesome marketing machine that is 25 million and doing very nicely, thank you. 4. Encourage the software developers to implement MIME in older software like pgp2.6. I'm open to bribery. 5. Install ordinary PGP on your machine. Comes with Armour. 6. Switch to cleartext. Comms in the clear is often better than no comms. 7. Don't Communicate. Given the compelling view that 25.1 million MIME users can't be wrong, you shouldn't be too worried about the 4 million older non-MIME users. That's the problem with a broken standard. There'll be so many bypass options to choose from :-) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA01406 for ietf-open-pgp-bks; Wed, 26 Nov 1997 23:50:37 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA01401 for ; Wed, 26 Nov 1997 23:50:32 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id KAA02703; Thu, 27 Nov 1997 10:17:48 +0100 (MET) Message-ID: <347D273C.15FB7483@systemics.com> Date: Thu, 27 Nov 1997 07:54:36 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org Subject: Re: The armour issue References: <199711270055.QAA00816@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney wrote: > There is nothing wrong with a clear-signed MIME message for email. > (Well, maybe it is harder with existing tools to save it to its own > file and verify it again later, but that could be addressed.) Ta. I meant my task actually. Looking at the actual message before my browser munged it, there is enough info there to handle that, with some scripting. So it's technically possible to do, question remains whether it is desirable (again, for this application) which means examining all of the other factors. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA01297 for ietf-open-pgp-bks; Wed, 26 Nov 1997 23:40:55 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA01293 for ; Wed, 26 Nov 1997 23:40:50 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id KAA02667; Thu, 27 Nov 1997 10:08:01 +0100 (MET) Message-ID: <347D24F0.794BDF32@systemics.com> Date: Thu, 27 Nov 1997 07:44:48 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Bill Stewart CC: IETF OpenPGP Subject: Re: The armour issue References: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> <3.0.3.32.19971126162310.0070ce30@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart wrote: > Surely you're not planning to FAX your keys in these days of Email?! Actually, yes :-) I see a world of lawyers with printed paper contracts with embedded cleartext signatures, which they can fax around, then scan in and run through pgp as soon as they need to check the signature. One would like to get them to use email, but... in has a plan to sell as paper documents with ascii armoured messages on them, which users scan in, and use pgp to convert into something useful, and then mail them . The reasons for this application are quite amusing... -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA00640 for ietf-open-pgp-bks; Wed, 26 Nov 1997 22:18:29 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA00635 for ; Wed, 26 Nov 1997 22:18:24 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id WAA18242 for ietf-open-pgp@imc.org; Wed, 26 Nov 1997 22:17:10 -0800 Message-ID: <19971126221707.27065@songbird.com> Date: Wed, 26 Nov 1997 22:17:07 -0800 From: Kent Crispin To: ietf-open-pgp@imc.org Subject: Re: The armour issue References: <347CC01C.4A019561@systemics.com> <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> <199711262241.OAA00928@proper.com> <199711270412.UAA01427@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199711270412.UAA01427@proper.com>; from Dave Crocker / IMC on Wed, Nov 26, 1997 at 07:55:50PM -0800 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, Nov 26, 1997 at 07:55:50PM -0800, Dave Crocker / IMC wrote: > > >How do armor and MIME compare in their support of this application? > > yes, it would be nice if folks developed some familiarity with the relevant > aspects of MIME. I think the request was for worked out examples. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA00293 for ietf-open-pgp-bks; Wed, 26 Nov 1997 21:30:27 -0800 (PST) Received: from soran.pacific.net.sg (soran.pacific.net.sg [203.120.90.76]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA00289 for ; Wed, 26 Nov 1997 21:30:22 -0800 (PST) Received: from pop2.pacific.net.sg (pop2.pacific.net.sg [203.120.90.86]) by soran.pacific.net.sg with ESMTP id NAA18962; Thu, 27 Nov 1997 13:31:33 +0800 (SGT) Received: from ngps (dyn81ppp218.pacific.net.sg [210.24.81.218]) by pop2.pacific.net.sg with SMTP id NAA11838; Thu, 27 Nov 1997 13:31:25 +0800 (SGT) Message-Id: <199711270531.NAA11838@pop2.pacific.net.sg> Comments: Authenticated sender is From: "Ng Pheng Siong" To: Jeremey Barrett Date: Thu, 27 Nov 1997 13:26:14 -0800 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: Armour CC: ietf-open-pgp@imc.org In-reply-to: <199711212219.OAA04747@einstein.bluemoney.com> References: <199711212133.NAA17838@proper.com> X-mailer: Pegasus Mail for Win32 (v2.54) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > I thought we were discussing PGP, not email. Last time I checked noone > has implemented file encryption, or encrypted archiving tools, or > remailers, or keyservers, or nym servers, or anything other than > email (and on occasion news) using MIME. Nor should they. I think we are discussing if armour should be a MUST in OPGP. I've been following this debate off and on. Just one question: are you saying that armour is a MUST to implement the stuff in your example list? File encryption: pgp binary format. Encrypted archiving tool: Tar or zip (or some proprietary archival format), then pgp-encrypt (or des, or oily-crypt) the archive. No armour. Remailers: 1. If talking via SMTP, then this is about email. 2. Mixmaster uses its own binary format - no armour. Keyservers: Historically, ftp interface - no armour; email interface - armour; WWW interface - armour carried in text/plaintext. LDAP - is armour necessary? How does PGP 5.x do it? Nymservers: Haven't played with these; any example? Likely interfaces are, again, email, WWW, or LDAP. Does Perl's Penguin use armour? If something like Penguin is implemented natively (i.e., doing the pgp bits directly, instead of invoking an external pgp app), armour is not needed. > PGP is a powerful tool, used in many different ways. ONE of them is > vanilla email. ALL of them benefit from ASCII armoring. ASCII armoring > is essential to the survival of PGP and to the security of the "PGP > system", and the many systems built on top of it now and in the future. Too many topic sentences in one paragraph. ;-) "ALL of them" benefit from armouring: I think this point has not been clearly established. Armour "essential" to survival of PGP and to "security of the "PGP system"": Ditto. > One can implement MIME support without "switching to it". PGP/MIME is > good. PGP/MIME SHOULD be done. ASCII armor MUST be done. If there is no consensus, surely armour support must not be a MUST, but should be a SHOULD. Whether armour is MUST or SHOULD, nobody will produce an OPGP implementation without armour, IMHO. If somebody does, the market will decide. Ng Pheng Siong Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA29792 for ietf-open-pgp-bks; Wed, 26 Nov 1997 20:14:01 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA29786 for ; Wed, 26 Nov 1997 20:13:55 -0800 (PST) Received: from omni.imc.org (pm3-13.netgate.net [205.214.163.13]) by proper.com (8.8.7/8.7.3) with SMTP id UAA01427 for ; Wed, 26 Nov 1997 20:12:25 -0800 (PST) Message-Id: <199711270412.UAA01427@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Release Candidate 3 Date: Wed, 26 Nov 1997 19:55:50 -0800 To: ietf-open-pgp@imc.org From: Dave Crocker / IMC Subject: Re: The armour issue In-Reply-To: References: <347CC01C.4A019561@systemics.com> <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> <199711262241.OAA00928@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >How do armor and MIME compare in their support of this application? yes, it would be nice if folks developed some familiarity with the relevant aspects of MIME. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA29631 for ietf-open-pgp-bks; Wed, 26 Nov 1997 19:53:41 -0800 (PST) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA29626 for ; Wed, 26 Nov 1997 19:53:38 -0800 (PST) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id VAA15946; Wed, 26 Nov 1997 21:54:05 -0600 (CST) Received: from ffd-ca1-10.ix.netcom.com(205.186.177.42) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma015845; Wed Nov 26 21:52:09 1997 Message-Id: <3.0.3.32.19971126195018.006a30c0@popd.netcruiser> X-Sender: JonWienk@popd.netcruiser X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 26 Nov 1997 19:50:18 -0800 To: Bill Frantz , ietf-open-pgp@imc.org From: Jonathan Wienke Subject: Re: The armour issue In-Reply-To: References: <347CC01C.4A019561@systemics.com> <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> <199711262241.OAA00928@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 07:04 PM 11/26/97 -0800, Bill Frantz wrote: >The first piece of signed code I ever got was MacPGP 2.6.2. I like the >idea of detached signatures on executable files. One use I can see is >signing every executable on your system and storing the signatures >separately. Then you can periodically check the system for altered code. >(Too bad Mac code normally alters itself.) This could be the basis of an extremely secure anti-virus scanner. If the signature key and verification program are kept only on a write-protected floppy disk that is not usually in the computer, it would be extremely difficult for a virus/trojan to alter a file without your knowledge. >How do armor and MIME compare in their support of this application? Binary is the way to go here. MIME and armor are irrelevant and unnecessary in an environment capable of handling 32-bit binary data. Save them for primitive systems that cannot yet deal with 8-bit data. -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBNHzt+MJF0kXqpw3MEQJShACfaRWXyfMimpZ5Z9M73y8z/G5TVNsAoPf4 9nfQZThG2pwkBnTLzBV3qWkQ =Lrbl -----END PGP SIGNATURE----- Jonathan Wienke PGP Key Fingerprints: 7484 2FB7 7588 ACD1 3A8F 778A 7407 2928 3312 6597 8258 9A9E D9FA 4878 C245 D245 EAA7 0DCC "If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home from us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you. May your chains set lightly upon you; and may posterity forget that ye were our countrymen." -- Samuel Adams "Stupidity is the one arena of of human achievement where most people fulfill their potential." -- Jonathan Wienke Never sign a contract that contains the phrase "first-born child." RSA export-o-matic: print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Wed, 26 Nov 1997 19:10:23 -0800 (PST) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id VAA21561 for ; Wed, 26 Nov 1997 21:11:06 -0600 (CST) Received: from sjc-ca6-21.ix.netcom.com(207.94.249.213) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma021546; Wed Nov 26 21:11:00 1997 X-Sender: frantz@netcom7.netcom.com Message-Id: In-Reply-To: <347CC01C.4A019561@systemics.com> References: <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> <199711262241.OAA00928@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Nov 1997 19:04:20 -0800 To: ietf-open-pgp@imc.org From: Bill Frantz Subject: Re: The armour issue Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The first piece of signed code I ever got was MacPGP 2.6.2. I like the idea of detached signatures on executable files. One use I can see is signing every executable on your system and storing the signatures separately. Then you can periodically check the system for altered code. (Too bad Mac code normally alters itself.) How do armor and MIME compare in their support of this application? ------------------------------------------------------------------------- Bill Frantz | One party wants to control | Periwinkle -- Consulting (408)356-8506 | what you do in the bedroom,| 16345 Englewood Ave. frantz@netcom.com | the other in the boardroom.| Los Gatos, CA 95032, USA Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA29098 for ietf-open-pgp-bks; Wed, 26 Nov 1997 18:37:45 -0800 (PST) Received: from magna.com.au (mail.magna.com.au [203.4.212.90]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA29088; Wed, 26 Nov 1997 18:37:18 -0800 (PST) Received: from [203.10.19.150] (schneider.magna.com.au [203.10.19.150]) by magna.com.au (8.8.5/8.6.10) with SMTP id NAA18679; Thu, 27 Nov 1997 13:37:45 +1100 (EST) Message-Id: <199711270237.NAA18679@magna.com.au> Subject: Re: Armour Date: Thu, 27 Nov 97 13:37:46 +1100 x-mailer: Claris Emailer 2.0v2, June 6, 1997 From: Gavan Schneider To: cc: "Hal Finney" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Quoting Hal Finney on or about 1997/11/27 05:28 Sydney time- >Dave Crocker writes: >> 1. Technical >> >> There is no strong argument that either MIME or Armour are superior at >> doing protection against the vagaries of transport. >> >> It is worth noting that Armour combines the control information with >> the data, whereas MIME keeps them separate. This facilitates processing by >> recipients who either do not have the necessary security software or who >> want to defer its use. That is, for authenticated data which is not also >> encrypted, the main data can be kept cleartext whereas with Armour it is not. > >I described several technical objections to the use of MIME which no one >has addressed. > Ok ok I might only qualify for the contingency substitute reserve bench but I will give it a go and see how I go :-) I apologise if I end up creating too much work for others. >Many of them are related to the MIME convention you describe of separating >control information from data. This works well in an email environment, >where such separation is already in place. We have mail headers and body, >and it is natural to add the MIME control information to the headers, >and to put the MIME body parts into the body. This also works for HTTP >and news, which have a similar header/body distinction. > My earlier comments were designed to be for email only. I admit after reading the comment by Jon Callas that my "premise" stating this was poorly expressed but that was my intent. I was not trying to draw a conclusion. Now I will **try** to cover a broader scope. And I am aware from Dave Crocker's separate reply that many of these issues are beyond the remit of the proposed standard. I will try to tie some back to the proposal as best I can. >But this model breaks down when we are in an environment where such >separation does not exist. I used the example of disk files. > I am sure others will comment on this and set me right as appropriate but I find it extremely hard to think of any logical construction which could ever hope to address files in the same breath as email, usenet and web based cgi transactions. #pragma personal_opinion_mode true I will now go right out on a long limb and risk all sorts of fire and brimstone (and this folks, without a helmet :-) and say: A wonderful multi purpose application like PGP 2,3,5 does not fit well into a single standard. (And I expect I am not the first to have thought that!) In my mind the original and subsequent PGP applications all addressed multiple cryptographic needs from a single code base and in doing this came up with the necessary (non cryptographic) fixes like ascii armour just to get the thing to work in the real world. As David Sternlight is so fond of saying Phil Z./PGP Inc. did not invent the cryptographic "bricks", the algorithms. And I always thought that was a feature not a problem. One big achievement of Phil Z./PGP Inc. was to built a "house" with good quality pretested "bricks" and bring it to us at a price we could afford. And more recently to do some "renovations" because some to the original "bricks" are not as good as originally thought :-). I think it would be a nonsense to attempt to codify some version of PGP as a standard. A standard is not an application programming language. What we want from the standard is a well defined result. The result we want is effective cryptography in our existing environments. I do believe this process of defining a standard is a way of thinking about all the different services provided by the PGP application and getting the same benefits in an integrated way along side all the other "standard" ways to achieve specific results. I want to emphasise that I am not claiming any of this is true. I just wanted to say it so you would have a better idea of my mind set and maybe get a better gauge of what I think is so obvious I might never think to say it. Thank you for your forbearance. Please send me my "reeducation camp" bookings in a plain envelope. I do not want my family to be upset :-) #pragma personal_opinion_mode 0.5 >Now, some >people have said that this should not count, either because people don't >exchange disk files, or they don't need disk files to be ascii armored. >Actually, people do exchange disk files all the time, either as email >attachments, or by FTP, or by sharing them in other ways. > Mostly I use .hqx, .uu, .b64 or whatever binary-to-ascii transmission format the other person needs. My helper/application list is already very long just to handle the current lot. Why add another encapsulation format when these will do the job just fine? When all is said and done an encrypted file is just another binary file for transmission purposes. The general internet file transfer conventions with O/PGP would go something like: Start with: mysecret.doc -> mysecret.pgp -> mysecret.uu send file over internet mysecret.uu -> mysecret.pgp apply the correct key and the recipient gets mysecret.doc And the standard should make this as simple as possible. Ascii armour is not needed. It would do just fine in place of encoding with uu/hqx/b64/... but is not needed. >And there >are reasons for ascii armoring files. One good example is a clearsigned >file, where you want to be able to view the contents while maintaining >the signature in the file. There may also be situations where people >find it convenient to be able to view their encrypted files and see BEGIN >PGP MESSAGE, so that they are reminded that they hold encrypted data. > >The only way that I can see to support this with PGP/MIME is to make >the file consist of the MIME headers, then a blank line, then the MIME >body parts. In effect we adopt a convention that files do have two parts, >control information and data, and that they are separated by a blank line. >We are forced to do this if the file system does not provide us with >another place to put lengthy control information, as most do not. > AFAIK O/PGP/MIME could only address the manner in which an email message is constructed. It has nothing to do with the **internal** structure of an attached file if that file type is not defined to the mime system as needing translation. If OTOH the O/PGP standard defines a mime conversion for files with suffix .pgp then the standard also has to be specific about the internal structure of that file. To me this implies some sort of delimiter setup and could still be well defined in terms of mime type encapsulation. After unpacking, the result on the recipient's system might have any combination of blank lines, resource forks, paired files with the proper suffix... pick your OS and you get the most natural solution, and the standard should deliver from one system/format to another system/format via the mime packing/unpacking. The bits and pieces (content, signatures, certificates, whatever) are all best displayed via the application interface or as a result of a unix style command line. Let the code do the work, use the standard to define the end results. I have a dream... (sorry! wrong holiday :-) that O/PGP will not be a bunch of cluncky headers and strange looking ascii strings. Sure that sort of stuff will still be around but it should be "under the hood". Interested types can still look at the raw data, nothing is hidden we just move to higher level of function. >But since this convention cannot be applied uniformly throughout the file >system, ambiguities arise. There is no way to tell a priori whether a >file is in this new "MIME format" or whether it is an ordinary file. >I described various examples of where these ambiguities could cause >problems. > Agreed. O/PGP cannot define the contents of the file system at large, but it can define a valid file for its own purposes. Nothing will ever stop people from sometimes serving the wrong files to an application. All we can ever do is ensure there is enough redundancy in the system to allow for robust sanity checking. Ascii-armour is only one way. I would like to hear an expert talk of the other possibilities. And there is no specific reason why the current PGP file part delimiters cannot remain in files stored on the file system. But we still need to repack the file if we want to transmit it over the internet and mime is the way to go in that area. >I also pointed out other places where PGP/MIME conventions that would be >logical for email don't make sense in more constrained applications, such >as the convention that data to be signed MUST be converted to 7 bit form >beforehand. > This is an excellent point. Maybe the convention is wrong. Let us not to hobble this new standard with an outmoded one byte alphabet. If it has not been suggested already let's get multi byte alphabets built into the standard from the ground up. No late add-on fixits to cater for the Chinese, Hindu, Japanese... scripts. These are all huge markets and getting bigger, and I believe there is already an ISO standard for these alphabets. We don't have to invent this wheel. Just use it and make O/PGP savvy with it. >In addition, I mentioned that PGP/MIME does not provide methods to >encapsulate some legal PGP packet structures which were expected not to >be used for email. > Propose the packets for inclusion. >Sorry to be redundant here, but since my first message apparently made >so little impact, perhaps a repetition will help. > No problem for me. Got me off the bench. But there are so many good players in this game I always think I look stupid :-) Quoting Adam Back on or about 1997/11/27 07:51 Sydney time- > >A minimal implementation should be allowed to call itself OpenPGP >compliant without implementing either MIME or armor. > I would worry about a standard which did not define a minimum functionality so that all implementations could talk to each other. I think mime should be MUST, this is looking ahead, and means all conformant implementations can talk to each other via this format. Allow ascii-armour as a MAY, does the right thing by history and the method is available between consenting parties. Enjoy the turkey and holiday folks, it is already Thanksgiving in Australia Regards, Gavan. Gavan Schneider | In a world without fences, | who needs Gates? Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA28422 for ietf-open-pgp-bks; Wed, 26 Nov 1997 17:08:12 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA28416 for ; Wed, 26 Nov 1997 17:08:08 -0800 (PST) Received: from s20.term1.sb.rain.org (s09.term1.sb.rain.org [198.68.144.139]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id RAA21857; Wed, 26 Nov 1997 17:10:59 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id QAA00816; Wed, 26 Nov 1997 16:55:04 -0800 Date: Wed, 26 Nov 1997 16:55:04 -0800 Message-Id: <199711270055.QAA00816@s20.term1.sb.rain.org> From: Hal Finney To: ietf-open-pgp@imc.org, iang@systemics.com Subject: Re: The armour issue Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=--"; protocol="application/pgp-signature"; micalg=pgp-sha1; Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --=-- Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Ian Grigg wrote: > OK. I know it's not strictly within the gambit of the WG, but could > somebody send me a clear-signed MIME message. I'd like to see what it > looks like and hazard a guess as to whether it can handle the task. There is nothing wrong with a clear-signed MIME message for email. (Well, maybe it is harder with existing tools to save it to its own file and verify it again later, but that could be addressed.) The issue I was raising is whether it would be useful in other contexts, where the header/body distinction was not so natural. Hal --=-- Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.0 iQA/AwUBNHzEfsDh8jnv1nHwEQJW1wCaArpJnpyHGsZu2XmSTd/Fp3hFKd4AoJQQ 5CdzERYvM6GdIk32fZSkVX/V =PNHO -----END PGP MESSAGE----- --=---- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA28077 for ietf-open-pgp-bks; Wed, 26 Nov 1997 16:33:33 -0800 (PST) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA28073 for ; Wed, 26 Nov 1997 16:33:29 -0800 (PST) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id SAA27699; Wed, 26 Nov 1997 18:34:09 -0600 (CST) Received: from pax-ca32-12.ix.netcom.com(199.35.217.236) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma027668; Wed Nov 26 18:34:00 1997 Message-Id: <3.0.3.32.19971126162310.0070ce30@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Wed, 26 Nov 1997 16:23:10 -0800 To: Ian Brown , IETF OpenPGP From: Bill Stewart Subject: Re: The armour issue In-Reply-To: <347C0AFC.C828F3AB@cs.ucl.ac.uk> References: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:41 AM 11/26/1997 +0000, Ian Brown wrote: >> Ascii armor allows PGP binary data to be held or transmitted in >> any environment that may not be safe to raw binary data. >Can you give us an example of this apart from mail? Web-based keyservers >only use armour because they are based on mail servers. HTTP allows >binary data to be transferred directly. The Web-based keyserver isn't just using armor because it's on a mailserver. A typical Web-based PGP application requires the user to cut&paste a PGP key or PGP-encrypted message into a web form and submit it. Not only are window systems highly prone to munging such data (at least white space, backspaces, CRLFs, NULs, and other control characters, if not necessarily munging 8-bit data), but web forms aren't always friendly about accepting it, and are likely to turn it into forms like %FF which need to be unmunged by the receiving program. Some of this can be avoided by adding MIME support into PGP, so it produces MIME-armored stuff to cut&paste instead of PGP-ASCII-armored, but you still need armor. (If you've got a friendly way around this problem, I'd love to see it, because I'd like to be able to have users paste Microsoft Word/Excel/PPT documents into forms to autoadd to web pages.) There's also the problem of sending PGP keys in email messages, which MIME attachments aren't always the best user interface for: Bob - Sorry your corporate maildroids are using LookOutXChange! (No Resemblence To Any Microsoft Product Intended.) If you want to buy GoodMTA, send email to alice@acme.com using my PGP key <> and remember to also encrypt to accounting's key <> so the SMTP filter doesn't bounce it. If you want to send us your resume, purchasing's key is <>. It's really much cleaner if you've got a format that can stay inlined, rather than getting transformed to ATTACH1.BIN, ATTACH2.BIN, ATTACH3.BIN. MIME would do, if you've got a convenient interface for pasting MIME into, but this requires making PGP aware of MIME headers - and if you do that, you need to decide whether to build in full-scale MIME support or just support some subset of features PGP is likely to use - do you build in both base64 (for Real Binaries and keys) and Quoted-Printable (for clearsigned text)? Then there's including keys inside encrypted messages - you need to nest the armored key structure inside the encrypted message, which means doing MIME-inside-MIME or Armor-inside-MIME or Armor-inside-Armor. See above for difficulties with MIME-inside. >I can see very little reason why people would want to store PGP data >armoured in a system that supports 8-bit data. 1) Storing clearsigned text in files, in editor-readable form. Even if you use EMACS, it's nicer to have the signature in Armored for, and with Evil GUI Editors, it's more important, and in Dumb Text Editors over telnet, you'd really like to be able to read the signature undamaged so you can copy it into things. 2) Storing keys along with clear text, in editor-readable form. Bob - here's my Revocation Certificate - only use it if my name shows up in the Dissociated Press wire stories or you hear periodic beeps when you call me. <> Alice. 3) Keyservers that are going to output the data armored anyway, whether it's by email or web. >> Lastly, there are systems that use (or would like to use) PGP over systems >> that are not the internet. I have given the example of pager systems >> before. There are other systems that use telephones, private networks, or >> other non-Internet means of data transfer. That web form for that pager service isn't the Internet! That web form for the text-to-speech reader isn't the Internet! Surely you're not planning to FAX your keys in these days of Email?! And then there's telex and TDDs .... I'm not sure if base64 works there, or if you really need monocase base32 or binhex or something; PGP's ASCII armor may not be enough. >> To forbid armor is to say that there is no conceivable use for it. >No-one has suggested this. Heh. Dave Crocker's sure come real close :-) Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA28029 for ietf-open-pgp-bks; Wed, 26 Nov 1997 16:30:42 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA28023; Wed, 26 Nov 1997 16:30:37 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id CAA01482; Thu, 27 Nov 1997 02:57:45 +0100 (MET) Message-ID: <347CC01C.4A019561@systemics.com> Date: Thu, 27 Nov 1997 00:34:36 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: dcrocker@imc.org CC: ietf-open-pgp@imc.org Subject: Re: The armour issue References: <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> <199711262241.OAA00928@proper.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Crocker / IMC wrote: > on the other hand, considerable community push-back on s/mime finally got > it to support clear signing, through support of multipart/signed. The > market desire for this feature is rather high. OK. I know it's not strictly within the gambit of the WG, but could somebody send me a clear-signed MIME message. I'd like to see what it looks like and hazard a guess as to whether it can handle the task. I can see that a clear-signed S/MIME message won't float. I'd hope that a clear-signed PGP/MIME message was approximately similar to the Armoured variety. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA27550 for ietf-open-pgp-bks; Wed, 26 Nov 1997 15:42:11 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA27545; Wed, 26 Nov 1997 15:42:05 -0800 (PST) Received: from s20.term1.sb.rain.org (s20.term1.sb.rain.org [198.68.144.150]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id PAA13349; Wed, 26 Nov 1997 15:44:56 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id PAA00076; Wed, 26 Nov 1997 15:29:00 -0800 Date: Wed, 26 Nov 1997 15:29:00 -0800 From: Hal Finney Message-Id: <199711262329.PAA00076@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Armour Cc: dcrocker@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Crocker, , writes: > At 10:28 AM 11/26/97 -0800, Hal Finney wrote: > >Actually, people do exchange disk files all the time, either as email > >attachments, or by FTP, or by sharing them in other ways. And there > > In which case they are disk files and, again, are outside of the scope of > this effort. > > This is effort is about adding security to Internet objects. That seems to be a relatively restrictive description of what we are doing, especially if you define Internet objects to only encompass MIME objects. I would suggest that this effort is about an Internet standard for exchanging PGP encrypted/signed data. FTP transfers of disk files do appear to be within the scope of the OP standard. Here is the WG description, from http://www.ietf.org/html.charters/openpgp-charter.html: PGP, or Pretty Good Privacy, first appeared on the Internet in 1991. It has enjoyed significant popularity amongst the Internet Community. PGP is used both for protecting E-mail and File Storage. It presents a way to digitally sign and encrypt information "objects." As such it is well suited for any store and forward application. The goal of the OpenPGP working group is to provide IETF standards for the algorithms and formats of PGP processed objects as well as providing the MIME framework for exchanging them via e-mail or other transport protocols. Because there is a significant installed base of PGP users, the working group will consider compatibilty issues to avoid disenfranchising the existing community of PGP users. Hal Finney hal@pgp.com hal@rain.org -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHywf8Dh8jnv1nHwEQLIegCgld4Pf5FgaU8uWa90QqnRgPPCUOQAoNWf 4XjIA2qnZoNKzh5mhpghFQvJ =9Yq7 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA27357 for ietf-open-pgp-bks; Wed, 26 Nov 1997 15:22:03 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA27352; Wed, 26 Nov 1997 15:21:59 -0800 (PST) Received: from server.test.net ([194.168.68.60]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAB23581; Wed, 26 Nov 1997 23:23:14 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id XAA06367; Wed, 26 Nov 1997 23:07:24 GMT Date: Wed, 26 Nov 1997 23:07:24 GMT Message-Id: <199711262307.XAA06367@server.test.net> From: Adam Back To: dcrocker@imc.org CC: jon@pgp.com, gavan@magna.com.au, ietf-open-pgp@imc.org In-reply-to: <199711262144.NAA00830@proper.com> (message from Dave Crocker / IMC on Wed, 26 Nov 1997 13:46:08 -0800) Subject: Re: expedience, consensus and editing Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Crocker writes: > At 09:08 PM 11/26/97 +0000, Adam Back wrote: > >My suggestions are: > > > >1) armor MAY > >2) MIME SHOULD (with update to rfc2015 where missing parts) > > Ok. So you implement armor and I implement MIME. How do we interoperate? I understand fully your point, and I agree. The difference is just labelling. The labelling problem I see is that people are planning to use OpenPGP for different purposes. What I meant above was: 2) MIME MUST if the data is transferred over 7 bit comms channel. I'm not fussy, if people implement a full OpenPGP packet set but don't plug it in to a MIME handler, it is true that they can't communicate directly with people who send them MIMEd packets. If we say (as I take your previous posts to argue): 2) MIME MUST (always, no exceptions) this means the 8 bit only people are not allowed to call their implementation OpenPGP complaint. Well I can live with a "that's their problem", answer, and doesn't seem that big an issue. Any other opinions? Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA27197 for ietf-open-pgp-bks; Wed, 26 Nov 1997 15:08:31 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA27191; Wed, 26 Nov 1997 15:08:25 -0800 (PST) Received: from s20.term1.sb.rain.org (s10.term2.sb.rain.org [198.68.144.170]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id PAA09676; Wed, 26 Nov 1997 15:11:11 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id OAA32742; Wed, 26 Nov 1997 14:54:32 -0800 Date: Wed, 26 Nov 1997 14:54:32 -0800 From: Hal Finney Message-Id: <199711262254.OAA32742@s20.term1.sb.rain.org> To: aba@dcs.ex.ac.uk, dcrocker@imc.org Subject: Re: expedience, consensus and editing Cc: gavan@magna.com.au, ietf-open-pgp@imc.org, jon@pgp.com Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keep in mind that you cannot do some things in PGP/MIME that you can with ascii armor. - There is no PGP/MIME encoding of a detached signature - There is no PGP/MIME encoding of a non-clear signed message - I'm not sure if there is a natural encoding of a signed message which also includes a key certificate for verification. Maybe you could use a multipart for this, but it's not in the spec, and it's not clear that it would interoperate. It is also unclear what you do with the output when you decrypt a PGP/MIME message. People may not be aware that before encrypting you MUST convert your input into a MIME body part, with a MIME header, if it is not already in that form. For example, to encrypt the one-line message: This is a test you convert it to something like these three lines: Content-type: text/plain This is a test and encrypt that. Now, some issues arise on decryption. If you added headers on encryption, probably you should remove them on decryption, right? That would be pretty easy in the case above. The first line is "Content-type: text/plain", so you strip that and any related MIME headers off. But what if that first line was "Content-type: multipart/mixed"? Now do you leave the MIME header lines on? You can't really strip them because the message body has structure and it can't be interpreted without the headers. What if it says "content-type: audio/basic"? Just strip it and save the raw data? How about text/richtext? Leave it, strip it, or try to include a richtext interpreter? At a minimum we would have to specify the rules to follow for these various cases. Or do we specify that PGP/MIME MUST only put simple Content-types into the encrypted body part? That wouldn't work well; the PGP Inc. plug-in already encrypts multiparts and other cases. The problem here is that PGP/MIME was designed to encrypt MIME-ish things. That makes sense for email, especially given that MIME is available or you wouldn't be using PGP/MIME. But in the PGP world we want to encrypt a wider range of things than that. This introduces ambiguities such as I have been describing here and in other messages. Within a MIME-aware mailer, all the PGP/MIME decryption module has to do is to strip off the encryption and hand the MIME encoded body part back to the mailer to worry about all these things. But that is not an adequate solution for the full range of applications we want to support. I have struggled with these issues, because I've implemented PGP/MIME within our SDK. It does not lend itself to the "filter" model used with the ascii armor and binary messages, where you have a single input stream and a single output stream. Thorny problems arise when you try to implement it, as I have described. I don't think it is a good substitute for ascii armor in its full generality. For email it's fine. Hal Finney hal@pgp.com hal@rain.org -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHyoosDh8jnv1nHwEQJolwCfSfsJQeShO3m6kgnVP1+Z8PJ1fwIAnjne sYx6YEpoIbZ64m+j99RX/K0g =s0Fl -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA27174 for ietf-open-pgp-bks; Wed, 26 Nov 1997 15:07:30 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA27170 for ; Wed, 26 Nov 1997 15:07:26 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id BAA01146; Thu, 27 Nov 1997 01:34:31 +0100 (MET) Message-ID: <347CAC9B.1466AD6B@systemics.com> Date: Wed, 26 Nov 1997 23:11:23 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org CC: jon@pgp.com, aba@dcs.ex.ac.uk Subject: Re: expedience, consensus and editing References: <199711262108.VAA05371@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > 1) armor MAY/SHOULD/MUST? SHOULD (sorry, I'm an old-timer who sees armour as part of PGP) > 2) MIME as MAY/SHOULD/MUST? SHOULD > 3) 32 bit int clean up shelved for OpenPGPv2, or discussed now Defer [ equals back-burner start in parallel. Danger of stalling of V1 needs alternate survival strategy. ] > 4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2, Define subpacket type 10 as reserved for future use. [ "for OpenPGPv2" is not an option for the WG as someone (presumably PGP Inc) must propose it for that first. ] > ... and let's not perform the 32 bit > clean up operation with OpenPGPv1, or it will delay the delivery date > enormously. What we lost in the cleanup discussions we might save in the coding :-) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA26768 for ietf-open-pgp-bks; Wed, 26 Nov 1997 14:43:05 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA26764 for ; Wed, 26 Nov 1997 14:43:01 -0800 (PST) Received: from omni.imc.org (pm3-32.netgate.net [205.214.163.32]) by proper.com (8.8.7/8.7.3) with SMTP id OAA00928; Wed, 26 Nov 1997 14:41:25 -0800 (PST) Message-Id: <199711262241.OAA00928@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 2 (build 233) Date: Wed, 26 Nov 1997 14:43:14 -0800 To: Ian Brown From: Dave Crocker / IMC Subject: Re: The armour issue Cc: ietf-open-pgp In-Reply-To: <347C997B.10EFDB1E@cs.ucl.ac.uk> References: <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:49 PM 11/26/97 +0000, Ian Brown wrote: >Ian Grigg's point in favour of armour is that clearsigned documents are >useful. Fair enough; Ian can buy/write an application which includes >this functionality. It does not need to be a MUST. As Adam just said, it >would be simple to do the same with MIME. on the other hand, considerable community push-back on s/mime finally got it to support clear signing, through support of multipart/signed. The market desire for this feature is rather high. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA26437 for ietf-open-pgp-bks; Wed, 26 Nov 1997 14:12:06 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA26433 for ; Wed, 26 Nov 1997 14:11:59 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id OAA24624 for ; Wed, 26 Nov 1997 14:13:07 -0800 (PST) Message-Id: <3.0.3.32.19971126141219.00b3d4f0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 26 Nov 1997 14:12:19 -0800 To: ietf-open-pgp From: Jon Callas Subject: Features issues... In-Reply-To: <347C997B.10EFDB1E@cs.ucl.ac.uk> References: <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Our WG chair is unfortunately down with pneumonia. I talked to him a couple of times yesterday, but he's severely under the weather now. Given that this is also the start of a long weekend in the US, I think moving forward is something *we* have to do. Determining what the consensus is on the features we're continuing to talk on (armor, ARR) is his responsibility, and none of us are presently adding content (and I hold up my own last responses as being content-free). Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA26233 for ietf-open-pgp-bks; Wed, 26 Nov 1997 13:52:20 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA26227 for ; Wed, 26 Nov 1997 13:52:16 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Nov 1997 21:53:15 +0000 Message-ID: <347C997B.10EFDB1E@cs.ucl.ac.uk> Date: Wed, 26 Nov 1997 21:49:47 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Paul Rarey CC: ietf-open-pgp , Adam Back Subject: Re: The armour issue References: <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Paul - thanks for that post. Input like yours - from companies deciding which standards to implement - is EXACTLY what we need in this debate. We can sit around all day discussing the technical and political issues. If the standard is not implemented, these discussions will be entirely pointless. As Adam says: S/MIME is racing ahead. Never mind completing at the same time; Open PGP needs a good head start if we are going to overcome the enormous odds we have against us (such as the 25 million installed base of Netscape and Microsoft software). (Please flame me directly if you must; this group cannot afford any more time to be wasted). Ian Grigg's point in favour of armour is that clearsigned documents are useful. Fair enough; Ian can buy/write an application which includes this functionality. It does not need to be a MUST. As Adam just said, it would be simple to do the same with MIME. On Adam's other points: MIME SHOULD, shelve 32-bit cleanup for OP2, define subpacket 10 as reserved for future use. Can we move forward, *please*? Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA26186 for ietf-open-pgp-bks; Wed, 26 Nov 1997 13:46:53 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA26182 for ; Wed, 26 Nov 1997 13:46:48 -0800 (PST) Received: from omni.imc.org (pm3-86.netgate.net [205.214.163.86]) by proper.com (8.8.7/8.7.3) with SMTP id NAA00830; Wed, 26 Nov 1997 13:44:49 -0800 (PST) Message-Id: <199711262144.NAA00830@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 2 (build 233) Date: Wed, 26 Nov 1997 13:46:08 -0800 To: Adam Back From: Dave Crocker / IMC Subject: Re: expedience, consensus and editing Cc: jon@pgp.com, gavan@magna.com.au, ietf-open-pgp@imc.org In-Reply-To: <199711262108.VAA05371@server.test.net> References: <199711260240.SAA27773@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:08 PM 11/26/97 +0000, Adam Back wrote: >My suggestions are: > >1) armor MAY >2) MIME SHOULD (with update to rfc2015 where missing parts) Ok. So you implement armor and I implement MIME. How do we interoperate? d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA25789 for ietf-open-pgp-bks; Wed, 26 Nov 1997 13:09:13 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA25782; Wed, 26 Nov 1997 13:09:06 -0800 (PST) Received: from server.test.net ([194.168.69.27]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAB9933; Wed, 26 Nov 1997 21:10:21 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id VAA05371; Wed, 26 Nov 1997 21:08:20 GMT Date: Wed, 26 Nov 1997 21:08:20 GMT Message-Id: <199711262108.VAA05371@server.test.net> From: Adam Back To: dcrocker@imc.org CC: jon@pgp.com, gavan@magna.com.au, ietf-open-pgp@imc.org In-reply-to: <199711260240.SAA27773@proper.com> (message from Dave Crocker / IMC on Tue, 25 Nov 1997 18:41:40 -0800) Subject: expedience, consensus and editing Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Crocker / IMC writes: > Jon Callas writes: > >The compromise that I, as editor am working with (with thanks to Ian Brown, > >who came up with it) is as follows: > > Jon, those who serve as working group chairs and document editors have a > difficult job. They are usually senior, talented folk. They get to work > hard and almost never are adequately appreciated. > > Worst of all, they are often architects who do not see their own > preferences chosen. > > The editor of an IETF working group document is required to be responsive > to the rough consensus of the working group. I hope no one has forgotten > this minor point. I would like to see more rapid progress in this forum. I am subscribed to ietf-smime also, and the rate of progress there is much quicker. Suggestions are made for modifications, the active editor says after some discussion, "ok added this, hows this", etc. Consensus appears to be followed with minimal political intrigue. Multiple revisions per day. So can we have a decision on what is the consensus on these four items: 1) armor MAY/SHOULD/MUST? 2) MIME as MAY/SHOULD/MUST? 3) 32 bit int clean up shelved for OpenPGPv2, or discussed now 4) CMR/ARR and alternatives worked through now or shelved for OpenPGPv2, My suggestions are: 1) armor MAY 2) MIME SHOULD (with update to rfc2015 where missing parts) 3) shelve until for OpenPGPv2 4) define subpacket type 10 as reserved for future use and get on with things. I already made 2 detailed posts explaing reasons for my recommendation for 4, and have had 2, or 3 people agree with my conclusion and have seen no disagreements on list. It seems the least controversial path, and the quickest path to take, and doesn't affect compatibility. The alternative of hashing out a consensus here of which method best allows for lost passphrase recovery seems that it will take forever. PGP Inc seem to be using message snooping techniques which reduce communications security to implement passphrase recovery, which in my and most of the non-PGP peoples opinion is bad design. Let's not get adventurous, and let's not have a massive brawl over controversial experimental features, and let's not perform the 32 bit clean up operation with OpenPGPv1, or it will delay the delivery date enormously. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA25784 for ietf-open-pgp-bks; Wed, 26 Nov 1997 13:09:09 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA25776; Wed, 26 Nov 1997 13:09:03 -0800 (PST) Received: from server.test.net ([194.168.69.27]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA9933; Wed, 26 Nov 1997 21:10:17 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id UAA05360; Wed, 26 Nov 1997 20:51:17 GMT Date: Wed, 26 Nov 1997 20:51:17 GMT Message-Id: <199711262051.UAA05360@server.test.net> From: Adam Back To: hal@rain.org CC: dcrocker@imc.org, ietf-open-pgp@imc.org In-reply-to: <199711261828.KAA32470@s20.term1.sb.rain.org> (message from Hal Finney on Wed, 26 Nov 1997 10:28:25 -0800) Subject: Re: Armour Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney writes: > Many of them are related to the MIME convention you describe of separating > control information from data. This works well in an email environment, > where such separation is already in place. We have mail headers and body, > and it is natural to add the MIME control information to the headers, > and to put the MIME body parts into the body. This also works for HTTP > and news, which have a similar header/body distinction. > > But this model breaks down when we are in an environment where such > separation does not exist. [...] > > The only way that I can see to support this with PGP/MIME is to make > the file consist of the MIME headers, then a blank line, then the MIME > body parts. In effect we adopt a convention that files do have two parts, > control information and data, and that they are separated by a blank line. > We are forced to do this if the file system does not provide us with > another place to put lengthy control information, as most do not. Sounds reasonable, and the way that I would expect MIME encoding to be implemented in files where this is required. You could view armor as already having this same two part structure .. it has to have a blank line (in pgp5 ... pgp2.x did not have this restriction, btw). So with armor your header is: : -----BEGIN PGP MESSAGE----- : Version: 2.6.3i and the body is: : hQEMA1u1vznKKgBtAQf/ZOZpqGBKIprmGUtUq/B/IPgGKE68r/D90fiSsKW3saCR : L8doacYM8PnRsKRrWq1MMxcn9AE3keAuqYUnosn/Wokd9zYtKJho13Yc7VxHqV2I : /dRkq4WxZlogmChxtaGFFSEiPC/bgFBbMryA0QQleCbArp3+16+TtLvG+uz9jezU : R+N+rzCILKJIUxt3HG14kz4RRA+x4VwV8h9A/TnCDgxGiUwDCxOranMJwmHPAsZa : Dr2xBFFe7Ael/D2ZbPfHdLWHnbZI81kuS1uE1YnLdt8xWtaUkPTCuHKANY1ccXj/ : 0v5CKfh27QqRACNeU+QBxaWTpBb4fXyjN6A5uqnDBqYAAAEwIG8UxuzfMPGPHFl4 : B0jISuJP/3FCnTgxl7gihtiwRDmdoOB7K8Tvw4YVhsl/oObo/kfx+pBAB0G65J+6 : f3IFU2a8SR6Gfm9g5pJjTSkt++q5R5qV7OAbenlYs5+w1Dh1plpWb46q4gpjrpqN : +TnHl3HPvB6OfkUrU2KogvI/R8TEkb0qfojI4qexk305TRb+X46Zm9/kY41yOZoB : 3tWCnjFN4dWBy5KZYk/TsToCyzzQ2mo/CPRTLrD3Ib99+Iwwd97u4pCIc0vLeFXZ : CYOdgOujyFw3ooI5P0drX9skZWd7bndg3T/TeZfdxXpDc0YQFREFI9WjvZ9Cqj7g : DnZS7mOhlc1wsS7rZDrNSqsDAz/a+Tlq92xRQzBjF2Wh8ca5z1KV6MLq3MtZWEJ6 : 9NPC9A== : =JEnb : -----END PGP MESSAGE----- Where they are separated by a blank line. Same thing for MIME, header: : Content-Type: application/pgp : Content-Transfer-Encoding: radix64 and body: : hQEMA1u1vznKKgBtAQf/ZOZpqGBKIprmGUtUq/B/IPgGKE68r/D90fiSsKW3saCR : L8doacYM8PnRsKRrWq1MMxcn9AE3keAuqYUnosn/Wokd9zYtKJho13Yc7VxHqV2I : /dRkq4WxZlogmChxtaGFFSEiPC/bgFBbMryA0QQleCbArp3+16+TtLvG+uz9jezU : R+N+rzCILKJIUxt3HG14kz4RRA+x4VwV8h9A/TnCDgxGiUwDCxOranMJwmHPAsZa : Dr2xBFFe7Ael/D2ZbPfHdLWHnbZI81kuS1uE1YnLdt8xWtaUkPTCuHKANY1ccXj/ > But since this convention cannot be applied uniformly throughout the file > system, ambiguities arise. There is no way to tell a priori whether a > file is in this new "MIME format" or whether it is an ordinary file. If it is a MIME format file, it will have Content-Type: etc. fields saying what kind of PGP object it is. Same as the armor header. I personally am accustomed to armor because my mailer uses it and because I haven't bothered installing direct MIME support. However it seems that MIME is the way forward, and that having Armor as a MAY allows implementors to implement it for backwards compatibility. I think neither MIME nor Armor should be MUST. Both MAY. You could argue for SHOULD for backwards compatibility. (Note: with IDEA and RSA relegated to SHOULD or is that MAY already, backwards compatibility is already lost for a minimal MUST only implementation.) A minimal implementation should be allowed to call itself OpenPGP compliant without implementing either MIME or armor. You might need to define some new MIME types to go with rfc2015 for the MIME types for the objects which you say are missing. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA25607 for ietf-open-pgp-bks; Wed, 26 Nov 1997 12:47:35 -0800 (PST) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA25603 for ; Wed, 26 Nov 1997 12:47:31 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id OAA24652; Wed, 26 Nov 1997 14:48:05 -0600 (CST) Received: from lax-ca66-50.ix.netcom.com(207.223.161.114) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma024618; Wed Nov 26 14:47:35 1997 Message-ID: <347C8AE3.B492B164@sternlight.com> Date: Wed, 26 Nov 1997 12:47:34 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: "A. Padgett Peterson P.E. Information Security" CC: ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving References: <971126124405.20e13942@hobbes.orl.lmco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2B0D2D6E9EDD702B61C36323" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms2B0D2D6E9EDD702B61C36323 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit A. Padgett Peterson P.E. Information Security wrote: > > > >Free PGP had used RSAREF (for RSA), a software package made available free > >by RSADSI for anyone's non-commercial use. No patent issues, fees, or > >litigation are involved. This is TOTALLY clear, not "not exactly clear" > >as Peterson claims. There is no "may be exempt" about those versions of > >free PGP. Thay are, in fact, fully licensed for non-commercial use of RSA. > >He should read the RSAREF license. > > May have changed but when it first came out I looked into the RSAREF and > was rather astounded by the wording of the "free" license agreement - looked > like something Microsoft might have written. Wasn't even something the I, > as a hobbyist, would sign since the restrictions seemed to outlive the > patent. I don't know what the above hand-waving paragraph means, but it is non-responsive to my correction. > Not going into the fact that you missed my point entirely since it is more > properly directed at PGP Inc. Your point turned on there being a licensing cloud or licensing fees over Free PGP. There wasn't. > - Is there something in the license you have > with RSA for the commercial product that limits what you can put into a > "free" version without paying RSA a fee ? I assume you mean the commercial licnnse PGP Inc. has. The RSAREF license used with Free PGP has nothing to do with any other license PGP Inc. may or may not have. It stands on its own. > If that is "no" then I too will > ask why the free version should not contain the older mechanisms for > compatability. (I use the commercial version so do not know if it does or > does not). Welcome to the club. David --------------ms2B0D2D6E9EDD702B61C36323 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKjQYJKoZIhvcNAQcCoIIKfjCCCnoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CIUwggPPMIIDOKADAgECAhAnuK6izE0BOIf7uTQQ8usCMA0GCSqGSIb3DQEBAgUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA4MjEwMDAw MDBaFw05ODA4MjEyMzU5NTlaMIIBEjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDIgLSBOZXRzY2FwZTEZMBcGA1UEAxMQRGF2aWQgU3Rlcm5saWdodDEjMCEGCSqGSIb3 DQEJARYUZGF2aWRAc3Rlcm5saWdodC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN09h1fHJlSiS54oM5YjKy9J6wMmjUFL58Xkwc6JiCBftinxpbm2ziTPSAn4TMhSVbZnuC1m oDZln2HSvkRS61+BwYL3yw9kus2/Tyoi4gparm1O+CRlRkudAP8w7cHax6AZXTr7KDQA/mOq nXSPERdO3XZIgvVRXvL7VIVt++F7AgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0gBIGn MIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24A AAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBAgUAA4GBAE8QvB3wHstP4Ggj +WuQRdIKOsO4U3F5mUjfle6hatqCA1fvD3Kzmrr4KSvBes2CH0BKV/Mmb/rRkkwXaspTkSIC 0ENT789yEuv/aoOVogJVaKYHz7bgNkSuwa6O8SKHkrGHdQRxl3J+GN1SEgOzkW7A15d702QM 0tR6rtxMvtxYMIICeTCCAeKgAwIBAgIQUNNSlJEvedMV4ysxrIVI8DANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3 MDAwMDAwWhcNOTgwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlk dWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+b yB2eT7R1731MMPOyqjS/mdtGxtSYxx1FDuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqt WhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCI cp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCG SAGG+EIBAQQEAwICBDANBgkqhkiG9w0BAQIFAAOBgQAN6OSPQTmZ8ouFAbfodckgYj0dsq43 RhipxsLh/k6LwgZbQUbv8sxw0AEqFp5AUak+wBPYFljrwLCW/qnQZbM1RsFBCP6IlPSbtgyv YbUZrIGeVCdsNpBTxypskPapJdjkip4YXyd8jdn10TX+OZmd7OjE9vRuXjCXTgiI0JmvnzCC AjEwggGaAgUCowAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFg a355LPoGDzqu9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fM CGw/PrNK/P9LbCPVUIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQAD gYEAe6+kHC/Amw47XPyo5tGWD0hySYXlrxojAOPpu4A0bLI/hKg8cnCzTN5z+nyE0pKlADcJ wgM0IwO37XaW3D5Phf1YF/QEvuxRHtx629uu6GF42mU4R6wdA3Bt6eO7oEqfQOq823O/Z01d xnwgXOfoogorwgl010z+2+lrAmNdOacxggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVy bmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQJ7iuosxNATiH+7k0EPLrAjAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTEy NjIwNDczN1owIwYJKoZIhvcNAQkEMRYEFLzxiGzEw+srDemOOIE9FFTidspyMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGADaig8qYHcR9+hIZ2ogpr RDDB6gAHCEwKEp2m9tIWmcg49o/VmSjPGFG/WIeCv3qDWB8uITM9wh3gqpIw1SoKqycGaif7 G/p637QhNjptcKj220xl1fA3F6X2rs8uE/wkkPPufhSKsrQATlufVyCMZ416FetHuEhcxnCq 5xFvqlM= --------------ms2B0D2D6E9EDD702B61C36323-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA25559 for ietf-open-pgp-bks; Wed, 26 Nov 1997 12:44:11 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA25555 for ; Wed, 26 Nov 1997 12:44:06 -0800 (PST) Received: from hayek.guvnet (wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id XAA00526; Wed, 26 Nov 1997 23:10:22 +0100 (MET) Message-ID: <347C8AA2.29B3C1AE@systemics.com> Date: Wed, 26 Nov 1997 20:46:26 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Ian Brown CC: ietf-open-pgp@imc.org Subject: Re: The armour issue References: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> <347C0AFC.C828F3AB@cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Brown wrote: > > Ascii armor allows PGP binary data to be held or transmitted in > > any environment that may not be safe to raw binary data. > > Can you give us an example of this apart from mail? Web-based keyservers > only use armour because they are based on mail servers. HTTP allows > binary data to be transferred directly. ( Armour also allows cut and paste. Presumably MIME would as well, I don't know. ) ... > I can see very little reason why people would want to store PGP data > armoured in a system that supports 8-bit data. I can't think of a reason either. What I do want to do is to store clear text signatures. That I need. I don't know whether MIME can do that, or whether it is applicable ... The specific instance is the contract. The cleartext sig must be embedded, obvious, and small (a la PRZ bit-culling). I would see S/MIME as a non-starter here as people talk about multiple K sigs, but maybe a MIME encoding of a PGP sig is ok. I won't know until I see one and look at how scriptable it is. I don't understand enough about the MIME vs Armour debate to know whether clear text sigs are effected. Is this Armour or something else? It's certainly PGP. > > There are other applications that use PGP technology > > for authentication, enveloping, etc. and use armor. > > Is this because they transfer data by mail? If assuming the above contract is included in the notion of Amour, then the answer is "not only mail, they have to be readable by humans in a wide variety of contexts." ... > > To forbid armor is to say that there is no conceivable use for it. > > No-one has suggested this. I suggest you be boring and repeat (every second post) what it is that is being suggested. One of the problems I had with this debate was working out what the proposal was (that's partly why I kept away from it, waiting for someone to state what). > > Armor itself is > > still a preferred way of transmitting OP objects that are not messages. > > Could you give us a case where it is vital to the understanding of an > object that it is armoured - i.e. just interpreting the underlying > binary packet(s) will not give you the full meaning of the object. The contract above must be clear, not binary. The reasons for this are complex and messy. I'll fill you in if we can decide if a clear text sig is applicable to this debate. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA25530 for ietf-open-pgp-bks; Wed, 26 Nov 1997 12:40:15 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA25526 for ; Wed, 26 Nov 1997 12:40:11 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EK9003ASTH479@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Wed, 26 Nov 1997 15:41:28 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EK900ELYTH3CK@lmco.com> for ietf-open-pgp@imc.org; Wed, 26 Nov 1997 15:41:27 -0500 (EST) Date: Wed, 26 Nov 1997 15:41:16 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: PGP, MIME, and Armour To: ietf-open-pgp@imc.org Message-id: <971126154116.20e12104@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Actually Hal make a valid point that appears to need emphasis: in a recursive message such as would exist in a PGP encrypted file which was then MIME encoded, how would the recipient know what it was ? Today, I can recognize PGP files for me by the "h" as the first character just as the typical UUENCODE first character is "M". It would seem to make sense that part of the standard be to bring forth to the top level each of the successive levels of encoding so that the recipient can tell what has been received without unbundling. Note that this is not something that is specific to PGP and AsciiArmouring but rather pertinant to any recursive mechanism. Warmly, Padgett ps of course maybe this is not a bug but a feature to make automatic universal decoders to spend as much time on each message as possible 8*) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA24463 for ietf-open-pgp-bks; Wed, 26 Nov 1997 11:11:53 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA24457 for ; Wed, 26 Nov 1997 11:11:49 -0800 (PST) Received: from omni.imc.org (pm3-90.netgate.net [205.214.163.90]) by proper.com (8.8.7/8.7.3) with SMTP id LAA00682; Wed, 26 Nov 1997 11:10:14 -0800 (PST) Message-Id: <199711261910.LAA00682@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 2 (build 233) Date: Wed, 26 Nov 1997 11:11:58 -0800 To: Hal Finney From: Dave Crocker / IMC Subject: Re: Armour Cc: ietf-open-pgp@imc.org In-Reply-To: <199711261828.KAA32470@s20.term1.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:28 AM 11/26/97 -0800, Hal Finney wrote: >separation does not exist. I used the example of disk files. Now, some >people have said that this should not count, either because people don't >exchange disk files, or they don't need disk files to be ascii armored. No, the major reason for dismissing it is that it is outside the scope of this effort, since this is a standards effort for the Internet, which means it is for transport across data networks, not storage on files. >Actually, people do exchange disk files all the time, either as email >attachments, or by FTP, or by sharing them in other ways. And there In which case they are disk files and, again, are outside of the scope of this effort. This is effort is about adding security to Internet objects. >The only way that I can see to support this with PGP/MIME is to make >the file consist of the MIME headers, then a blank line, then the MIME >body parts. In effect we adopt a convention that files do have two parts, >control information and data, and that they are separated by a blank line. The idea that armour does not impose its own encoding conventions is really rather strange. The fact that you seem to think it does not probably reflects a comfort with one approach and discomfort with another. This is not a technical issue, it is psychological. >In addition, I mentioned that PGP/MIME does not provide methods to >encapsulate some legal PGP packet structures which were expected not to >be used for email. Details? d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24114 for ietf-open-pgp-bks; Wed, 26 Nov 1997 10:45:18 -0800 (PST) Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA24110 for ; Wed, 26 Nov 1997 10:45:14 -0800 (PST) Received: from log3 ([128.100.100.195]) by bureau6.utcc.utoronto.ca with SMTP id <161114(6)>; Wed, 26 Nov 1997 13:32:17 -0500 Date: Wed, 26 Nov 1997 13:32:10 -0500 From: robert.guerra@utoronto.ca X-Sender: 01100108@log3 To: David Sternlight cc: ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving In-Reply-To: <347C5511.64407B46@sternlight.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I would dearly like that the discussions on here revolve around the guidelines set up for this mailing list. I'm tired of seeing your arguements seemingly multiply to wherever any pgp mailing list or newsgroup is to be found. If you want to contribute to advancing the open pgp project then you are more than welcome, otherwise please don't distract the many people on here who are trying to advance a noble project. regards robert Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24080 for ietf-open-pgp-bks; Wed, 26 Nov 1997 10:41:45 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA24074; Wed, 26 Nov 1997 10:41:36 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term2.sb.rain.org [198.68.144.173]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA04224; Wed, 26 Nov 1997 10:44:21 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA32470; Wed, 26 Nov 1997 10:28:25 -0800 Date: Wed, 26 Nov 1997 10:28:25 -0800 From: Hal Finney Message-Id: <199711261828.KAA32470@s20.term1.sb.rain.org> To: dcrocker@imc.org, ietf-open-pgp@imc.org Subject: Re: Armour Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dave Crocker writes: > 1. Technical > > There is no strong argument that either MIME or Armour are superior at > doing protection against the vagaries of transport. > > It is worth noting that Armour combines the control information with > the data, whereas MIME keeps them separate. This facilitates processing by > recipients who either do not have the necessary security software or who > want to defer its use. That is, for authenticated data which is not also > encrypted, the main data can be kept cleartext whereas with Armour it is not. I described several technical objections to the use of MIME which no one has addressed. Many of them are related to the MIME convention you describe of separating control information from data. This works well in an email environment, where such separation is already in place. We have mail headers and body, and it is natural to add the MIME control information to the headers, and to put the MIME body parts into the body. This also works for HTTP and news, which have a similar header/body distinction. But this model breaks down when we are in an environment where such separation does not exist. I used the example of disk files. Now, some people have said that this should not count, either because people don't exchange disk files, or they don't need disk files to be ascii armored. Actually, people do exchange disk files all the time, either as email attachments, or by FTP, or by sharing them in other ways. And there are reasons for ascii armoring files. One good example is a clearsigned file, where you want to be able to view the contents while maintaining the signature in the file. There may also be situations where people find it convenient to be able to view their encrypted files and see BEGIN PGP MESSAGE, so that they are reminded that they hold encrypted data. The only way that I can see to support this with PGP/MIME is to make the file consist of the MIME headers, then a blank line, then the MIME body parts. In effect we adopt a convention that files do have two parts, control information and data, and that they are separated by a blank line. We are forced to do this if the file system does not provide us with another place to put lengthy control information, as most do not. But since this convention cannot be applied uniformly throughout the file system, ambiguities arise. There is no way to tell a priori whether a file is in this new "MIME format" or whether it is an ordinary file. I described various examples of where these ambiguities could cause problems. I also pointed out other places where PGP/MIME conventions that would be logical for email don't make sense in more constrained applications, such as the convention that data to be signed MUST be converted to 7 bit form beforehand. In addition, I mentioned that PGP/MIME does not provide methods to encapsulate some legal PGP packet structures which were expected not to be used for email. Sorry to be redundant here, but since my first message apparently made so little impact, perhaps a repetition will help. Hal Finney hal@pgp.com hal@rain.org -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHxqQsDh8jnv1nHwEQJUCACfeCR18YyDsBBd0rCXEg82NxFhP/cAnjhO 3yOvMKYapbprPB7Xd1EUQHoM =S2Ud -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA24003 for ietf-open-pgp-bks; Wed, 26 Nov 1997 10:36:24 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23991 for ; Wed, 26 Nov 1997 10:36:12 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term2.sb.rain.org [198.68.144.173]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id KAA03717 for ; Wed, 26 Nov 1997 10:38:56 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id KAA32396 for ietf-open-pgp@imc.org; Wed, 26 Nov 1997 10:04:27 -0800 Date: Wed, 26 Nov 1997 10:04:27 -0800 From: Hal Finney Message-Id: <199711261804.KAA32396@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Critical bit (was: case for removing subpacket type 10) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Grigg, , writes regarding the critical bit: > In the case of the Criticality bit, you will still have comms, but the > various MUAs will alert you to problems, which is ideal. No loss of > functionality, but an annoying reminder to upgrade every time you talk > to someone :-) On this basis alone, I think we'd like to avoid a > standardised "please upgrade me" virus. The claim seems to be that the critical bit will lead to annoying software which pesters the user to upgrade. But this would not necessarily happen. There is no more reason to tell the user about an unknown packet with a critical bit than to tell him about an unknown packet without the bit set. Either way, upgrading might be a good idea as it will add some (inherently unknown) functionality. All the critical bit changes is the default handling of the signature containing the unknown packet. > I think the issue here surrounds the nature of the extension. Normally, > if one wanted to hack in and add the whatiwant feature, one would > do it in such a way that the feature was innocuous to older > non-conforming software. So the feature has to be an addition, without > which the sum is unchanged from the older standard. > > In the new packets as discussed here, the PGP Inc whatiwant feature is a > *subtraction* in that it applies some limit to the power of the > signature. Now, you can't take something away, and then put it back > whilst talking to those that don't understand the new mathematics. PGP > Inc people have recognised this, and have added an additional feature > that says "on any subtraction, reject the lot." If everybody > understands that there is a subtraction going on, then at least if they > can't put back that which was lost, then they can consider the whole > things broken. The purpose of the critical bit is to make it easier to add extensions to the meaning of signatures. One thing we have found in 5.X is the difficulty of trying to maintain backwards compatibility with old versions of PGP. We want to try to avoid this in the future by designing so that future implementations will have an easier job being backwards compatible. The critical bit greatly increases the flexibility and ease of adding new features without breaking old implementations. You can create new kinds of signature qualifications, which would otherwise be interpreted wrongly by old code. For example, suppose we hadn't thought of adding signature expirations and we wanted to add a field for that purpose. Issuing a signature with an expiration field will be dangerous because old software won't understand the expiration part and will treat it as valid even when it has expired. This breaks the security model. By setting the critical bit we make the old software ignore signatures with expirations rather than treating them as lasting forever. It's a matter of whether the old software errs on the secure side versus on the risky side. The critical bit increases security by making the software err conservatively. > Hal said: > - On a self-signature, ignore the key if you don't understand the > subpacket type. This is because the self-signature may be > saying something important qualifying the meaning of the key or > how it is intended to be used by the owner. If you don't know > what he's saying, it's safest not to use the key. > > This is trouble piled upon trouble. Trying to set this sort of > behaviour up in complex software is tricky, and is best avoided unless > you're well paid to do precisely that (and I hope the folks at PGP Inc > are indeed well paid). Putting it into a standard is equivalent to > institutionalising software failures. I don't understand why this simple rule is so troublesome. But even if this particular case seems difficult, the more general rule of ignoring signatures with unknown critical subpackets should be straightforward enough. (The self-signature rule would then follow automatically if we adopted the convention of not using userids that were lacking self-sigs, as Lutz has suggested.) > I would suggest that the Criticality bit be dropped. This will limit the scope of future expansions. Designers who want to add new semantics to signatures (e.g. see the SPKI work, PolicyMaker, or any of the many research projects on trust models) will find their options limited. They will probably have to create new kinds of signature packets just so that old software will ignore their signatures. This will lead to redundancy, with different signature packets defined with the same or similar semantics, solely to prevent old software from treating the signatures the wrong way. The critical bit is a benefit to future designers. It helps to make the spec more robust and able to accommodate future needs. It does not add much complexity to just ignore signatures which have unrecognized critical subpackets. It will be a useful feature. Hal Finney hal@rain.org hal@pgp.com -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHxkmMDh8jnv1nHwEQJlAwCfaXg6+bvIszQDAJVScfV1+GKYI2cAoIOM 7C3k4euDQBHHtg3HRVhFPYTB =ne6R -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA23218 for ietf-open-pgp-bks; Wed, 26 Nov 1997 09:42:55 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA23213; Wed, 26 Nov 1997 09:42:51 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EK900MPNL9IFR@mailgw2.lmco.com>; Wed, 26 Nov 1997 12:44:06 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EK900A69L9IF9@lmco.com>; Wed, 26 Nov 1997 12:44:06 -0500 (EST) Date: Wed, 26 Nov 1997 12:44:05 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: PGP evolving, improving To: david@sternlight.com Cc: ietf-open-pgp@imc.org, ietf-smime@imc.org Message-id: <971126124405.20e13942@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Peterson is quite mistaken in his post below. (who 8*) >Free PGP had used RSAREF (for RSA), a software package made available free by RSADSI for anyone's non-commercial use. No patent issues, fees, or litigation are involved. This is TOTALLY clear, not "not exactly clear" as Peterson claims. There is no "may be exempt" about those versions of free PGP. Thay are, in fact, fully licensed for non-commercial use of RSA. He should read the RSAREF license. May have changed but when it first came out I looked into the RSAREF and was rather astounded by the wording of the "free" license agreement - looked like something Microsoft might have written. Wasn't even something the I, as a hobbyist, would sign since the restrictions seemed to outlive the patent. Not going into the fact that you missed my point entirely since it is more properly directed at PGP Inc. - Is there something in the license you have with RSA for the commercial product that limits what you can put into a "free" version without paying RSA a fee ? If that is "no" then I too will ask why the free version should not contain the older mechanisms for compatability. (I use the commercial version so do not know if it does or does not). Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA22653 for ietf-open-pgp-bks; Wed, 26 Nov 1997 09:13:29 -0800 (PST) Received: from mail-oak-1.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA22648 for ; Wed, 26 Nov 1997 09:13:25 -0800 (PST) Received: from relay1.clorox.com (relay.clorox.com [168.189.64.36]) by mail-oak-1.pilot.net with ESMTP id JAA18801 for ; Wed, 26 Nov 1997 09:14:39 -0800 (PST) Received: from Nomad.clorox.com ([168.189.64.106]) by relay1.clorox.com (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-38927U100L100S0) with SMTP id AAA20550 for ; Wed, 26 Nov 1997 09:13:37 -0800 Reply-To: "Paul Rarey" From: "Paul Rarey" To: Subject: Re: The armour issue Date: Wed, 26 Nov 1997 09:20:28 -0800 Message-ID: <002b01bcfa8f$97223500$6a40bda8@Nomad.clorox.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.2039.0 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I've been reading quite a bit about the virtues of MIME vs. ASCII Armor (AA) for secure messages. Frankly - I don't understand the delima. AA was a great tool to solve problems Secure Message Exchange (SME) imposed when AA was envisioned and implemented. AA solved problem's that don't need solving in today's message exchange standards (and.. most relevant.. pervasive installation) for progressing SME as a "dial tone" service. I don't see the fruits of this effort as only germane to SMTP {supporting business to business information transactions (Inter/Intra/Xtra or whatever the flavor of the day wants to call it)}. There is a clear need within my organization's intranet (gee.. the terms we stoop to today....:-) for secure heterogeneous message exchange. Folks.. CICS, IMS, MQ, HTTP, ODBC servers, Notes, --and-- Exchange exchange message units. As the principle architect for infrastructure systems in my organization I can emphatically state - AA has no place, MIME with [ pretty good ] privacy services does. PGP/MIME is an excellent candidate to date.... (MOSS is ..nice.. - but there's little to no chance of pervasive deployment). I have no problem with those that desire inclusion of AA as an option for receiving... then let the market decide on sending. Clorox won't be in the "buy" category for any "Must support send with AA" product.... Some grunt w/a budget.... [ psr ] -----Original Message----- From: Dave Crocker / IMC To: Jon Callas Cc: Gavan Schneider ; ietf-open-pgp@imc.org Date: Tuesday, November 25, 1997 6:52 PM Subject: Re: The armour issue >At 06:01 PM 11/25/97 -0800, Jon Callas wrote: >>or transmitted in any environment that may not be safe to raw binary data. > >so does MIME. > >>For example, PGP key servers transmit keys both to and from the server in > >so can MIME. > >>Armor is also useful for future applications. > >so is MIME. > >>Lastly, there are systems that use (or would like to use) PGP over systems >>that are not the internet. > >Then they are not relevant to an Internet standards process. > >>Furthermore, I disagree with this strongly. MIME is a preferrered way (by > >MIME is the standard way. As I try to make clear, that's not just a matter >of bureaucratic formaltiy, it is a matter of actual use. The purpose of a >standard is to achieve interoperability. The more choices there are, the >less interoperability there is. > >Absent a strong claim as to the technical superiority of armour or >something else, the only reason to support an alternative mechanism which >does the same job is... well, nothing constructive. > >>text describing it was done by Paul Hoffman, who used MIME as a base. So >>it's quite easy to do both. > >The question remains: what functional basis is there for retaining >armouring in the standards-based specification. The argument of >compatibility with the pre-standards installed base has already been >countered for a number of different issues, not just armouring. The idea >of possible uses in the future is an argument for MIME, not a legacy >mechanism. > >>The compromise that I, as editor am working with (with thanks to Ian Brown, >>who came up with it) is as follows: > >Jon, those who serve as working group chairs and document editors have a >difficult job. They are usually senior, talented folk. They get to work >hard and almost never are adequately appreciated. > >Worst of all, they are often architects who do not see their own >preferences chosen. > >The editor of an IETF working group document is required to be responsive >to the rough consensus of the working group. I hope no one has forgotten >this minor point. > >>(1) I'm going to remove anything in OP-FORMAT that requires the use of >>ascii armor. Following my touchstone that any feature needed for backwards >>compatibility is a SHOULD, it'll be a SHOULD. > >Now if you just move it to an appendix and note that it has been the basis >for "packaging" PGP in pre-standards versions of the technology, then we'd >be in perfect shape. This would leave the document with one standard way >to do the packaging, but with full documentation about the prior >(non-standard) way of doing it. > >d/ >-------------------- >Dave Crocker dcrocker@imc.org >Internet Mail Consortium +1 408 246 8253 >675 Spruce Dr. fax: +1 408 249 6205 >Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA22387 for ietf-open-pgp-bks; Wed, 26 Nov 1997 08:59:31 -0800 (PST) Received: from dfw-ix7.ix.netcom.com (dfw-ix7.ix.netcom.com [206.214.98.7]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA22355; Wed, 26 Nov 1997 08:58:06 -0800 (PST) Received: (from smap@localhost) by dfw-ix7.ix.netcom.com (8.8.4/8.8.4) id KAA16961; Wed, 26 Nov 1997 10:58:49 -0600 (CST) Received: from lax-ca66-07.ix.netcom.com(207.223.161.71) by dfw-ix7.ix.netcom.com via smap (V1.3) id rma016880; Wed Nov 26 10:58:03 1997 Message-ID: <347C5511.64407B46@sternlight.com> Date: Wed, 26 Nov 1997 08:57:59 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: "A. Padgett Peterson P.E. Information Security" CC: ietf-open-pgp@imc.org, ietf-smime@imc.org Subject: Re: PGP evolving, improving References: <971125135405.20e14553@hobbes.orl.lmco.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msF9FDBF5E9A87FDB35AAF7313" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------msF9FDBF5E9A87FDB35AAF7313 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit (This message is being copied to the S/MIME list only for the matter in the last paragraph of my response. Readers of the S/MIME list are requested to ignore the matter that is PGP-specific). Peterson is quite mistaken in his post below. Free PGP had used RSAREF (for RSA), a software package made available free by RSADSI for anyone's non-commercial use. No patent issues, fees, or litigation are involved. This is TOTALLY clear, not "not exactly clear" as Peterson claims. There is no "may be exempt" about those versions of free PGP. Thay are, in fact, fully licensed for non-commercial use of RSA. He should read the RSAREF license. The usage has nothing to do with Viacrypt, mergers, or anything else of the sort. It was that package, used in MIT PGP 2.x, (as well as the use of RSA overseas) that produced the huge RSA key base that made PGP's reputation and which they wave in front of the IETF to legitimiize themselves,. That PGP Inc. dropped RSA key generation in Free PGP 5.0 (while continuing to use RSAREF--so it was a completely gratuitous act), and then in Free 5.52 completely disabled any RSA compatibility with that huge user base, is, I assert, unconscionable. SInce they have done that, leaving aside the 'biting the hand that feeds one' aspect, the IETF should not credit any PGP Inc. user base claims involving number of holders of RSA PGP keys. This leaves PGP as a minuscule segment of the market compared with, for example, the installed base of S/MIME applications (well over 25 million) from Netscape and Microsoft. Any IETF standards activities must take account of that physical reality in the marketplace. Of more technical importance, this group should insure that this cannot happen again. "Open" anything should not be designed so that an entire user base of keys and certificates resulting from the standard will later become obsolete just because a post-release algorithm is later added to the standard or an existing algorithm in the release is "improved". PGP Inc., having proven (in my view) their untrustworthiness on this point, should not be allowed any configuration influence at all with an Open PGP standard, and the IETF should insure that no control or influence of any kind over intellectual property can be exercised on Open PGP by PGP Inc. I make this point not as a general principle (since "non-discriminatory access on equitable terms" is the IETF policy mantra despite the attempts of some to go beyond that in the case of S/MIME), but rather because of PGP Inc's specific behavior in obsoleting this entire user base of PGP RSA keyholders in their latest versions of Free PGP.. Finally, a related point. If the pace of the Open PGP standards group is anything like the past history of voluntary PGP efforts (or maybe voluntary anything efforts), by the time the standard is done the RSA patent will have expired (or close enought not to make much difference to reasonable market penetration rates). It seems to me a realistic view of that eventuality and of realistic project scheduling might be useful in avoiding much of the to and fro fussing on this topic as well as totally avoiding all the noise about PGP Inc. vs. RSADSI. So to do would have the advantage that one resultant IETF standard (Open PGP) could be designed to be equally available to commercial users while using as "musts" two widely-trusted algorithms, RSA and TDES. If that thinking were accepted, the focus, as between the Open PGP standard and the S/MIME 3 standard, can become what at least this writer thinks it ought to be--one standard for web of trust and another for rigid heirarchical certification. This would insure the (security) purity of each model, its use for the things it is most suited for, and avoid any attempt to corrupt either (to try to emulate the other and get some of its market share). To do otherwise would lose some of either the free-form character of web of trust, or the exclusionary assurance character of rigid heirarchical. (By "exclusionary" I mean that every certifier must fall within the overall tree structure and to do so must meet specified, audited standards for certification operations assured from the top down, as an "if and only if" condition.) David A. Padgett Peterson P.E. Information Security wrote: > Note: this is really politics and not RFC business - my apologies but something > of a sore point. > > David rote: > > >And free PGP users didn't deserve an eased upgrade path, but rather to forcibly > >obsolete all their keys, signatures and web of trust in the new version? > >Especially since the RSA-key Free PGP user base is where PGP Inc. made their > >reputation and the size of that base is constantly cited to the IETF and in > >press releases as PGP's "customer base". Don't be ridiculous. And watch who you > >throw stones at--can you say "glass house"? > > Am surprised at this posting as it seems to forget one major problem: RSA is > patented. I have been told repeatedly by PGP that one of the reasons they do > not offer a site license (nor a real personal license for that matter in the > sense of being authorized to operate on all solely-used computers) is a > requirement by RSA for a "per CPU" fee. > > True, the "free" version may be exempt under the terms of the patent but > this has never been exactly clear. Do suspect that when PGP and Viacrypt > did their inverse triangular multibuyout which resulted in a common point > for both free and commercial versions that some of the clauses of the RSA > license began covering PGP Inc and thus the "free" version as well (do you > realize that there are fifty thousand lawyers in Florida alone ? Twice as > many Southern Bell yellow pages of attorneys as doctors and churches > combined ?) > > Would be nice if RSA put the mechanism into the public domain but since they > reniged on the S/MIME components, I have doubts that this will happen. > > Sounds like an opportunity for some programmer to create a "front end" to > determine which is being used and to invoke the correct version but this is > the reason that RSA (or any proprietary mechanism) should *never* be a MUST. > > Warmly, > Padgett --------------msF9FDBF5E9A87FDB35AAF7313 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKjQYJKoZIhvcNAQcCoIIKfjCCCnoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CIUwggPPMIIDOKADAgECAhAnuK6izE0BOIf7uTQQ8usCMA0GCSqGSIb3DQEBAgUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA4MjEwMDAw MDBaFw05ODA4MjEyMzU5NTlaMIIBEjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDIgLSBOZXRzY2FwZTEZMBcGA1UEAxMQRGF2aWQgU3Rlcm5saWdodDEjMCEGCSqGSIb3 DQEJARYUZGF2aWRAc3Rlcm5saWdodC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN09h1fHJlSiS54oM5YjKy9J6wMmjUFL58Xkwc6JiCBftinxpbm2ziTPSAn4TMhSVbZnuC1m oDZln2HSvkRS61+BwYL3yw9kus2/Tyoi4gparm1O+CRlRkudAP8w7cHax6AZXTr7KDQA/mOq nXSPERdO3XZIgvVRXvL7VIVt++F7AgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0gBIGn MIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24A AAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBAgUAA4GBAE8QvB3wHstP4Ggj +WuQRdIKOsO4U3F5mUjfle6hatqCA1fvD3Kzmrr4KSvBes2CH0BKV/Mmb/rRkkwXaspTkSIC 0ENT789yEuv/aoOVogJVaKYHz7bgNkSuwa6O8SKHkrGHdQRxl3J+GN1SEgOzkW7A15d702QM 0tR6rtxMvtxYMIICeTCCAeKgAwIBAgIQUNNSlJEvedMV4ysxrIVI8DANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3 MDAwMDAwWhcNOTgwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlk dWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+b yB2eT7R1731MMPOyqjS/mdtGxtSYxx1FDuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqt WhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCI cp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCG SAGG+EIBAQQEAwICBDANBgkqhkiG9w0BAQIFAAOBgQAN6OSPQTmZ8ouFAbfodckgYj0dsq43 RhipxsLh/k6LwgZbQUbv8sxw0AEqFp5AUak+wBPYFljrwLCW/qnQZbM1RsFBCP6IlPSbtgyv YbUZrIGeVCdsNpBTxypskPapJdjkip4YXyd8jdn10TX+OZmd7OjE9vRuXjCXTgiI0JmvnzCC AjEwggGaAgUCowAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFg a355LPoGDzqu9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fM CGw/PrNK/P9LbCPVUIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQAD gYEAe6+kHC/Amw47XPyo5tGWD0hySYXlrxojAOPpu4A0bLI/hKg8cnCzTN5z+nyE0pKlADcJ wgM0IwO37XaW3D5Phf1YF/QEvuxRHtx629uu6GF42mU4R6wdA3Bt6eO7oEqfQOq823O/Z01d xnwgXOfoogorwgl010z+2+lrAmNdOacxggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVy bmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQJ7iuosxNATiH+7k0EPLrAjAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTEy NjE2NTgwMVowIwYJKoZIhvcNAQkEMRYEFCyjOGRcBQ7uqe31AyXFZamr4rjoMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAbnxLwVc5BFTY7p1rmnxq l5TbH0csZztE9KwRx4YtINHLtoCStPiYs1ZYCu4KyvdenjTQEhxkscSpq+Dhf+xezmGZFu2c OlHwLkkgwH3X7UJr+bG/IP29xqwiHQBLYwiXKQW4eJh5/erNfmgzWymVDHjKohgl8o1+cFUz t6Tq4FU= --------------msF9FDBF5E9A87FDB35AAF7313-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA17899 for ietf-open-pgp-bks; Wed, 26 Nov 1997 03:44:21 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA17895 for ; Wed, 26 Nov 1997 03:43:59 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 26 Nov 1997 11:44:56 +0000 Message-ID: <347C0AFC.C828F3AB@cs.ucl.ac.uk> Date: Wed, 26 Nov 1997 11:41:48 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jon Callas , IETF OpenPGP Subject: Re: The armour issue References: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Ascii armor allows PGP binary data to be held or transmitted in > any environment that may not be safe to raw binary data. Can you give us an example of this apart from mail? Web-based keyservers only use armour because they are based on mail servers. HTTP allows binary data to be transferred directly. >From RFC 2068 (HTTP 1.1) Transfer codings are analogous to the Content-Transfer-Encoding values of MIME , which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport. I can see very little reason why people would want to store PGP data armoured in a system that supports 8-bit data. > There are other applications that use PGP technology > for authentication, enveloping, etc. and use armor. Is this because they transfer data by mail? > I am presently working with > someone who is using the new extension mechanism to build an SPKI-like > authorization system for a network server. They want to use armored > blocks. Unless they want to transmit data by mail, there is no need for them to. They can send it as 8-bit data. If they do need to, they can use MIME as they don't need backwards compatibility. > Lastly, there are systems that use (or would like to use) PGP over systems > that are not the internet. I have given the example of pager systems > before. There are other systems that use telephones, private networks, or > other non-Internet means of data transfer. I would have thought the vast majority of non-Internet means of data transfer allow 8-bit data to be transmitted over them. > Armor has little to do with message > transmission, and everything to do with *OBJECT* (keys, authorizations, > etc.) transmission. PGP objects are made up of binary packet(s). They have very little to do with armour. The labelling is in most cases a convenience feature. For example: -----BEGIN PGP SIGNATURE----- jhglhgd876876jhJkjgJGKJlkjljkgjhg... -----END PGP SIGNATURE----- contains a binary encoded Signature packet. It is the format of the underlying binary data which defines the object, not the armour. > To forbid armor is to say that there is no conceivable use for it. No-one has suggested this. > Armor itself is > still a preferred way of transmitting OP objects that are not messages. Could you give us a case where it is vital to the understanding of an object that it is armoured - i.e. just interpreting the underlying binary packet(s) will not give you the full meaning of the object. > (1) I'm going to remove anything in OP-FORMAT that requires the use of > ascii armor. Following my touchstone that any feature needed for backwards > compatibility is a SHOULD, it'll be a SHOULD. > > (2) A description of OP-MIME will be in Michael Elkin's RFC 2015. In this case, RFC2015 need updating as it currently *requires* the use of Armour. > We'll leave it to implementors which they prefer to implement and > encourage the use of MIME for messages. Perfect! Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA11920 for ietf-open-pgp-bks; Tue, 25 Nov 1997 20:51:52 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA11915 for ; Tue, 25 Nov 1997 20:51:46 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id HAA06337; Wed, 26 Nov 1997 07:19:08 +0100 (MET) Message-ID: <347BAB50.FDA0280@systemics.com> Date: Wed, 26 Nov 1997 04:53:36 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Bill Stewart CC: Adam Back , ietf-open-pgp@imc.org Subject: Re: expediency and avoidance of politics References: <3.0.3.32.19971125141036.006f61b4@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart wrote: > We should probably mark Subpacket Type 10 as "reserved" or something. Spot on, Bill. I was thinking along these lines today. Avoidance of any name means that there is no possibility of endorsement or future confusion along those lines. Marking it as an RFU leaves PGP Inc free to use it within their proprietary client sites, until they are ready to propose this method as general and successful enough to be admitted to the standard. And as an experimental system, the right thing to do is to mark out the space, and wait for PGP Inc to get back to us with a case. As an informational RFC or a proposed extension, this is fine. It also does more merit to the question, as it is far more complex than one bit or field can cope with. Seems like a win for everbody, no? If we are agreed that type 10 is marked as reserved for future use, then we can move ahead. > Figuring out the semantics of the Critical Bit is going to be more complex. I think I've made my case that this is a "bad thing" at this stage, I'll see what others say. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA10657 for ietf-open-pgp-bks; Tue, 25 Nov 1997 18:45:15 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA10650 for ; Tue, 25 Nov 1997 18:45:07 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id NAA04269; Wed, 26 Nov 1997 13:43:15 +1100 Received: from shirley (dformosa@dialin-29 [137.154.130.29]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id NAA04218; Wed, 26 Nov 1997 13:43:01 +1100 (EST) Date: Wed, 26 Nov 1997 12:27:25 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Jim McCoy cc: ietf-open-pgp@imc.org, platypus@acmeonline.net Subject: Re: Armour In-Reply-To: <3.0.3.32.19971124110041.007138c0@mail.communities.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 24 Nov 1997, Jim McCoy wrote: [...] > David Formosa wrote: > >The second group is all the scrips, hacks, glue and basic > >applications of cyrto wich works with pgp[2|5]. [...] > Why do these things need to use 7-bit armored output? [...] (although I > would not doubt that lazy script writers keyed on things like ---BEGIN > PGP...) Its more the hacks like that then 7-bit armored nature of the post itself. Most of the applications work off the PGP delimitters. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHt7AqQK0ynCmdStAQExlgP+J5op7uVa55gc3LmDKWQcmrOaHNPwqAs0 CCe1M+xF8ywao6bfGUm8eUkdnVn2hxnBGcKq91kRA2ZFzejfrrifb8a35uICV/Po 95qYInIk4GUwNzvITnmSXHceXN0jB+bZhWN+1pdZAVamtVf2tEDVR6cp03FyUTYx XR6TIQHHGUc= =33tZ -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA10624 for ietf-open-pgp-bks; Tue, 25 Nov 1997 18:42:52 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA10617 for ; Tue, 25 Nov 1997 18:42:44 -0800 (PST) Received: from omni.imc.org (pm3-105.netgate.net [205.214.163.105]) by proper.com (8.8.7/8.7.3) with SMTP id SAA27773; Tue, 25 Nov 1997 18:40:49 -0800 (PST) Message-Id: <199711260240.SAA27773@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 2 (build 233) Date: Tue, 25 Nov 1997 18:41:40 -0800 To: Jon Callas From: Dave Crocker / IMC Subject: Re: The armour issue Cc: Gavan Schneider , In-Reply-To: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> References: <199711260029.LAA27395@magna.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 06:01 PM 11/25/97 -0800, Jon Callas wrote: >or transmitted in any environment that may not be safe to raw binary data. so does MIME. >For example, PGP key servers transmit keys both to and from the server in so can MIME. >Armor is also useful for future applications. so is MIME. >Lastly, there are systems that use (or would like to use) PGP over systems >that are not the internet. Then they are not relevant to an Internet standards process. >Furthermore, I disagree with this strongly. MIME is a preferrered way (by MIME is the standard way. As I try to make clear, that's not just a matter of bureaucratic formaltiy, it is a matter of actual use. The purpose of a standard is to achieve interoperability. The more choices there are, the less interoperability there is. Absent a strong claim as to the technical superiority of armour or something else, the only reason to support an alternative mechanism which does the same job is... well, nothing constructive. >text describing it was done by Paul Hoffman, who used MIME as a base. So >it's quite easy to do both. The question remains: what functional basis is there for retaining armouring in the standards-based specification. The argument of compatibility with the pre-standards installed base has already been countered for a number of different issues, not just armouring. The idea of possible uses in the future is an argument for MIME, not a legacy mechanism. >The compromise that I, as editor am working with (with thanks to Ian Brown, >who came up with it) is as follows: Jon, those who serve as working group chairs and document editors have a difficult job. They are usually senior, talented folk. They get to work hard and almost never are adequately appreciated. Worst of all, they are often architects who do not see their own preferences chosen. The editor of an IETF working group document is required to be responsive to the rough consensus of the working group. I hope no one has forgotten this minor point. >(1) I'm going to remove anything in OP-FORMAT that requires the use of >ascii armor. Following my touchstone that any feature needed for backwards >compatibility is a SHOULD, it'll be a SHOULD. Now if you just move it to an appendix and note that it has been the basis for "packaging" PGP in pre-standards versions of the technology, then we'd be in perfect shape. This would leave the document with one standard way to do the packaging, but with full documentation about the prior (non-standard) way of doing it. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA10321 for ietf-open-pgp-bks; Tue, 25 Nov 1997 18:15:57 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA10315 for ; Tue, 25 Nov 1997 18:15:45 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id NAA03857 for ; Wed, 26 Nov 1997 13:15:28 +1100 Received: from shirley (dformosa@dialin-29 [137.154.130.29]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id NAA15201 for ; Wed, 26 Nov 1997 13:15:25 +1100 (EST) Date: Wed, 26 Nov 1997 11:59:46 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: ietf-open-pgp@imc.org Subject: Re: Armour In-Reply-To: <347935B2.36C64BA7@systemics.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Mon, 24 Nov 1997, Ian Grigg wrote: > Dave Crocker / IMC wrote: [...] > > 2. Installed base compatibility > > > > It has been observed a number of times that that is already lost for > > other reasons, so use of MIME rather than Armour does not create a new > > problem. [...] > 1. Is this WG happy to take as a given, or a working assumption, or a > fundamental position (pick your own term), that the compatibility with > the installed base is lost? I am not happy with this assumpion/position installed base compasty is only realy lost for a subset of users. Thouse living outside the range of the patents or willing to bye a licence can recover backwards capasity. That being said the loss of armour would create a new problem for the unemcombered population. > 2. If compatibility with the installed base (as inferred above) is > *not* lost, does the proposal that MIME should "replace" Armour > (ignoring how&what) still have any merit? Advanigers for Mime Preexisting code liberys. Neetness of standerisation Advanigers for Armour Interoperbility with existing versons of PGP Interoperbility with existing scrips. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHt0iKQK0ynCmdStAQHHgAQAtrvh79unK1zlEM9r9eHC84+FCfCcpNZQ YkvxAhr/t6O2uqQCHTGOQ1awDAjujfXkTWhj5C6y112XA8Ne6c7qgAc4fcUo0/04 rjHhEj678eKg9DqbsTROGEu6TO6fYHX/KhLfLRZWopqJqmhZIpL+4mp1IINlskl/ K3UP8AAs5nI= =o7Nj -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA10134 for ietf-open-pgp-bks; Tue, 25 Nov 1997 17:59:58 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA10129 for ; Tue, 25 Nov 1997 17:59:55 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id SAA11200; Tue, 25 Nov 1997 18:00:56 -0800 (PST) Message-Id: <3.0.3.32.19971125180105.00a5ab50@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 25 Nov 1997 18:01:05 -0800 To: Gavan Schneider , From: Jon Callas Subject: Re: The armour issue In-Reply-To: <199711260029.LAA27395@magna.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:29 AM 11/26/97 +1100, Gavan Schneider wrote: Thanks for writing this up. I'm addressing your message as a logical argument. Please forgive the pickiness that follows. My premises: PGP ascii-armour is a 7-bit ascii form of the 8-bit encrypted content, includes a fixed line-wrap, and uses base64 encoding. This allows transmission through 7-bit channels over the internet. This is true, but incomplete. Ascii armor allows PGP binary data to be held or transmitted in any environment that may not be safe to raw binary data. For example, PGP key servers transmit keys both to and from the server in ascii armoured blocks. There are other applications that use PGP technology for authentication, enveloping, etc. and use armor. Armor is also useful for future applications. I am presently working with someone who is using the new extension mechanism to build an SPKI-like authorization system for a network server. They want to use armored blocks. Lastly, there are systems that use (or would like to use) PGP over systems that are not the internet. I have given the example of pager systems before. There are other systems that use telephones, private networks, or other non-Internet means of data transfer. Therefore armour has little to do with files stored on disk, and a lot to do with email transmission, which is where mime comes into play. Well, this isn't a premise, this is a conclusion. Structurally, it's not fair to start derivations in your statement of premises of an argument. Even so, logically, I don't see what chain of reasoning leads one to conclude this from the previous paragraph. Furthermore, I disagree with this strongly. MIME is a preferrered way (by many people) to encode email transmissions. Many people believe it is *the* preferred way to transmit email. Other people believe that MIME is the best solution long term, but not at the present date. Still other people don't like MIME at all. I think we've heard on this list from representatives of all of these classes of people. Armor has little to do with message transmission, and everything to do with *OBJECT* (keys, authorizations, etc.) transmission. Lastly, for what it's worth, factually there are cases where armored PGP objects are stored on a disk, in spite of its inefficencies. In any event, this is an implementor's decision. To forbid armor is to say that there is no conceivable use for it. There are already mime formats for asciified binary, eg., base64, which mime compliant applications already need to implement. So there is no need for additional code if O/PGP uses existing mime/base64 as the format to protect the encrypted binary data during transmission over 7-bit channels. This also means there is no particular need to keep the PGP version of ascii-armour in the O/PGP standard. I agree with the first part, but not the last. There is no need to keep PGP's armor only if all applications that do not want to use raw binary want to use MIME. If there is one application that falls in the middle, then there is a need. We may choose to discount this need in the standard, but the need still exists. Again, pickily, this mixes conclusions with the premises. But there is a need to specify the encapsulation of O/PGP email parts as they are interpreted by the mime parsing system. I personally think the standard should specify base64 and not leave it to printed quotable. I accept that since printed quotable is not actually wrong (just less efficient) this issue would he handled by way of very strong advice in the standard. Base64 increases a message size by 25%. (Each byte transmitted carries 6-bits of original information). Actually, it increases the message size by 1/3. Three octets of data become four octets of armor. There is thus a 1 octet overhead for each 3 octets of actual data for an overhead of 33 1/3%. Printed quotable would more than double the message size since about half the bytes of the encrypted text would have the high order bit true (ie., char [128..255]) and need to be encoded with a 3 byte sequence, eg. "=9A", the char "=" is coded as "=3D". Not to mention the soft wrapping "=\r" sequence every 80 characters. Ref: "Winning the MIME QP Doll" by Will Mayall NetBITS#005/23-Oct-97 Both formats (base64 and printed quotable) break the transmitted text into lines of about 80 characters. These are removed by the receiving end during decoding/unpacking. Depending on the system base64 adds 1 [Unix,MacOS] or 2 [DOS,WIN] characters per line, printed quotable adds an extra one again. My conclusions: 1. Printed quotable should be avoided for the encrypted message body because of its much higher overhead. No one has ever suggested such a thing, and I would be surprised if anyone disagreed. 2. Existing mime/base64 encapsulation can replace PGP ascii-armour in the O/PGP standard for transmission of encrypted email over the internet. I agree completely. For email etc. (Dave Crocker has written some nice words on how in spite of its acronym, MIME isn't just for mail, so I say email etc.) MIME is long-term the preferred way to go. Armor itself is still a preferred way of transmitting OP objects that are not messages. 3. The O/PGP standard will not incur higher implementation cost by using mime/base64, rather it will be using existing code. Actually, PGP's ascii armor uses the same mechanisms as MIME's base 64. The text describing it was done by Paul Hoffman, who used MIME as a base. So it's quite easy to do both. The compromise that I, as editor am working with (with thanks to Ian Brown, who came up with it) is as follows: (1) I'm going to remove anything in OP-FORMAT that requires the use of ascii armor. Following my touchstone that any feature needed for backwards compatibility is a SHOULD, it'll be a SHOULD. (2) A description of OP-MIME will be in Michael Elkin's RFC 2015. (3) We'll leave it to implementors which they prefer to implement and encourage the use of MIME for messages. (4) I'm going to restructure the placement the armor discussion in OP-FORMAT so that it doesn't just spew from section 2, which is supposed to be an introductory section. It'll get its own chapter towards the back of the document. I'm going to digress here and note that in the WG's charter, we are to strive for "limited backwards compatibility." These are weasel-words. Full backwards compatibility is desirable, but not possible. When necessary, we will break backwards compatibility, but we won't do it gratuitously. I think that encouraging and supporting the use of MIME is a Good Thing, but forbidding armor is draconian and an overreaction. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA09670 for ietf-open-pgp-bks; Tue, 25 Nov 1997 17:16:37 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA09666 for ; Tue, 25 Nov 1997 17:16:23 -0800 (PST) Received: from s20.term1.sb.rain.org (s17.term1.sb.rain.org [198.68.144.147]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id RAA00364; Tue, 25 Nov 1997 17:19:07 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id RAA29633; Tue, 25 Nov 1997 17:03:08 -0800 Date: Tue, 25 Nov 1997 17:03:08 -0800 From: Hal Finney Message-Id: <199711260103.RAA29633@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, roessler@guug.de Subject: Re: V4 Fingerprints Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Thomas Roessler, , writes: > >From the draft: > 8.2 V4 Key IDs and Fingerprints > [...] > > This seems to imply that the fingerprint is always > generated as the hash over an old-style public key packet > with a two-byte length qualifier and the appropriate > packet tag. Is this correct and intended? Yes, this is correct, for the new 20-byte fingerprints. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA09073 for ietf-open-pgp-bks; Tue, 25 Nov 1997 16:29:14 -0800 (PST) Received: from magna.com.au (mail.magna.com.au [203.4.212.90]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA09069 for ; Tue, 25 Nov 1997 16:29:04 -0800 (PST) Received: from [203.10.19.150] (schneider.magna.com.au [203.10.19.150]) by magna.com.au (8.8.5/8.6.10) with SMTP id LAA27395 for ; Wed, 26 Nov 1997 11:29:36 +1100 (EST) Message-Id: <199711260029.LAA27395@magna.com.au> Subject: Re: The armour issue Date: Wed, 26 Nov 97 11:29:38 +1100 x-mailer: Claris Emailer 2.0v2, June 6, 1997 From: Gavan Schneider To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Quoting A. Padgett Peterson P.E. Information Security on or about 1997/11/26 05:25 Sydney time- > >>Compatibility with Classic PGP has become optional. All OP implementations >>will be compatible with each other. I suspect most will also be compatible >>with the Classic PGP, but that's up to implementers and users. > >Agree in principle. Armour/Mime/etc is really a mail issue with one >exception: >I would really be bothered if installation of PGPv14 made it impossible to >decrypt the thousands of instances of malicious software I keep in the >original PGP message format (easy to tell who it came from). Would also >like to read the ones received in the future as well. > ...snip... > >So would like to see something such as it MUST be an OPTION to any product >claiming PGP compatibility (is there such a thing as a mandatory option ?). >Personally, would not mind paying extra for the capability but would want to >be sure that it was available (I know - keep the old version around. Ever >read an upgrade license ?). > At the risk of sounding pedantic and apologies if this is really an example of very dry humour (if intended it is very good :-) A 'mandatory option' sets the scene where a product can only be compliant if there is an option to support some list of old (proprietary) implementations. And products which do support these implementations must allow this function to be disabled. In order to bring the implementations into the standard (ie., they cannot remain proprietary) each version of PGP Inc. product (and Phil Z.'s shareware versions) would have to have an exact definition of its behaviour spelled out into the O/PGP standard along with the proposed behaviour we are now discussing. One result of the O/PGP standard will (I hope) be more than one O/PGP standard compliant product. One of those versions will no doubt come from PGP Inc. And PGP Inc. can (and should) use backwards compatibility as one of many product differentiations in the market place. Others may also want to add this feature. This is a commercial and licensing issue. The O/PGP standard does not need to mandate backwards compatibility (it can but does not have to). IMHO this functionality should be left to actual products. Which leads me back to the issue of this thread viz., ascii-armour. I have watched this issue over a couple of threads, joined some ideas, added my thoughts, had some help Dave Crocker , and present the following (hopefully useful) summary. (Many thanks to Dave but the opinions and mistakes are mine :-) My premises: PGP ascii-armour is a 7-bit ascii form of the 8-bit encrypted content, includes a fixed line-wrap, and uses base64 encoding. This allows transmission through 7-bit channels over the internet. Therefore armour has little to do with files stored on disk, and a lot to do with email transmission, which is where mime comes into play. There are already mime formats for asciified binary, eg., base64, which mime compliant applications already need to implement. So there is no need for additional code if O/PGP uses existing mime/base64 as the format to protect the encrypted binary data during transmission over 7-bit channels. This also means there is no particular need to keep the PGP version of ascii-armour in the O/PGP standard. But there is a need to specify the encapsulation of O/PGP email parts as they are interpreted by the mime parsing system. I personally think the standard should specify base64 and not leave it to printed quotable. I accept that since printed quotable is not actually wrong (just less efficient) this issue would he handled by way of very strong advice in the standard. Base64 increases a message size by 25%. (Each byte transmitted carries 6-bits of original information). Printed quotable would more than double the message size since about half the bytes of the encrypted text would have the high order bit true (ie., char [128..255]) and need to be encoded with a 3 byte sequence, eg. "=9A", the char "=" is coded as "=3D". Not to mention the soft wrapping "=\r" sequence every 80 characters. Ref: "Winning the MIME QP Doll" by Will Mayall NetBITS#005/23-Oct-97 Both formats (base64 and printed quotable) break the transmitted text into lines of about 80 characters. These are removed by the receiving end during decoding/unpacking. Depending on the system base64 adds 1 [Unix,MacOS] or 2 [DOS,WIN] characters per line, printed quotable adds an extra one again. My conclusions: 1. Printed quotable should be avoided for the encrypted message body because of its much higher overhead. 2. Existing mime/base64 encapsulation can replace PGP ascii-armour in the O/PGP standard for transmission of encrypted email over the internet. 3. The O/PGP standard will not incur higher implementation cost by using mime/base64, rather it will be using existing code. Regards, Gavan Gavan Schneider | In a world without fences, | who needs Gates? Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA07344 for ietf-open-pgp-bks; Tue, 25 Nov 1997 14:21:17 -0800 (PST) Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA07340 for ; Tue, 25 Nov 1997 14:21:12 -0800 (PST) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id QAA02180; Tue, 25 Nov 1997 16:21:15 -0600 (CST) Received: from pax-ca13-21.ix.netcom.com(204.31.233.53) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma002163; Tue Nov 25 16:20:55 1997 Message-Id: <3.0.3.32.19971125141036.006f61b4@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 25 Nov 1997 14:10:36 -0800 To: Adam Back , ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: expediency and avoidance of politics In-Reply-To: <199711250013.AAA02465@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:13 AM 11/25/1997 GMT, Adam Back wrote: >It seems to me that the debate over CMR and it's more secure >alternatives could easily be deferred to OpenPGPv2 with no >compatibility issues. > >The way that CMR/ARR field is encoded in the draft is that it is a >signature subpacket type. Signature subpacket types are extensible; >that is an implementation already has a defined method to safely >ignore subpackets it does not understand. This means that no one will >experience compatibility problems if the experimental CMR subpacket is >only implemented by PGP Inc. I agree. We should probably mark Subpacket Type 10 as "reserved" or something. Figuring out the semantics of the Critical Bit is going to be more complex. >- it would allow more time for PGP Inc to get feed-back on this > controversial experimental feature from their customers as to how > CMR performs functionally in practice (I am expecting there will > be complaints about the lack of ergonomic recovery from forgotten > passphrases -- all files have to be re-encrypted), how the security > of the system holds up (how well companies are managing very > sensitive CMR master keys), and to gauge customers acceptance of the > feature politically. >- it will give time for more secure competing proposals (such as local > escrow) to be developed for recovery from forgotten passphrases. Yeah, Stealth is going to take some discussion, and OPv2 is probably a good venue for it. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA06774 for ietf-open-pgp-bks; Tue, 25 Nov 1997 13:45:04 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA06761 for ; Tue, 25 Nov 1997 13:44:56 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id AAA05191; Wed, 26 Nov 1997 00:14:15 +0100 (MET) Message-ID: <347B47BE.7A0F4A02@systemics.com> Date: Tue, 25 Nov 1997 21:48:46 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Adam Back CC: ietf-open-pgp@imc.org Subject: Re: expediency and avoidance of politics References: <199711250013.AAA02465@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > > It seems to me that the debate over CMR and it's more secure > alternatives could easily be deferred to OpenPGPv2 with no > compatibility issues. ... > Avoiding, or deferring the political debate seems like it would be a > good idea for a number of reasons: > > - it would allow us to focus on getting OpenPGPv1 out in a timely > manner. Agreed. The existance of the CMR/AAR field could erupt again I guess. > - it would allow more time for PGP Inc to get feed-back on this > controversial experimental feature from their customers as to how > CMR performs functionally in practice (I am expecting there will > be complaints about the lack of ergonomic recovery from forgotten > passphrases -- all files have to be re-encrypted), how the security > of the system holds up (how well companies are managing very > sensitive CMR master keys), and to gauge customers acceptance of the > feature politically. I'd also add that it would allow more time to actually develop internal experience with this method. The design as I understand it has existed on paper for some time, and within the code since pgp5.0, but has not really been deployed until recently at test sites. Such a change of infrastructural import needs to be put in the field for some time before we could really state that it is working how we intended. As there's no evidence that any experience has been gained, it remains in the "interesting proposal" basket, contents of which aren't really ready for prime time WG consideration. > - it will give time for more secure competing proposals (such as local > escrow) to be developed for recovery from forgotten passphrases. Yeah, well, enhancement of competition, the level playing field, all that interventionist stuff, is not really in the mission statement for the IETF. Not that I don't sympathise with your paper that is :-) > The consolidation phase would then be in OpenPGPv2 where the better > solution would be chosen in OpenPGPv2 for standardisation. You could say that the choice phase is conducted in the market place, and the acceptance phase is the job of V2. But, in an absence of competition, no choice is possible. So no decision at this time. (my incoming mail's been broken for a day or two, so this might be out of time.) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA06204 for ietf-open-pgp-bks; Tue, 25 Nov 1997 13:06:31 -0800 (PST) Received: from koobera.math.uic.edu (qmailr@koobera.math.uic.edu [131.193.178.247]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA06200 for ; Tue, 25 Nov 1997 13:06:27 -0800 (PST) Received: (qmail 21934 invoked by uid 666); 25 Nov 1997 21:08:15 -0000 Date: 25 Nov 1997 21:08:15 -0000 Message-ID: <19971125210815.21933.qmail@cr.yp.to> From: "D. J. Bernstein" To: ietf-open-pgp@imc.org Subject: 103-microsecond 2048-bit verification on a Pentium-133 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have a variant of the Rabin-Williams signature system that speeds up verification by an order of magnitude with no effect on security. This might be useful for web pages or USENET postings. See http://pobox.com/~djb/papers/sigs.ps. > People have been scared of Rabin encryption because it has a chosen > ciphertext attack which reveals the key. Rabin's signature system, as published in 1979, uses a one-way hash function and is invulnerable to chosen-message attacks. (The original RSA signature system was vulnerable, as were various oversimplified versions of Rabin's system.) The only reason to use RSA signatures instead of Rabin signatures is to line RSADSI's pockets. ---Dan Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA05008 for ietf-open-pgp-bks; Tue, 25 Nov 1997 11:54:00 -0800 (PST) Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA05003 for ; Tue, 25 Nov 1997 11:53:55 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with UUCP id UAA24892 for ietf-open-pgp@imc.org; Tue, 25 Nov 1997 20:54:26 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id SAA22193 ; Tue, 25 Nov 1997 18:49:10 +0100 Message-ID: <19971125184910.42970@sobolev.rhein.de> Date: Tue, 25 Nov 1997 18:49:10 +0100 From: Thomas Roessler To: ietf-open-pgp@imc.org Subject: V4 Fingerprints Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88.3 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >From the draft: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 8.2 V4 Key IDs and Fingerprints A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag, followed by the two-octet packet length, followed by the entire Public Key packet starting with the version field. The key ID is either the low order 32 bits or 64 bits of the fingerprint. Here are the fields of the hash material, with the example of a DSA key: a.1) 0x99 (1 byte) a.2) high order length byte of (b)-(f) (1 byte) a.3) low order length byte of (b)-(f) (1 byte) b) version number = 4 (1 byte); c) time stamp of key creation (4 bytes); e) algorithm (1 byte): 17 = DSA; f) Algorithm specific fields. Algorithm Specific Fields for DSA keys (example): f.1) MPI of DSA prime p; f.2) MPI of DSA group order q (q is a prime divisor of p-1); f.3) MPI of DSA group generator g; f.4) MPI of DSA public key value y (= g**x where x is secret). <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< This seems to imply that the fingerprint is always generated as the hash over an old-style public key packet with a two-byte length qualifier and the appropriate packet tag. Is this correct and intended? tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 1280/593238E1 · AE 24 38 88 1B 45 E4 C6 03 F5 15 6E 9C CA FD DB Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03959 for ietf-open-pgp-bks; Tue, 25 Nov 1997 10:53:50 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA03955 for ; Tue, 25 Nov 1997 10:53:46 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EK700M78TUCB5@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Tue, 25 Nov 1997 13:54:14 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EK70031GTU969@lmco.com> for ietf-open-pgp@imc.org; Tue, 25 Nov 1997 13:54:12 -0500 (EST) Date: Tue, 25 Nov 1997 13:54:05 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: PGP evolving, improving To: david@sternlight.com Cc: ietf-open-pgp@imc.org Message-id: <971125135405.20e14553@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Note: this is really politics and not RFC business - my apologies but something of a sore point. David rote: >And free PGP users didn't deserve an eased upgrade path, but rather to forcibly >obsolete all their keys, signatures and web of trust in the new version? >Especially since the RSA-key Free PGP user base is where PGP Inc. made their >reputation and the size of that base is constantly cited to the IETF and in >press releases as PGP's "customer base". Don't be ridiculous. And watch who you >throw stones at--can you say "glass house"? Am surprised at this posting as it seems to forget one major problem: RSA is patented. I have been told repeatedly by PGP that one of the reasons they do not offer a site license (nor a real personal license for that matter in the sense of being authorized to operate on all solely-used computers) is a requirement by RSA for a "per CPU" fee. True, the "free" version may be exempt under the terms of the patent but this has never been exactly clear. Do suspect that when PGP and Viacrypt did their inverse triangular multibuyout which resulted in a common point for both free and commercial versions that some of the clauses of the RSA license began covering PGP Inc and thus the "free" version as well (do you realize that there are fifty thousand lawyers in Florida alone ? Twice as many Southern Bell yellow pages of attorneys as doctors and churches combined ?) Would be nice if RSA put the mechanism into the public domain but since they reniged on the S/MIME components, I have doubts that this will happen. Sounds like an opportunity for some programmer to create a "front end" to determine which is being used and to invoke the correct version but this is the reason that RSA (or any proprietary mechanism) should *never* be a MUST. Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03674 for ietf-open-pgp-bks; Tue, 25 Nov 1997 10:28:46 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA03653 for ; Tue, 25 Nov 1997 10:28:21 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id NAA09256; Tue, 25 Nov 1997 13:29:03 -0500 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id NAA12134; Tue, 25 Nov 1997 13:29:02 -0500 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA59130; Tue, 25 Nov 1997 13:29:02 -0500 From: Uri Blumenthal Message-Id: <9711251829.AA59130@watpub1.watson.ibm.com> Subject: Re: PGP evolving, improving To: aba@dcs.ex.ac.uk (Adam Back) Date: Tue, 25 Nov 1997 13:29:02 -0500 (EST) Cc: ietf-open-pgp@imc.org In-Reply-To: <199711250233.CAA07069@server.test.net> from "Adam Back" at Nov 25, 97 02:33:45 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back says: > > Also, since this is an IETF forum, let me remind you, that the > > official IETF security guideline is: "For all the new standards > > MD5 shall not be used - but SHA-1". > > MD5 is in the draft as a MAY. You want to change that to a MUST NOT? Oh, certainly not. I was simply pointing out that "MUST" for the new drafts should exclude MD5. "MAY" - is a different story, and I personally see no reason why backward compatibility cannot be offered as an option. With the understanding that an implementor does not HAVE to be backward compatible - it's just nice of him, if he is. > I don't think the situation with MD5 is serious enough currently to > warrant the loss of backwards compatibility as an implementation > option. IESG does not require this either, to the best of my knowledge. Actually, even SHA-1 MUST and MD5 SHOULD would wash well, I think. > Where we came in to this discussion was that by having backwards > compatibility more people migrate to new algorithms more quickly. Granted - except I think we differ on where the crucial backwards compatibility is. For me [apologies for repeating myself :-] the "schwerpunkt" is the external interface - the ability or inability to use the existing software by just editing config files and dropping a new PGP executable in. > > ...............but I absolutely hate > > the fact that I can no longer use Mailcrypt-3.4 from XEmacs. > > Well I use mailcrypt also, so I can share on that one. However I keep > getting emails from people with pgp5.x which are addressed to my RSA > key, and yet which pgp2.x simply can't read. I think this must either > be the bug Hal described, or people are signing the message with a DSS > key which I thought pgp5.x was supposed to warn against when the > recipient is using an RSA key. Don't know... Maybe Hal could comment? > > Yes and no. Of course transparency will help. HOWEVER, many of PGP > > users have either no time, or no skills (or "no" both) to modify > > the software that interfaces between their favorite whatever > > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part > > is taken care of - don't expect people to switch. > > I think mailcrypt users are small in number. We should ask Pat > LoPresti if he wants to hack in pgp5.x support. (:-) Well, I tend to doubt that all the other e-mailers have no problem with the new PGP interface, and only big bad Mailcrypt does... But if you can ask Pat - by all means, please do so. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03610 for ietf-open-pgp-bks; Tue, 25 Nov 1997 10:24:32 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA03604 for ; Tue, 25 Nov 1997 10:24:27 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EK700M89SISB5@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Tue, 25 Nov 1997 13:25:40 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EK7003TZSIP69@lmco.com> for ietf-open-pgp@imc.org; Tue, 25 Nov 1997 13:25:38 -0500 (EST) Date: Tue, 25 Nov 1997 13:25:36 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: The armour issue To: ietf-open-pgp@imc.org Message-id: <971125132536.20e14553@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Compatibility with Classic PGP has become optional. All OP implementations >will be compatible with each other. I suspect most will also be compatible >with the Classic PGP, but that's up to implementers and users. Agree in principle. Armour/Mime/etc is really a mail issue with one exception: I would really be bothered if installation of PGPv14 made it impossible to decrypt the thousands of instances of malicious software I keep in the original PGP message format (easy to tell who it came from). Would also like to read the ones received in the future as well. Would imagine that many of the people who have supported Viacrypt/PGP Inc through the years have similar concerns. OTOH the thought of FIPS compliant PGP flowing on the DMS with DH/TripleDES also has a certain appeal to the absurd 8*). So would like to see something such as it MUST be an OPTION to any product claiming PGP compatability (is there such a thing as a mandatory option ?). Personally, would not mind paying extra for the capability but would want to be sure that it was available (I know - keep the old version around. Ever read an upgrade license ?). Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA23515 for ietf-open-pgp-bks; Tue, 25 Nov 1997 02:25:19 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA23509 for ; Tue, 25 Nov 1997 02:25:12 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 25 Nov 1997 10:25:58 +0000 Message-ID: <347AA717.9F9CBC89@cs.ucl.ac.uk> Date: Tue, 25 Nov 1997 10:23:19 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Black Unicorn CC: ietf-open-pgp@imc.org Subject: Re: PGP, evolving. References: <3.0.3.32.19971125041210.006a407c@schloss.li> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Has anyone bothered with a netscape plug-in? See http://www.cs.ucl.ac.uk/staff/I.Brown/enigma/ - a plugin that will work with any POP/SMTP mailer such as Netscape. Doesn't do PGP 5 formats yet, though - am working on that now. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA23057 for ietf-open-pgp-bks; Tue, 25 Nov 1997 02:11:48 -0800 (PST) Received: from archduke.torgo.net (archduke.torgo.net [207.229.134.19]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA23044 for ; Tue, 25 Nov 1997 02:11:42 -0800 (PST) Received: from zug.li by archduke.torgo.net (AppleShare IP Mail Server 5.0.1) id 52377 via TCP with SMTP; Tue, 25 Nov 1997 04:13:24 -0600 Message-Id: <3.0.3.32.19971125041210.006a407c@schloss.li> X-Sender: unicorn@schloss.li X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 25 Nov 1997 04:12:10 -0600 To: ietf-open-pgp@imc.org From: Black Unicorn Subject: PGP, evolving. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:15 AM 11/25/97 -0800, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >Adam Back writes: > > > > > Yes and no. Of course transparency will help. HOWEVER, many of PGP > > > users have either no time, or no skills (or "no" both) to modify > > > the software that interfaces between their favorite whatever > > > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part > > > is taken care of - don't expect people to switch. > > > > I think mailcrypt users are small in number. We should ask Pat > > LoPresti if he wants to hack in pgp5.x support. Has anyone bothered with a netscape plug-in? Eudora is nice, get that and netscape and OE and you'd be close to quitting (since I gather there is already a pine integration). Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA19914 for ietf-open-pgp-bks; Tue, 25 Nov 1997 01:11:36 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA19905 for ; Tue, 25 Nov 1997 01:11:29 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.8/8.6.9) id BAA11196; Tue, 25 Nov 1997 01:15:03 -0800 Date: Tue, 25 Nov 1997 01:15:03 -0800 Message-Id: <199711250915.BAA11196@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Adam Back Cc: uri@watson.ibm.com, ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving In-Reply-To: <199711250233.CAA07069@server.test.net> References: <9711241626.AA70184@watpub1.watson.ibm.com> <199711250233.CAA07069@server.test.net> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Adam Back writes: > > > Yes and no. Of course transparency will help. HOWEVER, many of PGP > > users have either no time, or no skills (or "no" both) to modify > > the software that interfaces between their favorite whatever > > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part > > is taken care of - don't expect people to switch. > > I think mailcrypt users are small in number. We should ask Pat > LoPresti if he wants to hack in pgp5.x support. > This is a project on my list. I use XEmacs and mailcrypt exclusively, and want DSS/EG support fairly badly. If someone else gets to it first, more power to them. I plan to get to it sometime over the next month. Regards, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHqXAy/fy+vkqMxNAQFNNQP8D5LqlB5Nq5mE6KlPSxXUruR8n5I2dLiJ fYDvcXzPFvG81pKEc3VDJzQnQ9CpKFibPyZSrcdcEL2IQTbdg1jX5CyqfQNjxt3P e8Bv6nUzkMEgjngVCxozhSJOQobe+A3D3p4mGNWXRR+5tHFAs1Hf4Thn7kT0AL9y NcaUmEcQvTE= =WXkk -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA18241 for ietf-open-pgp-bks; Tue, 25 Nov 1997 00:21:56 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA18231 for ; Tue, 25 Nov 1997 00:21:51 -0800 (PST) Received: from server.test.net ([194.168.56.183]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA7693; Tue, 25 Nov 1997 08:23:00 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id CAA07069; Tue, 25 Nov 1997 02:33:45 GMT Date: Tue, 25 Nov 1997 02:33:45 GMT Message-Id: <199711250233.CAA07069@server.test.net> From: Adam Back To: uri@watson.ibm.com CC: david@sternlight.com, ietf-open-pgp@imc.org In-reply-to: <9711241626.AA70184@watpub1.watson.ibm.com> (message from Uri Blumenthal on Mon, 24 Nov 1997 11:26:17 -0500 (EST)) Subject: Re: PGP evolving, improving Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Uri Blumenthal writes: > > > b. There have been no practical cases of signature spoofing with MD5--it > > > hasn't been broken. > > > > I agree, in the general case it has not. I'll discuss a better > > user migration path below. > > Excuse me, gentlemen, were there any practical cases of signature > spoofing with MD4? > > Also, since this is an IETF forum, let me remind you, that the > official IETF security guideline is: "For all the new standards > MD5 shall not be used - but SHA-1". MD5 is in the draft as a MAY. You want to change that to a MUST NOT? I don't think the situation with MD5 is serious enough currently to warrant the loss of backwards compatibility as an implementation option. > However, as an algorithm starts showing cracks, a cryptographer with > brains replaces it before the "practical" cases start piling up. Of course, that much is a given. Where we came in to this discussion was that by having backwards compatibility more people migrate to new algorithms more quickly. > Well, the only compatibility concerns that *I* have as a user are > related to the broken *interface*. I.e. I APPLAUD the move to DSS > and EG (would like to see ECC too, BTW) - but I absolutely hate > the fact that I can no longer use Mailcrypt-3.4 from XEmacs. Well I use mailcrypt also, so I can share on that one. However I keep getting emails from people with pgp5.x which are addressed to my RSA key, and yet which pgp2.x simply can't read. I think this must either be the bug Hal described, or people are signing the message with a DSS key which I thought pgp5.x was supposed to warn against when the recipient is using an RSA key. > > Now the discussion of a better migration path. It seems to me that a > > nice thing to do would be to generate two keys at key gen time: an RSA > > key and an DSS/EG pair. > > What if I *don't* want to generate RSA keys. Why cramming those down my > throat? Make it possible to geterate DSS *or* DSS+RSA, if you REALLY > insist... Default operation. Same as you get a default operation with pgp5.x of using cooked primes. > > Largely transparent interoperability on all versions > > would I suspect paradoxically have meant many more people made the > > switch. > > Yes and no. Of course transparency will help. HOWEVER, many of PGP > users have either no time, or no skills (or "no" both) to modify > the software that interfaces between their favorite whatever > and PGP. For me it is Mailcrypt/XEmacs. Until *that* part > is taken care of - don't expect people to switch. I think mailcrypt users are small in number. We should ask Pat LoPresti if he wants to hack in pgp5.x support. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA16390 for ietf-open-pgp-bks; Mon, 24 Nov 1997 23:31:19 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA16386 for ; Mon, 24 Nov 1997 23:31:14 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id KAA03408; Tue, 25 Nov 1997 10:00:18 +0100 (MET) Message-ID: <347A7F9F.3D12DFA1@systemics.com> Date: Tue, 25 Nov 1997 07:34:55 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org Subject: Re: Complexity not a dominant strategy for independant deployment References: <199711250613.WAA27417@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney wrote: > It sounds like the lack of documentation was a significant factor in > making the implementation difficult. Hopefully with the new draft this > will change. It will certainly help. However I would stress that a simple, clear protocol and formats architecture will make nice documentation easy. The alternate, good documentation on top of a complicated protocol, remains second best. > Maybe a more constructive approach is to ask whether the description > in the new draft is clear and useful. The draft is lengthy, yes, > but not very much of it is occupied discussing packet length headers, > and perhaps that portion could be made more concise. We could include > some code samples if this is an area where people are afraid of the > implementation difficulty. Adding code fragments is a good idea. Code does not lie where text can not help but spread mistruths. Psuedo code or C or even Java would be very useful. We may even be able to make this easier by adopting the convention that comments on the draft, within this mailgroup, include code fragments to explain their points, as Adam did earlier. Then, the editors can simply cut and past. Oh, and when you say "where people are afraid," you are of course referring to project leaders who are afraid of programmers who are not afraid? This is the fear that I most often experience :-) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15196 for ietf-open-pgp-bks; Mon, 24 Nov 1997 22:45:08 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA15192 for ; Mon, 24 Nov 1997 22:45:04 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id WAA09928 for ; Mon, 24 Nov 1997 22:47:47 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id WAA27462 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 22:31:48 -0800 Date: Mon, 24 Nov 1997 22:31:48 -0800 From: Hal Finney Message-Id: <199711250631.WAA27462@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: MUST accept 32 bit lols everywhere? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keep in mind that part of the reason for going to the new length headers is that we were running out of tag values. The old PGP "CTB" had only 16 possible tags. Getting rid of the "length of length" field added two more bits allowing 64 possible packet types. So whatever new proposals are considered for OP V2, we should not retain the original "lol" field. Hal -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHpwzcDh8jnv1nHwEQJFoACfWr0X/NMhY4z9KsXtyvoO2Ni+GHEAoODj VrL6dw2ajxo/0QGSuXmDQxl/ =1Ps6 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15120 for ietf-open-pgp-bks; Mon, 24 Nov 1997 22:42:46 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA15114 for ; Mon, 24 Nov 1997 22:42:41 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id WAA09749 for ; Mon, 24 Nov 1997 22:45:22 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id WAA27455 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 22:29:23 -0800 Date: Mon, 24 Nov 1997 22:29:23 -0800 From: Hal Finney Message-Id: <199711250629.WAA27455@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Complexity not a dominant strategy for independant deployment Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Grigg, , writes: > It never occurred to me until right now - probably because I have > cauterised that part of my brain - but it would be a big win for future > generations if we can add an alternate CFB method that is straight down > the line, and start deprecating the existing method. We will need to make some alterations when it is time to support ciphers with block sizes larger than 64 bits. There is language in the draft which would allow us to fix it at that time. The current wording is: : The data is encrypted in CFB mode, with a CFB shift size equal to the : cipher's block size [Ref]. The Initial Vector (IV) is specified as all : zeros. Instead of using an IV, OP prepends a 10 octet string to the : data before it is encrypted. The first eight octets are random, and : the 9th and 10th octets are copies of the 7th and 8th octets, : respectivelly. After encrypting the first 10 octets, the CFB state is : resynchronized if the cipher block size is 8 octets or less. The last : 8 octets of ciphertext are passed through the cipher and the block : boundary is reset. Notice "resynchronized if the cipher block size is 8 octets or less". This means the resync will go away for larger block ciphers. However now I realize that the 8+2 header will not be right for such ciphers, either. Probably we should replace the "8" with the block size of the cipher. Any other suggestions on how to revise this? (Note that the purpose of the two redundant bytes is to tell if you have the right key for decryption.) > I am *not* suggesting that we should make the existing CFB_PGP anything > less than a MUST to read. The current generation can suffer. We did. > > But it would be nice to have straight CFB that could be coded up from > Schneier without resorting to black magic. That way a non-conforming > implementation would be quicker to get going, and if it is successful, > we could start to deprecate the CFB_PGP in the V2 that people are > looking to. Slowly slowly, none of this unseemly rush that leaves > customers suddenly with a split email community. I considered another way of documenting the resynchronization of the CFB mode. It can be described pretty cleanly as follows: Encrypt the first 8 bytes in CFB-64 mode, the next two bytes in CFB-16 mode, and the remainder of the message in CFB-64. In other words, you encrypt the first 64 bits (8 bytes) and shift the shift register by 64 bits, bringing in new data; then you encrypt the next 16 bits (2 bytes) and shift the shift register by 16 bits, bringing in new data; and then you go back to encrypting 64 bits at a time and shifting in 64 bits of new data each time. Someone familiar with the meaning of CFB-n might find this description to be clearer. Any preferences? Hal -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHpwNcDh8jnv1nHwEQL2uQCg0utkjVCOh1RClQcKDs9W15Vaxu0AnRLe sVg7l3g6rMqgp/ioCMVx9EoU =DxbI -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15004 for ietf-open-pgp-bks; Mon, 24 Nov 1997 22:27:53 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA14997 for ; Mon, 24 Nov 1997 22:27:46 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id WAA08549 for ; Mon, 24 Nov 1997 22:30:28 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id WAA27399 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 22:08:00 -0800 Date: Mon, 24 Nov 1997 22:08:00 -0800 From: Hal Finney Message-Id: <199711250608.WAA27399@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: The web of trust has no clothes. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk PGP 5.X implements an extension to the trust model to address the issue raised by David Sternlight. > Another flaw in the web of trust and PGP is now revealed and comes home > to roost. Now that PGP Inc. has deep-sixed RSA in new free versions, > not only does everyone with an old RSA key have to generate a new key > but also a complete new set of signatures and web of trust must be built > if they wish to use the "better" algorithms. And the new keys must be > distributed to correspondents, either directly or by "pull" from > servers. This took years the first time--perhaps the second time it will > be a bit faster. The way it works is as follows. If you have two keys with identical userids, and the first key signs the second userid, then validity from the signatures on the first user ID gets propagated to the second userid. The effect is that if you generate a new DSA key with the same name as your old RSA key, and sign it with your old key, then your new key inherits the validity from the old key. (This propagation happens irrespective of whether the old key is marked as a trusted introducer.) In effect, the signatures on your old key automatically get applied to your new key. This is an easy way to inherit the signatures from the old web of trust. The new keys do not have to start from scratch, as implied above. There may be some concern that this would introduce certain kinds of spoofing attacks. Let us assume that the old signatures are valid, that the old key is in fact properly bound to the userid. (If the old signatures are invalid, no one should trust them anyway, so they have no impact on the web of trust.) Now, when that old key issues a signature on the same userid on another key, it is in effect asserting that the same keyholder controls this other key. If the other key actually does belong to the same keyholder, then there is no danger in transferring validity from the signatures on the old key over to the new one. The new key is in fact valid, and so measures which show it as valid are proper. The questionable aspect arises if the new key does not actually belong to the keyholder. For example, someone might create a key and put Phil Zimmermann's name and email address on it. If Phil signed that name, he would be falsely claiming that this other key belonged to him. With the 5.X extension to the trust model, other signatures on Phil's true key would be treated as though they apply to this new key. Someone trying to encrypt a message to Phil might find their software encrypting it to this new key instead of Phil's real key. This might appear to be a security weakness. Note, though, that this can only occur with Phil's active cooperation. He has knowingly signed a userid which matches his own but is bound to someone else's key. Only in this circumstance can it occur that other people will encrypt to this key when they mean to encrypt to Phil. However, since this was done with Phil's active cooperation, he is intentionally sharing the contents of messages with the other keyholder. But if this is his intention, he can do that even with the old trust model. He has the power to share the contents of his encrypted messages with anyone he wants. It was our conclusion that this feature does not add any new weaknesses to the PGP trust model, and it greatly improves its robustness and usability as new keys are introduced. In fact, the basic idea can probably be improved to make it easier to retire and replace old keys in a more general way, while retaining the validity of old signatures. This would be a good topic for OP V2. Hal Finney hal@pgp.com hal@rain.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15001 for ietf-open-pgp-bks; Mon, 24 Nov 1997 22:27:49 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA14994 for ; Mon, 24 Nov 1997 22:27:43 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id WAA08543 for ; Mon, 24 Nov 1997 22:30:26 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id WAA27417 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 22:13:52 -0800 Date: Mon, 24 Nov 1997 22:13:52 -0800 From: Hal Finney Message-Id: <199711250613.WAA27417@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Complexity not a dominant strategy for independant deployment Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Grigg, , writes: > Well, I have to disagree on that. The difficulty is high. I recall the > swearing going on when each one of the infamous bit twiddles was finally > debugged out of the Cryptix code - not pleasant to be on the same > mailgroup as that discussing yet another PGP furfy. > [...] > Up until now, it has been the fact that the only documentation was the > code. PGP code is not the worst I've come across, but it's not the > best. Having the code-as-dox is a reasonable strategy when it is well > written, but elsewise, you're adding a cost. Having a complicated > standard will result in a three-way reliance of programmers on the > standard, the code and the conformance tests. It sounds like the lack of documentation was a significant factor in making the implementation difficult. Hopefully with the new draft this will change. Maybe a more constructive approach is to ask whether the description in the new draft is clear and useful. The draft is lengthy, yes, but not very much of it is occupied discussing packet length headers, and perhaps that portion could be made more concise. We could include some code samples if this is an area where people are afraid of the implementation difficulty. Hal -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHpsl8Dh8jnv1nHwEQKDHACdFj5mO0jAcG6btDwTMJFeOfc3lc8AnRlg GPPyD3efAG861J8HpuaGKvEc =thRY -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA13860 for ietf-open-pgp-bks; Mon, 24 Nov 1997 19:55:06 -0800 (PST) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA13856 for ; Mon, 24 Nov 1997 19:55:01 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id VAA04631; Mon, 24 Nov 1997 21:55:05 -0600 (CST) Received: from lax-ca69-43.ix.netcom.com(207.223.161.171) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma004596; Mon Nov 24 21:54:45 1997 Message-ID: <347A4C04.F7605E20@sternlight.com> Date: Mon, 24 Nov 1997 19:54:49 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: Ian Grigg CC: ietf-open-pgp@imc.org Subject: Re: The web of trust has no clothes. References: <3475DB15.8B949920@sternlight.com> <6552rm$6a7@clarknet.clark.net> <3477fe3f.60527863@news.concentric.net> <657vke$7lv@camel12.mindspring.com> <3477901B.62531F94@sternlight.com> <34793D2E.8EF0B95D@sternlight.com> <347A293B.394BFE6C@sternlight.com> <347A42E8.5B676EE@systemics.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msCDDA59CF3501ED496475ADA3" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------msCDDA59CF3501ED496475ADA3 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Ian Grigg wrote: > David Sternlight wrote: > > > > Another flaw in the web of trust and PGP is now revealed and comes home > > to roost. Now that PGP Inc. has deep-sixed RSA in new free versions, > > not only does everyone with an old RSA key have to generate a new key > > but also a complete new set of signatures and web of trust must be built > > if they wish to use the "better" algorithms. And the new keys must be > > distributed to correspondents, either directly or by "pull" from > > servers. This took years the first time--perhaps the second time it will > > be a bit faster. > > Slow down David. You are right that there are now two WoTs and they > don't look like getting back together, assuming good takeup on the > freeware pgp5.5. > > However, the new Open PGP format does have the ability to separate out > your signing key from your usage keys. I think there is an ability to > sign keys of different algorithms, as in SSL V3. Is that the case? Dunno. My purpose in posting this to the Open PGP list was to point out that Open PGP needs a mechanism, if it hasn't already been created, that will avoid invalidating or slicing off an entire web of trust structure if a crucial algorithm changes. There's nothing like a worked example to clear minds. David > > > > In contrast, with S/MIME-Verisign-Netscape/Microsoft if they were to > > change the algorithm you just generate a new key and get one certificate > > and you're done. And as you e-mail your correspondents using your new > > certificate, they get a copy of your new key automatically. > > > > And some say PGP's trust model is "better". Can you say "needs work", > > boys and girls? > > The work *is* being done. I agree that the PGP Inc schedule leaves the > customer cold or dead, and this WG perplexed, but the direction is > reasonable. > > -- > iang systemics.com > > FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com --------------msCDDA59CF3501ED496475ADA3 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKjQYJKoZIhvcNAQcCoIIKfjCCCnoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CIUwggPPMIIDOKADAgECAhAnuK6izE0BOIf7uTQQ8usCMA0GCSqGSIb3DQEBAgUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA4MjEwMDAw MDBaFw05ODA4MjEyMzU5NTlaMIIBEjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDIgLSBOZXRzY2FwZTEZMBcGA1UEAxMQRGF2aWQgU3Rlcm5saWdodDEjMCEGCSqGSIb3 DQEJARYUZGF2aWRAc3Rlcm5saWdodC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN09h1fHJlSiS54oM5YjKy9J6wMmjUFL58Xkwc6JiCBftinxpbm2ziTPSAn4TMhSVbZnuC1m oDZln2HSvkRS61+BwYL3yw9kus2/Tyoi4gparm1O+CRlRkudAP8w7cHax6AZXTr7KDQA/mOq nXSPERdO3XZIgvVRXvL7VIVt++F7AgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0gBIGn MIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24A AAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBAgUAA4GBAE8QvB3wHstP4Ggj +WuQRdIKOsO4U3F5mUjfle6hatqCA1fvD3Kzmrr4KSvBes2CH0BKV/Mmb/rRkkwXaspTkSIC 0ENT789yEuv/aoOVogJVaKYHz7bgNkSuwa6O8SKHkrGHdQRxl3J+GN1SEgOzkW7A15d702QM 0tR6rtxMvtxYMIICeTCCAeKgAwIBAgIQUNNSlJEvedMV4ysxrIVI8DANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3 MDAwMDAwWhcNOTgwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlk dWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+b yB2eT7R1731MMPOyqjS/mdtGxtSYxx1FDuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqt WhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCI cp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCG SAGG+EIBAQQEAwICBDANBgkqhkiG9w0BAQIFAAOBgQAN6OSPQTmZ8ouFAbfodckgYj0dsq43 RhipxsLh/k6LwgZbQUbv8sxw0AEqFp5AUak+wBPYFljrwLCW/qnQZbM1RsFBCP6IlPSbtgyv YbUZrIGeVCdsNpBTxypskPapJdjkip4YXyd8jdn10TX+OZmd7OjE9vRuXjCXTgiI0JmvnzCC AjEwggGaAgUCowAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFg a355LPoGDzqu9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fM CGw/PrNK/P9LbCPVUIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQAD gYEAe6+kHC/Amw47XPyo5tGWD0hySYXlrxojAOPpu4A0bLI/hKg8cnCzTN5z+nyE0pKlADcJ wgM0IwO37XaW3D5Phf1YF/QEvuxRHtx629uu6GF42mU4R6wdA3Bt6eO7oEqfQOq823O/Z01d xnwgXOfoogorwgl010z+2+lrAmNdOacxggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVy bmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQJ7iuosxNATiH+7k0EPLrAjAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTEy NTAzNTQ1MlowIwYJKoZIhvcNAQkEMRYEFJFxcYPyhpD6dIi5wjYuWNTNzOrMMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAud4Rwts/O2/OPX9z9/VD eDITDPPzLE5M2svTVX+4J9c0K0oz8ErEix4rid6aN1ccx7DfX8TkcnCmHF2Zu9DP/7kUf6jU wK0tTLO0HiveZ5PPatdh2QAkgI4wv1SYz3NpnVUYpOLYiJ9EfevusXCtd8LZsS9fO9PTLHIW hamNvkk= --------------msCDDA59CF3501ED496475ADA3-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA13213 for ietf-open-pgp-bks; Mon, 24 Nov 1997 19:13:19 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA13209 for ; Mon, 24 Nov 1997 19:13:14 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id FAA02714; Tue, 25 Nov 1997 05:41:14 +0100 (MET) Message-ID: <347A42E8.5B676EE@systemics.com> Date: Tue, 25 Nov 1997 03:15:52 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: david@sternlight.com CC: ietf-open-pgp@imc.org Subject: Re: The web of trust has no clothes. References: <3475DB15.8B949920@sternlight.com> <6552rm$6a7@clarknet.clark.net> <3477fe3f.60527863@news.concentric.net> <657vke$7lv@camel12.mindspring.com> <3477901B.62531F94@sternlight.com> <34793D2E.8EF0B95D@sternlight.com> <347A293B.394BFE6C@sternlight.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Sternlight wrote: > > Another flaw in the web of trust and PGP is now revealed and comes home > to roost. Now that PGP Inc. has deep-sixed RSA in new free versions, > not only does everyone with an old RSA key have to generate a new key > but also a complete new set of signatures and web of trust must be built > if they wish to use the "better" algorithms. And the new keys must be > distributed to correspondents, either directly or by "pull" from > servers. This took years the first time--perhaps the second time it will > be a bit faster. Slow down David. You are right that there are now two WoTs and they don't look like getting back together, assuming good takeup on the freeware pgp5.5. However, the new Open PGP format does have the ability to separate out your signing key from your usage keys. I think there is an ability to sign keys of different algorithms, as in SSL V3. Is that the case? > In contrast, with S/MIME-Verisign-Netscape/Microsoft if they were to > change the algorithm you just generate a new key and get one certificate > and you're done. And as you e-mail your correspondents using your new > certificate, they get a copy of your new key automatically. > > And some say PGP's trust model is "better". Can you say "needs work", > boys and girls? The work *is* being done. I agree that the PGP Inc schedule leaves the customer cold or dead, and this WG perplexed, but the direction is reasonable. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA13074 for ietf-open-pgp-bks; Mon, 24 Nov 1997 18:59:24 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA13070 for ; Mon, 24 Nov 1997 18:59:19 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id FAA02675; Tue, 25 Nov 1997 05:28:23 +0100 (MET) Message-ID: <347A3FE6.729F0C69@systemics.com> Date: Tue, 25 Nov 1997 03:03:02 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Adam Back CC: hal@rain.org, ietf-open-pgp@imc.org Subject: Re: Complexity not a dominant strategy for independant deployment References: <199711250152.BAA06198@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > I found the non-standard CFB mode consumed more time than the LOL > twiddling (spent a bit of time with two gdb's up to get that one > working). Not tackled the rest of the bit twiddling to date, nor the > WoT and revocation semantics. (I only coded the PRZ style CFB and LOL > bit twiddling as an extra confidence test that my app was doing > something sensible with it's vanilla IDEA and 32 bit ints). You raise an interesting point. No, more than interesting, this brings up dark memories. Ian will confirm that there was nothing that caused more strife in the entire Cryptix development effort over the last 2.5 years than the CFB_PGP (as it is called at the minute within Cryptix-Java). Five people have had a go at coding it up in an architecturally good way such that users can see what's happening. I think the sixth is just about to have another go . It never occurred to me until right now - probably because I have cauterised that part of my brain - but it would be a big win for future generations if we can add an alternate CFB method that is straight down the line, and start deprecating the existing method. I am *not* suggesting that we should make the existing CFB_PGP anything less than a MUST to read. The current generation can suffer. We did. But it would be nice to have straight CFB that could be coded up from Schneier without resorting to black magic. That way a non-conforming implementation would be quicker to get going, and if it is successful, we could start to deprecate the CFB_PGP in the V2 that people are looking to. Slowly slowly, none of this unseemly rush that leaves customers suddenly with a split email community. I defer to the bit-twiddlers amongst us as to the appropriate way to do this. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12969 for ietf-open-pgp-bks; Mon, 24 Nov 1997 18:47:01 -0800 (PST) Received: from boeing.rutgers.edu (boeing.rutgers.edu [165.230.8.73]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12951; Mon, 24 Nov 1997 18:44:42 -0800 (PST) Received: from localhost (mione@localhost) by boeing.rutgers.edu (8.8.5/8.6.12) with SMTP id VAA04068; Mon, 24 Nov 1997 21:45:50 -0500 (EST) Date: Mon, 24 Nov 1997 21:45:49 -0500 (EST) From: Tony Mione To: ietf-open-pgp@imc.org, ietf-smime@imc.org, pgp-users@joshua.rivertown.net, mac-crypto@vmeng.com cc: Tony Mione Subject: PGP Implementor's survey Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk PGP Implementor's survey The IETF OpenPGP Working Group is currently formalizing message certificate formats used by PGP. As part of this effort, we are trying to find out what implementations exist of various pgp-based products and tools. This survey is designed to gather that information. We ask that you take time to fill out and return this survey if you fall into one of the following catagories: - You have written a pgp-based tool or an implementation of pgp - You are in the process of writing one of the above - You are planning to write one of the above If you are only in the planning stages (or very early in the development stage), answer the questions as though in the future tense "What platforms do you plan to support?", "Will it be compatible with 2.6.x?", etc. Please answer the following questions as completely as possible. When completed, email back to mione@nbcs-ns.rutgers.edu or print the form, fill it out and FAX it to Antonino Mione at +1 (732)-445-2968. Thanks for your help. Antonino N. Mione mione@nbcs-ns.rutgers.edu ----- BEGIN PGP SURVEY FORM ----- PGP Implementation Survey Identification of the Package and Legal Issues ---------------------------------------------- 1) Name of Package: ______________________________________________________ 2) Contact Name:__________________________________________________________ Phone #:_______________________________________________________ Email Address:_________________________________________________ 3) Is the software a commercial product, shareware, freeware, other? ___________________________________________________________________ 4) How can one obtain it (URL, anonymous ftp, prepaid ftp retrieval, etc)? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ General Characteristics of the Package -------------------------------------- 5) On which platform(s) does it run? __ Windows 3.1.x __ Windows 95 __ Windows NT __ MS-DOS __ Mac/OS (7.5, 8.0, etc) __ Unix (list flavors) : __________________________________________ ___________________________________________________ __ Amiga __ MVS __ OpenVMS __ Handheld/embeded devices : _____________________________________ __ Other(s) : _____________________________________________________ 6) Is source distributed or available? ___________________________________ 7) What type of product is this (check all that apply)? __ Full PGP application? __ Email plug-in (i.e. Eudora)? __ Browser plug-in (i.e. Netscape)? __ Programming API __ C, C++ __ Perl __ Other 8) Does it support PGP 2.6.x compatibility? ______________________________ Exceptions? : _____________________________________________________ 9) Does it support PGP 5.x compatibility? ________________________________ Exceptions? : _____________________________________________________ 10) With what other PGP-Based implementations or products (that you know of) does it interoperate? ___________________________________________________________________ ___________________________________________________________________ ___________________________________________________________________ Technical Characteristics of the Package ---------------------------------------- 11) Which Symmetric Encryption algorithms does it support? __ DES __ 3-DES __ CAST __ IDEA __ Blowfish __ SAFER __ Others : _______________________________________________________ 12) Which Public Key Encryption algorithms does it support? __ RSA __ ElGammal __ D/H __ Elliptic Curve __ Others : _______________________________________________________ 13) Which Message Digest algorithms does it support? __ MD4 __ MD5 __ SHA-1 __ Tiger __ RIPEMD-160 __ Others : ______________________________________________________ 14) Which Signature algorithms does it support? __ RSA __ DSS __ Others : ______________________________________________________ 15) Which email armoring algorithms does it support? __ RADIX-64 ASCII Armor __ Mime __ UUENCODE/UUDECODE __ Others : _______________________________________________________ 16) Besides standard PGP message formats, does it support any additional certificate formats? If so, which ones? __ X.509 __ PKIX __ Others : ______________________________________________________ Thanks again! ----- END PGP SURVEY FORM ----- Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650 mione@nbcs-ns.rutgers.edu W3: http://www-ns.rutgers.edu/~mione/ PGP Fingerprint : E2 25 2C CD 28 73 3C 5B 0B 91 8A 4E 22 BA FA 9F Editorial Advisor for Digital Systems Report ***** Important: John 17:3 ***** Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12893 for ietf-open-pgp-bks; Mon, 24 Nov 1997 18:35:14 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12889 for ; Mon, 24 Nov 1997 18:35:08 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA21910; Tue, 25 Nov 1997 15:35:59 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88042535406712>; Tue, 25 Nov 1997 15:35:54 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: aba@dcs.ex.ac.uk Subject: Re: MUST accept 32 bit lols everywhere? Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Tue, 25 Nov 1997 15:35:54 (NZDT) Message-ID: <88042535406712@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >So pgp2.x has lol field values 0, 1, 2 to mean 1 byte, 2 bytes and 4 >bytes. All that needs to be done is to depracate lol field values 0 >and 1. Ian Grigg said he tried this with his systemics pgp2.x >implementation cryptix2.x but found cases where the pgp2.x code base >could not handle 4 byte lengths! I think there are portions of 2.x code which assume the CTB will be in a certain form, eg that the lol will indicate an 8-bit length so it's possible to process the CTB in a single byte comparison rather than having to pick apart the lol. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12608 for ietf-open-pgp-bks; Mon, 24 Nov 1997 18:12:10 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12604 for ; Mon, 24 Nov 1997 18:12:06 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.5) with ESMTP id SAA24869 for ; Mon, 24 Nov 1997 18:13:17 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Nov 1997 18:13:32 -0800 To: ietf-open-pgp@imc.org From: Will Price Subject: Sternlight Drivel Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In the past few days, an individual named David Sternlight has begun posting abusive progaganda-style messages to this and other lists. He usually sticks to the newsgroups, but since he he has appeared here, I think it is important for any who have not previously heard of him to know just what kind of person this guy is with a multiyear history of posting nonsensical drivel about PGP and many other products to suit his own suspect motives. Here are 2 whole websites dedicated to exposing this guy for what he is: http://www.synernet.com/estone/ (Click the "Sternlight" button) http://www.austinlinks.com/Crypto/sternlight.html I assume there is no procedure on an IETF list to ban a particular poster. If there isn't, his presence will undoubtedly be a great hindrance to intelligent and calm discussion. My philosophy along with many others with his posts has been to simply not reply especially on this list where his posts are completely outside the realm of this list. -Will Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA12352 for ietf-open-pgp-bks; Mon, 24 Nov 1997 17:52:04 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA12348 for ; Mon, 24 Nov 1997 17:52:00 -0800 (PST) Received: from server.test.net ([194.168.66.81]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA27766; Tue, 25 Nov 1997 01:53:09 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id BAA06198; Tue, 25 Nov 1997 01:52:17 GMT Date: Tue, 25 Nov 1997 01:52:17 GMT Message-Id: <199711250152.BAA06198@server.test.net> From: Adam Back To: iang@systemics.com CC: hal@rain.org, ietf-open-pgp@imc.org In-reply-to: <347A1E2D.700445B5@systemics.com> (message from Ian Grigg on Tue, 25 Nov 1997 00:39:09 +0000) Subject: Re: Complexity not a dominant strategy for independant deployment Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Grigg writes: > Hal Finney wrote in "Re: hand huffman encoding at PGP world HQ:" > > > > It is true that Phil Zimmermann has been the chief advocate of making > > PGP data structures as concise as possible. (I don't know whether Jon > > actually goes around the office singing songs about it or not.) Phil is > > out of the country now so I will try to relay some of his thinking. > > > > First, the difficulty is really not as large as people are making out. > > Well, I have to disagree on that. The difficulty is high. I recall the > swearing going on when each one of the infamous bit twiddles was finally > debugged out of the Cryptix code - not pleasant to be on the same > mailgroup as that discussing yet another PGP furfy. I found the non-standard CFB mode consumed more time than the LOL twiddling (spent a bit of time with two gdb's up to get that one working). Not tackled the rest of the bit twiddling to date, nor the WoT and revocation semantics. (I only coded the PRZ style CFB and LOL bit twiddling as an extra confidence test that my app was doing something sensible with it's vanilla IDEA and 32 bit ints). Really I am an oddity in this discussion. I am a hand huffman encoding freak if ever there was one. But at the same time there is another side: mostly I code optimised for clarity and simplicity. Perhaps it's just my freakish optimisation for amusement tendencies coming out again, but I actually went over and reimplemented 3 or 4 times optimising for simplicity my SHA1 implementation. Same thing for IDEA, and MD5. (Note not for speed -- for clarity, speed was secondary concern). Now it seemed to me that aside from the enjoyment found in the optimisation to simplify, simplicity is a valuable feature of crypto coding -- firstly it reduces scope for errors, and secondly it enables others to more easily read the code and get confidence that they understand it. The same thing could be said for the standard, as Ian was arguing. The simpler the better. Now this is amusing from my point of view, because as soon as Hal talks about the challenge of using the serendipity of 160 bit DSS sigs, I get the urge to join in and figure out ways to save a few more bytes :-) Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Mon, 24 Nov 1997 17:26:10 -0800 (PST) Received: (from smap@localhost) by dfw-ix4.ix.netcom.com (8.8.4/8.8.4) id TAA29751 for ; Mon, 24 Nov 1997 19:26:48 -0600 (CST) Received: from lax-ca69-20.ix.netcom.com(207.223.161.148) by dfw-ix4.ix.netcom.com via smap (V1.3) id rma029742; Mon Nov 24 19:26:36 1997 Message-ID: <347A293B.394BFE6C@sternlight.com> Date: Mon, 24 Nov 1997 17:26:26 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 Newsgroups: alt.security.pgp,comp.security.pgp.discuss To: ietf-open-pgp@imc.org Subject: The web of trust has no clothes. References: <3475DB15.8B949920@sternlight.com> <6552rm$6a7@clarknet.clark.net> <3477fe3f.60527863@news.concentric.net> <657vke$7lv@camel12.mindspring.com> <3477901B.62531F94@sternlight.com> <34793D2E.8EF0B95D@sternlight.com> Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Another flaw in the web of trust and PGP is now revealed and comes home to roost. Now that PGP Inc. has deep-sixed RSA in new free versions, not only does everyone with an old RSA key have to generate a new key but also a complete new set of signatures and web of trust must be built if they wish to use the "better" algorithms. And the new keys must be distributed to correspondents, either directly or by "pull" from servers. This took years the first time--perhaps the second time it will be a bit faster. In contrast, with S/MIME-Verisign-Netscape/Microsoft if they were to change the algorithm you just generate a new key and get one certificate and you're done. And as you e-mail your correspondents using your new certificate, they get a copy of your new key automatically. And some say PGP's trust model is "better". Can you say "needs work", boys and girls? David Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11693 for ietf-open-pgp-bks; Mon, 24 Nov 1997 16:35:36 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA11689 for ; Mon, 24 Nov 1997 16:35:32 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id DAA02238; Tue, 25 Nov 1997 03:04:29 +0100 (MET) Message-ID: <347A1E2D.700445B5@systemics.com> Date: Tue, 25 Nov 1997 00:39:09 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org Subject: Complexity not a dominant strategy for independant deployment References: <199711240154.RAA02289@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk It seems that every time that one of the technical people from PGP Inc post that we leap forward in our understanding of what's happening. Thanks Hal. Hal Finney wrote in "Re: hand huffman encoding at PGP world HQ:" > > It is true that Phil Zimmermann has been the chief advocate of making > PGP data structures as concise as possible. (I don't know whether Jon > actually goes around the office singing songs about it or not.) Phil is > out of the country now so I will try to relay some of his thinking. > > First, the difficulty is really not as large as people are making out. Well, I have to disagree on that. The difficulty is high. I recall the swearing going on when each one of the infamous bit twiddles was finally debugged out of the Cryptix code - not pleasant to be on the same mailgroup as that discussing yet another PGP furfy. There are only a handfull of people who really understand the formats, and they have invested years in the exercise. You're probably one of them, I'd hazard a guess that Derik and Will are too. Outside that small group, which might think of it as "not so hard," we have a whole bunch of people who are working on this, but have different motivations: * hack something up to please the boss / move onto the next project. Somebody's paying for this. * no particular loyalty to pgp formats, above say SMTP or IP or ... most will be expert in many things rather than just one protocol, so there's only a limited attention span. * no particular loyalty to pgp, against say SMIME or hacking up their own, which would be a *lot* simpler and would do the the same job. Another factor is that many of these people did not choose to be in the PGP bit-twiddling profession, their paymasters sent them into it. We've all got our cross to bear, but in this case there is the valid difference between those that are conscripted and those that volunteer. The people who are going to coding up the future generation of OP might not actually be the right programmers for the job. The more you head in to the standards and respectable systems field, the lesser becomes the benefit from programmer self-selection. And then there's the simple documentation exercise. The standard, huge as it is, will be a daunting factor in itself. The bigger it gets, the more difficult it is to go through all the conformance exercises that are now necessary - something that until now has been ignored in programmer calculations. Conformance testing is generally more complex than writing the code in the first place... Up until now, it has been the fact that the only documentation was the code. PGP code is not the worst I've come across, but it's not the best. Having the code-as-dox is a reasonable strategy when it is well written, but elsewise, you're adding a cost. Having a complicated standard will result in a three-way reliance of programmers on the standard, the code and the conformance tests. Complexity is not a good strategy for widespread adoption by independant developers. I think the notion of going for a MUST 32 bits, MUST/SHOULD? read others and MAY produce others has some merit, which still allows PGP Inc to pursue their minimalist signature aspirations. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11550 for ietf-open-pgp-bks; Mon, 24 Nov 1997 16:14:46 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA11541 for ; Mon, 24 Nov 1997 16:14:38 -0800 (PST) Received: from server.test.net ([194.168.62.179]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA24220 for ; Tue, 25 Nov 1997 00:15:41 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id AAA02465; Tue, 25 Nov 1997 00:13:21 GMT Date: Tue, 25 Nov 1997 00:13:21 GMT Message-Id: <199711250013.AAA02465@server.test.net> From: Adam Back To: ietf-open-pgp@imc.org Subject: expediency and avoidance of politics Sender: owner-ietf-open-pgp@imc.org Precedence: bulk It seems to me that the debate over CMR and it's more secure alternatives could easily be deferred to OpenPGPv2 with no compatibility issues. The way that CMR/ARR field is encoded in the draft is that it is a signature subpacket type. Signature subpacket types are extensible; that is an implementation already has a defined method to safely ignore subpackets it does not understand. This means that no one will experience compatibility problems if the experimental CMR subpacket is only implemented by PGP Inc. Avoiding, or deferring the political debate seems like it would be a good idea for a number of reasons: - it would allow us to focus on getting OpenPGPv1 out in a timely manner. - it would allow more time for PGP Inc to get feed-back on this controversial experimental feature from their customers as to how CMR performs functionally in practice (I am expecting there will be complaints about the lack of ergonomic recovery from forgotten passphrases -- all files have to be re-encrypted), how the security of the system holds up (how well companies are managing very sensitive CMR master keys), and to gauge customers acceptance of the feature politically. - it will give time for more secure competing proposals (such as local escrow) to be developed for recovery from forgotten passphrases. The consolidation phase would then be in OpenPGPv2 where the better solution would be chosen in OpenPGPv2 for standardisation. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11549 for ietf-open-pgp-bks; Mon, 24 Nov 1997 16:14:45 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA11539 for ; Mon, 24 Nov 1997 16:14:37 -0800 (PST) Received: from server.test.net ([194.168.62.179]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAC24220; Tue, 25 Nov 1997 00:15:45 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id XAA02435; Mon, 24 Nov 1997 23:50:34 GMT Date: Mon, 24 Nov 1997 23:50:34 GMT Message-Id: <199711242350.XAA02435@server.test.net> From: Adam Back To: wprice@pgp.com CC: ietf-open-pgp@imc.org In-reply-to: (message from Will Price on Sun, 23 Nov 1997 13:44:20 -0800) Subject: MUST accept 32 bit lols everywhere? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Will Price > >All this bit twiddling and little hacks to scrimp on an extra bit here > >and there is dangerous! Which hacker is it at PGP Inc that thrives on > >these bit twiddling hacks? Come one 'fess up! > > I couldn't agree more with you on this one issue. I've been saying this > for years. Unfortunately, I think the point is really moot. These are > format issues. The format is already there and you can't really change it > fundamentally without violating the WG charter. I think Peter Gutmann's suggestion shows how the move to 32 bit could be made without any major changes. So pgp2.x has lol field values 0, 1, 2 to mean 1 byte, 2 bytes and 4 bytes. All that needs to be done is to depracate lol field values 0 and 1. Ian Grigg said he tried this with his systemics pgp2.x implementation cryptix2.x but found cases where the pgp2.x code base could not handle 4 byte lengths! A good start in depracating 1 and 2 byte length fields would be to firstly define that everywhere in OpenPGP1.0 that the implementation MUST be able to accept a 32 bit int. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA11548 for ietf-open-pgp-bks; Mon, 24 Nov 1997 16:14:43 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA11534 for ; Mon, 24 Nov 1997 16:14:35 -0800 (PST) Received: from server.test.net ([194.168.62.179]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAB24220; Tue, 25 Nov 1997 00:15:43 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id XAA02452; Mon, 24 Nov 1997 23:59:18 GMT Date: Mon, 24 Nov 1997 23:59:18 GMT Message-Id: <199711242359.XAA02452@server.test.net> From: Adam Back To: jon@pgp.com CC: ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971124120455.00ae3140@mail.pgp.com> (message from Jon Callas on Mon, 24 Nov 1997 12:04:55 -0800) Subject: OpenPGP version2 plan? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: > The "hand huffman-coded" structures go all the way back to the origins of > PGP, they're hardly new. There are a number of bit packing methods which were not in pgp2.x.which are in the OpenPGP draft: - 8 bit floatpoint format for S2k iteration count - new 192 format Someone suggested that these were mostly decided prior to company formation -- which suggests that Colin Plumb, Derek Atkins are the guilty parties (and perhaps PRZ). > I agree with the sentiment that it would be nice to have a system > laid out with long constants, but I think that that would be a good > thing to do in V2 of the spec. I'd like to get this one done, and > then let the working group debate new formats. This (saving 32 bit constants for OpenPGPv2) only makes sense, and will only really be possible if the plan is to have an OpenPGPv2 which only has SHOULD for backwards compatibility options. Is this the plan? That OpenPGPv2 should be the clean up version? Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11049 for ietf-open-pgp-bks; Mon, 24 Nov 1997 15:22:58 -0800 (PST) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11045 for ; Mon, 24 Nov 1997 15:22:54 -0800 (PST) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id RAA05853; Mon, 24 Nov 1997 17:16:10 -0600 (CST) Received: from lax-ca69-49.ix.netcom.com(207.223.161.177) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma005674; Mon Nov 24 17:15:13 1997 Message-ID: <347A0A80.3352C014@sternlight.com> Date: Mon, 24 Nov 1997 15:15:23 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: uri@watson.ibm.com CC: Adam Back , ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving References: <9711241626.AA70184@watpub1.watson.ibm.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2F430162516CDCC8FC52644B" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms2F430162516CDCC8FC52644B Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Uri Blumenthal wrote: > Adam Back says: > > > b. There have been no practical cases of signature spoofing with MD5--it > > > hasn't been broken. > > > > I agree, in the general case it has not. I'll discuss a better > > user migration path below. > > Excuse me, gentlemen, were there any practical cases of signature > spoofing with MD4? > > Also, since this is an IETF forum, let me remind you, that the > official IETF security guideline is: "For all the new standards > MD5 shall not be used - but SHA-1". > > Of course, Security Area folks don't have the depth of knowledge > tat David has been exhibiting on the Net for quite a while (:-). Your gratuitous slam comes with ill grace from someone who apparently doesn't understand the meaning of "for all the new standards". We were talking about PGP's pulling RSA key generation from free PGP 5.0, and pulling RSA entirely from free PGP 5.5.2, neither of which is a new IETF standard or even a standard in work.. What is more, they didn't pull it from pay PGP 5.0 at the same time, so your argument fails doubly. > However, as an algorithm starts showing cracks, a cryptographer > with brains replaces it before the "practical" cases start > piling up. For a commercial product to get into such a > situation would mean death, I think (unless you are > Micro$oft, of course :-). They didn't replace it in pay PGP 5.0. > > > > > c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0 > > > > It is possible that Will was talking about the fingerprint spoofing > > attack, which you are probably aware of. This flaw is nothing to do > > with MD5 or RSA per se, but more to do with a flaw introduced in the > > way that the fingerprint is calculated in pgp2.x. > > It was possibly to ease the upgrade path for paying customers. Like: > "Yes, we strongly suggest you move to SHA-1, but to make sure your > traffic isn't interrupted, here's 'bilingual' PGP for you." And free PGP users didn't deserve an eased upgrade path, but rather to forcibly obsolete all their keys, signatures and web of trust in the new version? Especially since the RSA-key Free PGP user base is where PGP Inc. made their reputation and the size of that base is constantly cited to the IETF and in press releases as PGP's "customer base". Don't be ridiculous. And watch who you throw stones at--can you say "glass house"? David --------------ms2F430162516CDCC8FC52644B Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKjQYJKoZIhvcNAQcCoIIKfjCCCnoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CIUwggPPMIIDOKADAgECAhAnuK6izE0BOIf7uTQQ8usCMA0GCSqGSIb3DQEBAgUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA4MjEwMDAw MDBaFw05ODA4MjEyMzU5NTlaMIIBEjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDIgLSBOZXRzY2FwZTEZMBcGA1UEAxMQRGF2aWQgU3Rlcm5saWdodDEjMCEGCSqGSIb3 DQEJARYUZGF2aWRAc3Rlcm5saWdodC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN09h1fHJlSiS54oM5YjKy9J6wMmjUFL58Xkwc6JiCBftinxpbm2ziTPSAn4TMhSVbZnuC1m oDZln2HSvkRS61+BwYL3yw9kus2/Tyoi4gparm1O+CRlRkudAP8w7cHax6AZXTr7KDQA/mOq nXSPERdO3XZIgvVRXvL7VIVt++F7AgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0gBIGn MIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24A AAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBAgUAA4GBAE8QvB3wHstP4Ggj +WuQRdIKOsO4U3F5mUjfle6hatqCA1fvD3Kzmrr4KSvBes2CH0BKV/Mmb/rRkkwXaspTkSIC 0ENT789yEuv/aoOVogJVaKYHz7bgNkSuwa6O8SKHkrGHdQRxl3J+GN1SEgOzkW7A15d702QM 0tR6rtxMvtxYMIICeTCCAeKgAwIBAgIQUNNSlJEvedMV4ysxrIVI8DANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3 MDAwMDAwWhcNOTgwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlk dWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+b yB2eT7R1731MMPOyqjS/mdtGxtSYxx1FDuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqt WhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCI cp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCG SAGG+EIBAQQEAwICBDANBgkqhkiG9w0BAQIFAAOBgQAN6OSPQTmZ8ouFAbfodckgYj0dsq43 RhipxsLh/k6LwgZbQUbv8sxw0AEqFp5AUak+wBPYFljrwLCW/qnQZbM1RsFBCP6IlPSbtgyv YbUZrIGeVCdsNpBTxypskPapJdjkip4YXyd8jdn10TX+OZmd7OjE9vRuXjCXTgiI0JmvnzCC AjEwggGaAgUCowAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFg a355LPoGDzqu9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fM CGw/PrNK/P9LbCPVUIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQAD gYEAe6+kHC/Amw47XPyo5tGWD0hySYXlrxojAOPpu4A0bLI/hKg8cnCzTN5z+nyE0pKlADcJ wgM0IwO37XaW3D5Phf1YF/QEvuxRHtx629uu6GF42mU4R6wdA3Bt6eO7oEqfQOq823O/Z01d xnwgXOfoogorwgl010z+2+lrAmNdOacxggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVy bmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQJ7iuosxNATiH+7k0EPLrAjAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTEy NDIzMTUyNlowIwYJKoZIhvcNAQkEMRYEFCXZevcCSR6C2Fm4mLrBGn1hP7bRMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAR1T+MNslzioKErFETvgf IyhYvxAjHnWAmxnfypU/wYZunaMuHsRhA/eMyo53ttNxiS2DQYH0co2WnoPjNEMvK3nG5Txw WArQR5Vk5BtoOXFsVPQGVBT/BcC4zTE8r/sMyedgrGltAl10dUSM32FpOPIxmRrhb8Su2I8/ sbM2nbU= --------------ms2F430162516CDCC8FC52644B-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA10105 for ietf-open-pgp-bks; Mon, 24 Nov 1997 13:59:10 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA10100 for ; Mon, 24 Nov 1997 13:59:06 -0800 (PST) Received: from [205.180.136.44] (shiva4.pgp.com [205.180.136.44]) by fusebox.pgp.com (8.8.7/8.8.5) with ESMTP id OAA21062 for ; Mon, 24 Nov 1997 14:00:16 -0800 (PST) X-Sender: vinnie@mail.pgp.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Nov 1997 13:59:42 -0800 To: ietf-open-pgp@imc.org From: Vinnie Moscaritolo Subject: RE: PGP API Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >does anyone know of any docs for the Windows PGP 5.0 DLL's ? >.... >I beleive that there is a PGP Developers Kit for the Windows platform for >integrating PGP into application. sorry for the delay, I just recently re-joined the list. I recently posted a webpage at http://www.pgp.com/sdk/ that descibes and lets you download a copy of the the developer kit from PGP. THere are libraries for Mac, Win32 and Unix. I have also set up provisions for using it for freeware/shareware. since this is a commercial product, I wont go about it on this list, drop me an email if you need more info. __________________________________________________________________________ Vinnie Moscaritolo tel: 415.524.6222 Pretty Good Privacy, Inc. Senior Consulting Engineer main: 415.572.0430 2121 S. El Camino Real web: http://www.pgp.com San Mateo, CA 94403 DH Key: http://keys.pgp.com:11371/pks/lookup?op=get&search=0x070A5CFF 1 if by land, 2 if by sea. Paul Revere - encryption 1775 __________________________________________________________________________ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA08734 for ietf-open-pgp-bks; Mon, 24 Nov 1997 12:03:42 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA08730 for ; Mon, 24 Nov 1997 12:03:39 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id MAA19450 for ; Mon, 24 Nov 1997 12:04:48 -0800 (PST) Message-Id: <3.0.3.32.19971124120455.00ae3140@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 24 Nov 1997 12:04:55 -0800 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: hand huffman encoding at PGP world HQ In-Reply-To: <199711241537.HAA24948@s20.term1.sb.rain.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The "hand huffman-coded" structures go all the way back to the origins of PGP, they're hardly new. I agree with the sentiment that it would be nice to have a system laid out with long constants, but I think that that would be a good thing to do in V2 of the spec. I'd like to get this one done, and then let the working group debate new formats. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07607 for ietf-open-pgp-bks; Mon, 24 Nov 1997 10:58:26 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07600 for ; Mon, 24 Nov 1997 10:58:23 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA18315; Mon, 24 Nov 1997 10:59:22 -0800 (PST) Message-Id: <3.0.3.32.19971124105929.00aee9d0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 24 Nov 1997 10:59:29 -0800 To: Ian Brown , Jeremey Barrett From: Jon Callas Subject: Re: The case against redundancy and isolation Cc: IETF OpenPGP , rdenny@dc3.com In-Reply-To: <3476F29C.F3ADAD0C@cs.ucl.ac.uk> References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:56 PM 11/22/97 +0000, Ian Brown wrote: 1. We should not MUST MIME *or* Armour. Both increase the amount of code needed for a minimal implementation, which none of us want. As Dave said, linearly increased code increases exponentially the potential for errors. 2. We are not trying to eliminate Armour. It is entirely appropriate that it should be in there as an option to provide backward compatibility, if implementors so wish. 3. Both systems are for converting fully secure binary PGP data into a form which can be safely stored in/sent across 7-bit systems. Mail is such a system. Armour/MIME does nothing for security. As Dave and Jon have both said, OP is NOT a mail standard. It is a security standard. 7-bit conversion should therefore not be a MUST. As Lindsay Mathieson said, we can safely assume most file systems can cope with 8-bit data. Excellent statement, Ian. I can live with not MUSTing any of them. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07587 for ietf-open-pgp-bks; Mon, 24 Nov 1997 10:56:20 -0800 (PST) Received: from homer.communities.com (root@homer.communities.com [205.162.51.9]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA07583 for ; Mon, 24 Nov 1997 10:56:17 -0800 (PST) Received: from igor.four11.com (igor.four11.com [205.180.227.86]) by homer.communities.com (8.7.5/8.7.3) with SMTP id MAA12918; Mon, 24 Nov 1997 12:28:33 -0800 Message-Id: <3.0.3.32.19971124110041.007138c0@mail.communities.com> X-Sender: mccoy@mail.communities.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 24 Nov 1997 11:00:41 -0800 To: ietf-open-pgp@imc.org From: Jim McCoy Subject: Re: Armour Cc: platypus@acmeonline.net In-Reply-To: References: <199711232024.MAA22139@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Formosa wrote: [...] >The second group is all the scrips, hacks, glue and basic applications of >cyrto wich works with pgp[2|5]. These things tend to use pgp as a tool >rather then aplication all by itself. [...] Why do these things need to use 7-bit armored output? If they are using PGP as a tool then the scripts must implicitly lack the ability to actually do anything with the blob of data other than pass it around and run it through PGP. Neither of these functions requires armored output (although I would not doubt that lazy script writers keyed on things like ---BEGIN PGP...) jim Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA07539 for ietf-open-pgp-bks; Mon, 24 Nov 1997 10:53:54 -0800 (PST) Received: from sspe.mcit.com (switcheng.mcit.com [166.35.157.155]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA07534; Mon, 24 Nov 1997 10:53:49 -0800 (PST) Received: from pop4200.switcheng.mci.com by sspe.mcit.com with smtp (Smail3.1.29.1 #1) id m0xa3YW-0008tOC; Mon, 24 Nov 97 12:48 CST Message-Id: <3.0.2.32.19971124113607.006b7ddc@postoffice.switcheng.mci.com> X-Sender: dhayes@postoffice.switcheng.mci.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Mon, 24 Nov 1997 11:36:07 -0600 To: Ian Grigg , Dave Crocker / IMC From: David Hayes Subject: Re: Armour Cc: ietf-open-pgp@imc.org In-Reply-To: <347935B2.36C64BA7@systemics.com> References: <19971121164757.06784@songbird.com> <199711232024.MAA22139@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:07 AM 11/24/97 +0000, Ian Grigg wrote: >1. Is this WG happy to take as a given, or a working assumption, or a >fundamental position (pick your own term), that the compatibility with >the installed base is lost? There is a tendancy to assume that there will be an unbridgable rift between OP and pre-standard Classic PGP (2.6, Viacrypt 4, PGP Inc 5.x). This is not so, and is unlikely ever to be so. It is misleading to speak of compatibility "being lost". It _may_ be forgone by some implementations, which choose not to implement RSA/IDEA. They are still documented, for those who wish to use them. Compatibility with Classic PGP has become optional. All OP implementations will be compatible with each other. I suspect most will also be compatible with the Classic PGP, but that's up to implementers and users. It is true that a de-minimis implementation of OP will not be compatible with old PGP. -- David Hayes David.Hayes@MCI.Com Switch Systems Engineering voice: 972-918-7236 MCI Communications, Inc. VNET: 777-7236 --If these thoughts were MCI's official opinions, the line above would --read "MCI - Law & Public Policy Department". Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA05325 for ietf-open-pgp-bks; Mon, 24 Nov 1997 08:26:55 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA05317 for ; Mon, 24 Nov 1997 08:26:47 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id IAA18492 for ; Mon, 24 Nov 1997 08:29:22 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id HAA24948 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 07:37:47 -0800 Date: Mon, 24 Nov 1997 07:37:47 -0800 From: Hal Finney Message-Id: <199711241537.HAA24948@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: hand huffman encoding at PGP world HQ Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Adam Back writes: > Hal Finney writes: > > First, the difficulty is really not as large as people are making out. > > The code to read the packet lengths in the various cases is less than a > > page, and it's very simple. Read a byte to see if it is the old or new > > packet formats. In the old case, read 1, 2, or 4 bytes to get the length; > > in the new case, read 1 byte and if it's 0xc0 or over, read a second. > > The issue is the complexity and the code bloat. > > So with universal 32 bit length values, the code looks like: > [code samples, maybe with some endianness problems] Ideally you only have to write this code once, in a subroutine. You test it and get it right, and from then on you can rely on it. Yes, it's a few more lines of code, but it is not a major part of implementing OP. > Seems to me there is more likely to be an error in the second set of > code (probably is -- I haven't compiled it), also that the second > example will be larger, and the second example took about 4 times > longer to code. Multiply by the other bit twiddling operations (new > 192 bit twiddling, proprietry floating point stuff, and the same kind > of philosophy applied throughout etc) stir in some programmer error, > and there is significant extra complexity and code bloat, adding to > development time, creating errors, and dissuading people from coding > to OpenPGP. The code bloat will affect smart card implementations. I agree, as I said, that there is some additional cost to the coder. And you may be right that this will dissade some people from attempting the project, since apparently developers within this WG are concerned about the difficulty of implementing these fields. I can only reiterate that the payoff is intended to be for end users and not developers, and that compared to the level of effort for an OP implementation, writing a page of code to handle packet headers is not that large a burden. > I don't think it's that big a deal. The only place where size at the > bit scrimping level matters much is signatures. I reckon use of 32 > bit ints will add at max 3 bytes to the length of the signature. That > won't even cause an additional line wrap on your DSS sig example. The > longer keyID will be much more significant. This is one example we see now. Note that until we went to DSS it was not a very effective point. RSA signatures are many times larger than DSS ones. "Bit scrimping" was not very effective there. However, the point is that its philosophy of parsimony put PGP in position to exploit the concise nature of DSS signatures. The raw data for DSS sigs is only 40 bytes long. Saving a few bytes here and there is a significant percentage improvement. So this design philosophy gave us the advantage of a beautifully compact signature even though it was not specifically intended to address that case. When a philsophical approach gives you a serendipitous result like this, it creates hope that the philosophy is valid and will have similar unexpected payoffs in the future. (Or contrariwise that abandoning it in favor of bulky 32 bit and 64 bit lengths is going to foreclose some future opportunities.) This is a philosophical argument rather than a practical one since we can't point to specific future applications where it will matter. But generally it leaves more options open. > If you really want some nasty hacks to save space, I'm sure I could > construct some -- I am something of a past master at hand huffman > encoding cf the RSA in perl and dc signature -- an implementation of > RSA which is smaller than most PGP signatures :-) Yes, no doubt you could. You and Phil would probably make quite a team. > > Compare that with SMIME. If you've seen an SMIME signed message > > in any public forum, you've probably also seen complaints about it. > > The signature block is about 50+ lines long. > > Yes David Sternlight just posted one to this forum. I had just > previously picked apart a x509 signature made by a colleague -- 4350 > bytes, and most of it turned out to be text disclaimers and legalese. Yes, and level 2 certs include the cert holders street address! People didn't even know. > One pass processing is a useful feature -- perhaps we could do > something simple like SSLv3 does -- max of 16k -- a simple 16 bit > integer. No need for this > 192 means something odd hacking -- the 1 > byte of bloat I don't think will be a problem. However you do it, it will add some complexity, which may reduce the attractiveness of the simple-seeming 32 or 64 bit length field. Hal -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHmfQ8Dh8jnv1nHwEQKXvQCbB0nPw1/3NhlTCEno0RK/ByZjTp8AnR8w G//rDgQg4V7U7fQdgGWxAhyK =jFgv -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA05324 for ietf-open-pgp-bks; Mon, 24 Nov 1997 08:26:53 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA05316 for ; Mon, 24 Nov 1997 08:26:45 -0800 (PST) Received: from s20.term1.sb.rain.org (s13.term1.sb.rain.org [198.68.144.143]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id IAA18487 for ; Mon, 24 Nov 1997 08:29:19 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id HAA24914 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 07:16:56 -0800 Date: Mon, 24 Nov 1997 07:16:56 -0800 From: Hal Finney Message-Id: <199711241516.HAA24914@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: PGP 5.x will communicate with 2.6.x Sender: owner-ietf-open-pgp@imc.org Precedence: bulk There was a bug in the initial release of 5.5 (but not in 5.0) which impaired the intended backward compatibility. Key signatures issued by an RSA key on another RSA key were using v4 packets, instead of the intended v3 packets. Older versions of PGP will complain when they see v4 signature packets. This can cause some interoperability problems even when using RSA keys. This bug has been fixed in update release 5.5.2. (Sorry, I am not in the distribution chain, and I am not familiar with the procedures involved in acquiring updates.) Hal Finney Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA05302 for ietf-open-pgp-bks; Mon, 24 Nov 1997 08:25:33 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA05298 for ; Mon, 24 Nov 1997 08:25:29 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id LAA14062; Mon, 24 Nov 1997 11:26:19 -0500 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id LAA11470; Mon, 24 Nov 1997 11:26:19 -0500 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA70184; Mon, 24 Nov 1997 11:26:18 -0500 From: Uri Blumenthal Message-Id: <9711241626.AA70184@watpub1.watson.ibm.com> Subject: Re: PGP evolving, improving To: aba@dcs.ex.ac.uk (Adam Back) Date: Mon, 24 Nov 1997 11:26:17 -0500 (EST) Cc: david@sternlight.com, ietf-open-pgp@imc.org In-Reply-To: <199711240953.JAA00602@server.test.net> from "Adam Back" at Nov 24, 97 09:53:17 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back says: > > b. There have been no practical cases of signature spoofing with MD5--it > > hasn't been broken. > > I agree, in the general case it has not. I'll discuss a better > user migration path below. Excuse me, gentlemen, were there any practical cases of signature spoofing with MD4? Also, since this is an IETF forum, let me remind you, that the official IETF security guideline is: "For all the new standards MD5 shall not be used - but SHA-1". Of course, Security Area folks don't have the depth of knowledge tat David has been exhibiting on the Net for quite a while (:-). However, as an algorithm starts showing cracks, a cryptographer with brains replaces it before the "practical" cases start piling up. For a commercial product to get into such a situation would mean death, I think (unless you are Micro$oft, of course :-). > > c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0 > > It is possible that Will was talking about the fingerprint spoofing > attack, which you are probably aware of. This flaw is nothing to do > with MD5 or RSA per se, but more to do with a flaw introduced in the > way that the fingerprint is calculated in pgp2.x. It was possibly to ease the upgrade path for paying customers. Like: "Yes, we strongly suggest you move to SHA-1, but to make sure your traffic isn't interrupted, here's 'bilingual' PGP for you." > > Brave talk, but if you had any integrity you would have explained > > any concerns and left it up to users by preserving all options--not > > crammed it down the free user's throats. > > I think that unencumbered algorithms are a good thing, however I think > the method of "encouraging" migration to DSS/EG algorithms has largely > backfired. I did a survey of pgp users, which I'll colate shortly, > and several commented that they scrapped 5.0 and went back to 2.x when > they discovered the various compatibility problems (eg. not being able > to generate RSA keys). Well, the only compatibility concerns that *I* have as a user are related to the broken *interface*. I.e. I APPLAUD the move to DSS and EG (would like to see ECC too, BTW) - but I absolutely hate the fact that I can no longer use Mailcrypt-3.4 from XEmacs. This is my "compatibility problem", not the ability or inability to generate RSA keys (which you can take with you on your way out :-). > Now the discussion of a better migration path. It seems to me that a > nice thing to do would be to generate two keys at key gen time: an RSA > key and an DSS/EG pair. What if I *don't* want to generate RSA keys. Why cramming those down my throat? Make it possible to geterate DSS *or* DSS+RSA, if you REALLY insist... > Largely transparent interoperability on all versions > would I suspect paradoxically have meant many more people made the > switch. Yes and no. Of course transparency will help. HOWEVER, many of PGP users have either no time, or no skills (or "no" both) to modify the software that interfaces between their favorite whatever and PGP. For me it is Mailcrypt/XEmacs. Until *that* part is taken care of - don't expect people to switch. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA04629 for ietf-open-pgp-bks; Mon, 24 Nov 1997 07:35:07 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA04622 for ; Mon, 24 Nov 1997 07:34:57 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Nov 1997 15:34:53 +0000 Message-ID: <34799E08.9F377C8B@cs.ucl.ac.uk> Date: Mon, 24 Nov 1997 15:32:25 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Kent Crispin CC: IETF OpenPGP Subject: Re: Armour References: <34796347.888AAEC7@cs.ucl.ac.uk> <19971124070541.51716@songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > That's an entertaining possibility. The implication being that a mail > program that could handle all the possibilities would require me > keeping copies of pgp2 and 5, along with a new OP compliant program, and > the mail program would have to be written to deal with them all. Am I > the only one who thinks this is nuts? No you aren't, as this wasn't what I said. People are complaining that old services won't work if we do x to the standard. People who currently use such services obviously have a current version of PGP. They will be able to continue using such services if they so wish. Meanwhile, said services can be upgrading to use the new standard. I really have lost count of how many times people have made the point that MUST OP implementations will not be backward compatible because of decisions we have made already. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA04550 for ietf-open-pgp-bks; Mon, 24 Nov 1997 07:29:38 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA04546 for ; Mon, 24 Nov 1997 07:29:34 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EK5008GDPR5PM@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 10:30:42 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EK500M2NPQVJB@lmco.com> for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 10:30:36 -0500 (EST) Date: Mon, 24 Nov 1997 10:30:30 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: re: CMR To: ietf-open-pgp@imc.org Message-id: <971124103030.20e13b48@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > So you accept it as a given that shredding evidence is appropriate and > desirable behavior in a free society? Even if said shredding is > conducted by the White House (or #10 Downing Street)? It can be - depends on the context. I use a shredder daily to produce kitty litter. I only use my own property to do this (and pity anyone who tries to go through my trash 8*). In other contexts, where retention is a condition for use established by the property owner then clearly destruction is not appropriate. Think the major area of concern is of demands by a third party for access. Since citizens, unlike those in the military, are not the property of the government (yet,here), whether shredding is or is not done is not anyone else's business without due process. Could be rong. Hope not. Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA04435 for ietf-open-pgp-bks; Mon, 24 Nov 1997 07:21:27 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA04431 for ; Mon, 24 Nov 1997 07:21:23 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EK5008DZPDHPM@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 10:22:29 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EK500MCWPB1JD@lmco.com> for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 10:21:01 -0500 (EST) Date: Mon, 24 Nov 1997 10:20:55 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: RE: Ancient Technology To: alexlh@xs4all.nl Cc: ietf-open-pgp@imc.org Message-id: <971124102055.20e13b48@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >The defacto standard for sending anything but plain-text-English >emails is MIME. Ascii Armour is from the time that UUEncoding was the >hip thing. The mailreaders of 99% of the internet users today already >understand MIME, they don't understand AA, so adding support for >PGP/MIME to them should be trivial. I tend to agree at least for corporate use since Eudora, Exchange, and ccMail all understand MIME which would seem to simplify plug-ins. AsciiArmouring is not necessary for PGP to operate properly, rather it is a "nice" but is ready to be considered a hysterical element along with TekHex and UUencode (which could also be easily supported). However I must agree that the prevalent mechanism today is Base64 encoding. Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA04246 for ietf-open-pgp-bks; Mon, 24 Nov 1997 07:07:06 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA04242 for ; Mon, 24 Nov 1997 07:07:02 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id HAA16190 for ietf-open-pgp@imc.org; Mon, 24 Nov 1997 07:05:43 -0800 Message-ID: <19971124070541.51716@songbird.com> Date: Mon, 24 Nov 1997 07:05:41 -0800 From: Kent Crispin To: IETF OpenPGP Subject: Re: Armour References: <34796347.888AAEC7@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <34796347.888AAEC7@cs.ucl.ac.uk>; from Ian Brown on Mon, Nov 24, 1997 at 11:21:43AM +0000 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Mon, Nov 24, 1997 at 11:21:43AM +0000, Ian Brown wrote: [...] > Don't forget, as Ian Grigg pointed out, that PGP 2|5 software won't > disappear overnight. We can continue to use them in many situations > where backward compatibility is important. That's an entertaining possibility. The implication being that a mail program that could handle all the possibilities would require me keeping copies of pgp2 and 5, along with a new OP compliant program, and the mail program would have to be written to deal with them all. Am I the only one who thinks this is nuts? Five messages ago there was a rant about pgp 5 breaking interoperability with pgp2. Now we are talking about an OP that won't be interoperable with with either. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA03833 for ietf-open-pgp-bks; Mon, 24 Nov 1997 06:38:58 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA03826 for ; Mon, 24 Nov 1997 06:38:48 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id PAA18776; Mon, 24 Nov 1997 15:39:53 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@belenus.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Draft comments Date: 24 Nov 1997 14:39:53 GMT Organization: IKS GmbH Jena Lines: 33 Message-ID: References: <3.0.3.32.19971121182014.00a358d0@mail.pgp.com> NNTP-Posting-Host: belenus.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Jon Callas wrote: >I've already said my part on why I think armour is *not* primarily for >backwards compatibility. The PART X headers are not a new header, though. >They are an old header. I don't mind losing them, or deprecating them. No. they are new. >I meant that new combined header that has a begin-message and the hash >announcement. I think that as long as the "Hash:" header line can have >multiple hashes there (or it is legal to have multiple hash headers), then >we don't need this, and it simplifies to just remove it. Hash headers can contain multiple values. They are specified as: ::= 'Hash:' ::= | ',' ::= 'SHA1' | 'MD5' | 'MD2' | 'RIPEM160' Btw: ::= | | >When PGP 2.6 was created, the version number of the packets was bumped from >2 to 3, but nothing else was changed. It's really only there so you can That's not true. V2 has a different padding for encrypted session keys and digests than V3. So V2 and V3 are totally incompatible. It's absolutly necessary to respond to an V2 key using the old format. >you send me a compressed message, I can't read it." This is so that a >minimal implementation -- one that does not have compression (remember, the >MUST algorithm for compression is uncompressed) -- can advertise that it >doesn't have compression. So the default has to be changed to 'prefered = no compression'. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA02979 for ietf-open-pgp-bks; Mon, 24 Nov 1997 05:32:01 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA02973 for ; Mon, 24 Nov 1997 05:31:55 -0800 (PST) Received: from server.test.net ([194.168.64.81]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAC1009; Mon, 24 Nov 1997 13:33:02 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id MAA01508; Mon, 24 Nov 1997 12:05:37 GMT Date: Mon, 24 Nov 1997 12:05:37 GMT Message-Id: <199711241205.MAA01508@server.test.net> From: Adam Back To: iang@systemics.com CC: david@sternlight.com, ietf-open-pgp@imc.org In-reply-to: <3479420D.27A54854@systemics.com> (message from Ian Grigg on Mon, 24 Nov 1997 08:59:57 +0000) Subject: Re: PGP evolving, improving Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Grigg writes: > So there are problems with the old PGP system. But, and it's an > important but, these (key) problems only effect keyservers in general. > As most people don't use key servers, this is not a tremendous problem, > and certainly not justification for dropping the old formats. It is of > course more important to PGP Inc as their products use key servers > automatically. That's an easy one to solve: just use a different value for the automated keyserver lookup. eg keyID||fingerprint. For manual pgp2.x users of the same keyservers (rather than software automated pgp5.x lookups) just provide an additional CGI form for fingerprint, and a short text explaining the problem, and how to avoid it. Display the fingerprint by default also might be a good idea. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA02978 for ietf-open-pgp-bks; Mon, 24 Nov 1997 05:32:00 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA02968 for ; Mon, 24 Nov 1997 05:31:53 -0800 (PST) Received: from server.test.net ([194.168.64.81]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAB1009; Mon, 24 Nov 1997 13:32:59 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id NAA01702; Mon, 24 Nov 1997 13:32:45 GMT Date: Mon, 24 Nov 1997 13:32:45 GMT Message-Id: <199711241332.NAA01702@server.test.net> From: Adam Back To: JonWienk@ix.netcom.com CC: iang@systemics.com, ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971123170234.006bcdcc@popd.netcruiser> (message from Jonathan Wienke on Sun, 23 Nov 1997 17:02:34 -0800) Subject: Re: PGP 5.x will communicate with 2.6.x Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jonathan Wienke writes: > As long as only old-style RSA keys are used when encrypting a message 5.x > will talk to 2.6.x. If you create an RSA key with a CMRK packet or other > 5.x features, it is not hard to understand why 2.6.x would break. Just a nit: I don't think pgp5.x will let you put a CMR (aka packet no 666) signature subpacket on an RSA key. (At least it was described that PGP 5.x for business had RSA keys disabled for this reason). This breaks orthogonality, not that I'm complaining in this case, for obvious reasons. Also it may be that this is an implementation choice rather than a restriction of the standard. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA02977 for ietf-open-pgp-bks; Mon, 24 Nov 1997 05:31:57 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA02963 for ; Mon, 24 Nov 1997 05:31:51 -0800 (PST) Received: from server.test.net ([194.168.64.81]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA1009; Mon, 24 Nov 1997 13:32:56 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id NAA01616; Mon, 24 Nov 1997 13:21:36 GMT Date: Mon, 24 Nov 1997 13:21:36 GMT Message-Id: <199711241321.NAA01616@server.test.net> From: Adam Back To: hal@rain.org CC: ietf-open-pgp@imc.org In-reply-to: <199711240154.RAA02289@s20.term1.sb.rain.org> (message from Hal Finney on Sun, 23 Nov 1997 17:54:03 -0800) Subject: Re: hand huffman encoding at PGP world HQ Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney writes: > It is true that Phil Zimmermann has been the chief advocate of making > PGP data structures as concise as possible. [...] > > First, the difficulty is really not as large as people are making out. > The code to read the packet lengths in the various cases is less than a > page, and it's very simple. Read a byte to see if it is the old or new > packet formats. In the old case, read 1, 2, or 4 bytes to get the length; > in the new case, read 1 byte and if it's 0xc0 or over, read a second. The issue is the complexity and the code bloat. So with universal 32 bit length values, the code looks like: word32 len; char ctb = getc(fp); read(fp,&len,4); len = ntohl(len); ... With bit twiddling the code looks more like: word32 len = 0; char lchar[4]=(char*)&len; char ctb = getc(fb); int lol = ctb & 3; ctb &= ~3; if (lol == 0) { read(fp,lchar+3,1); } else if (lol == 1) { read(fp,lchar+2,2); } else if (lol == 2) { read(fp,lchar,4); } len = ntohl(len); ... Seems to me there is more likely to be an error in the second set of code (probably is -- I haven't compiled it), also that the second example will be larger, and the second example took about 4 times longer to code. Multiply by the other bit twiddling operations (new 192 bit twiddling, proprietry floating point stuff, and the same kind of philosophy applied throughout etc) stir in some programmer error, and there is significant extra complexity and code bloat, adding to development time, creating errors, and dissuading people from coding to OpenPGP. The code bloat will affect smart card implementations. > The payoff is that you have slightly reduced the size of all the PGP > exchanged data. By itself it is not so much, but as a philosophy applied > throughout the design, these savings add up. The alternative philosophy > of making everything 32 or 64 bits can lead to bloated data structures. > It's easier on the coder, but every user pays the cost in terms of > larger data. I don't think it's that big a deal. The only place where size at the bit scrimping level matters much is signatures. I reckon use of 32 bit ints will add at max 3 bytes to the length of the signature. That won't even cause an additional line wrap on your DSS sig example. The longer keyID will be much more significant. > -----BEGIN PGP SIGNATURE----- > Version: PGP for Business Security 5.5.2 > > iQA/AwUBNHijtqy7FkvPc+xMEQJ9EQCg98ARQWaclA7enOcIroIRiaGJeQsAn1om > OZVLRqiOTCRBMJSZ6QX2pbUZ > =Juy1 > -----END PGP SIGNATURE----- > (He'd like to see the -----END line go away, too, since it is redundant.) > You can hardly imagine a more concise signature block than this. If you really want some nasty hacks to save space, I'm sure I could construct some -- I am something of a past master at hand huffman encoding cf the RSA in perl and dc signature -- an implementation of RSA which is smaller than most PGP signatures :-) > Compare that with SMIME. If you've seen an SMIME signed message > in any public forum, you've probably also seen complaints about it. > The signature block is about 50+ lines long. Yes David Sternlight just posted one to this forum. I had just previously picked apart a x509 signature made by a colleague -- 4350 bytes, and most of it turned out to be text disclaimers and legalese. ISO 7816-9 is being re-written to come up with a smaller x509 style certificate because the project involved couldn't fit three of the x509 bloaters on their cards! So that is an example of at least one standard which might find OpenPGP interesting, and proof that this issue is a problem. > Now, this is largely a design error in the client software, in that > it is including the whole certificate chain in the signature. But > it is probably going to be a factor in slowing acceptance of SMIME. > Nobody likes a technology which brings them tons of flames every > time they send a clearsigned message. Agree. Another neat trick to remove this problem is what mailcrypt used to offer: to puts the PGP signature in an X-signature header (can't find it in the docs for v3.4 he may have removed it). (Course you wouldn't want an X509 sig in your headers -- the huge header might crash some software!) > PGP's philosophy has been one of being willing to pay a cost in > implementation complexity in order to reduce objectionable aspects > of the software to end users. Part of that has been making the data > structures as compact as possible. I am confident I can shave a few more percent or so off your current data structures... you really want to see the hacks? > Let me make one technical point, in case all this philosophizing is > unpersuasive. Part of the purpose of the new packet length headers is > to allow "one pass" processing. You can put out a packet length header > which says "will be followed by 2K of data, then another packet length > header". This allows you to start emitting data even when you don't > know the total length of the data in advance, and also allows lengths > greater than 2^32 bits. One pass processing is a useful feature -- perhaps we could do something simple like SSLv3 does -- max of 16k -- a simple 16 bit integer. No need for this > 192 means something odd hacking -- the 1 byte of bloat I don't think will be a problem. > This is one of several technical changes which are designed to allow > one-pass processing. Yesterday I explained how the new ascii armor header > line and the one-pass signature packets also supported this capability. > It's an important feature which allows software to get by without the use > of temporary files. > > Any changes to another packet length header format should provide some > way of allowing one-pass processing. A simple 32 bit length will not > be adequate. You could either have a 16 bit length field, or a 32 bit length field. You can still have the continuation feature, this is useful and largely separable feature. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Mon, 24 Nov 1997 03:54:51 -0800 (PST) Received: from server.test.net ([194.168.71.18]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA26185; Mon, 24 Nov 1997 11:55:53 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id JAA00602; Mon, 24 Nov 1997 09:53:17 GMT Date: Mon, 24 Nov 1997 09:53:17 GMT Message-Id: <199711240953.JAA00602@server.test.net> From: Adam Back To: david@sternlight.com CC: ietf-open-pgp@imc.org In-reply-to: <34793505.17CAB964@sternlight.com> (message from David Sternlight on Mon, 24 Nov 1997 00:04:34 -0800) Subject: Re: PGP evolving, improving Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Sternlight writes: > This is a bogus explanation for two reasons: > 1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most > versions of pay PGP 5.0. > 2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see > below). Yet : > a. MD5 is a hash function not an encryption algorithm. > b. There have been no practical cases of signature spoofing with MD5--it > hasn't been broken. I agree, in the general case it has not. I'll discuss a better user migration path below. > c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0 It is possible that Will was talking about the fingerprint spoofing attack, which you are probably aware of. This flaw is nothing to do with MD5 or RSA per se, but more to do with a flaw introduced in the way that the fingerprint is calculated in pgp2.x. Here's a key with a spoofed fingerprint: Type Bits/KeyID Date User ID pub 704/977EE465 1997/06/08 Adam Back -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAzObE60AAAECwJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW 65d+5GUBSJ7iDg8utJslk8EUh7N3zF12fHn7mFtGTUrpSl9F5C47Kci4nVVqSmcT tCpBZGFtIEJhY2sgPHNwb29mZWQgZmluZ2VycHJpbnQgRE8gTk9UIFVTRT6JAG0D BRAzmxOtOgSW65d+5GUBAQ27ArwOTveQTs0kjzBEMa09yWFs5+jNjv5tzSCngzXO bRzvwhTwWz4voR3ov2o0bGTYZF1biKRKeKqZzHb4Oq4XhD4TADdlmsxA5gQgbYFN 5K+tbgWEDQD53KFv =rlth -----END PGP PUBLIC KEY BLOCK----- It has the same fingerprint as my low security 1024 bit key attached below. However it does not have the same keyid. It is fairly unlikely that pgp2.x key generation code would generate a key for which it is possible to spoof both keyid and fingerprint at the same time. Therefore a simple solution is to always consider the keyid part of the fingerprint information, say like this: 556a4a67/18b8a0659d381483615ae6ac918b9e57 This would then be a user education task. Many people do include the keyid in their signatures along with fingerprints already. pgp2.x already displays the keyid at the same time. (I downloaded the 25Mb key ring and searched all the keys to see if there was anyone a double keyid and fingerprint spoof was possible for -- there was not. It was something like a 25% chance I think I calculated given the size of the key database.) > In short, PGP Inc. has taken the weakest and most vulnerable sector--the > free users, and shoved it to them in an authoritarian "big brother" way. > (Ironic, that, given many PGP' staffers' and the founder's ideological > pretensions). Since that is the "huge" RSA-key user base (check the MIT and > linked international servers) PGP is waving around to justify itself both > in press releases and to the IETF, a more egregious case of biting the hand > that indirectly feeds one is hard to imagine. When you subscribe to this list (ietf-open-pgp), it says this: : PGP has become a very popular method for establishing trust between : internet users for securing communications. In order to grow the : installed-base of over 4 million users, ... So yes, PGP uses the freely installed base in it's figures. RSADSI used to be fond of this also (using freeware PGP installed base in their figures of RSA users). > Brave talk, but if you had any integrity you would have explained > any concerns and left it up to users by preserving all options--not > crammed it down the free user's throats. I think that unencumbered algorithms are a good thing, however I think the method of "encouraging" migration to DSS/EG algorithms has largely backfired. I did a survey of pgp users, which I'll colate shortly, and several commented that they scrapped 5.0 and went back to 2.x when they discovered the various compatibility problems (eg. not being able to generate RSA keys). > This is especially underhanded-seeming since Free PGP 5.0 uses RSAREF, > which can generate RSA keys, carries no fees, and is not in legal dispute > as between PGP Inc. and RSADSI. Yes, I agree with this... there is no legal reason not to include RSA keygen in freeware.. it already includes RSA encrypt decrypt, and RSAREF allows this anyway. Now the discussion of a better migration path. It seems to me that a nice thing to do would be to generate two keys at key gen time: an RSA key and an DSS/EG pair. The software could then cross authenticate the keys (thus retaining the web of trust if the RSA key was an old one.) The software could then use DSS/EG keys when talking to other pgp5 users (as determined by their public key, or a feature such as a comment field embedded in a 2.x message which would not upset a pgp2.x implementation), and revert to RSA when the user could not cope with 5.x DSS/EG keys. Largely transparent interoperability on all versions would I suspect paradoxically have meant many more people made the switch. Adam The real key the above spoofed key is a fingerprint spoof of: Type Bits/KeyID Date User ID pub 1024/556A4A67 1993/06/08 Adam Back -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQCNAiwUXUEAAAEEAJnWEHE3juLAyMnEt3hrID3t8tblJvJPfoPz4Plg+2a5y4HA TonXBomkhm8hrRu1umruUUaeW1mxIbpvP413a2JyU7pdyfyoFVpWW5iT9pXYOgSW 65d+5GWe4g4PLrSbJZPBFIezd8xddnx5+5hbRk1K6UpfReQuOynIuJ1VakpnAAUT tBxBZGFtIEJhY2sgPGFiYUBkY3MuZXguYWMudWs+iQCVAwUQMiDfwUZRiTErSPb1 AQF/yAP8D1X2eAhXSc0P/X7lCHyBhWCl3pxa6oyGxFBOmUeOGfYna8CpJeMiTmZm akRWDYmJUiXscQUfd9qRv8eAeOtbvM87olSjm56Dlh4gYJFZRxZ6IhHlFJx3mPmp q9PnL+pSC41IIheRBJFzpKGD3LW9+VQwRAx9bXFJYyOFpx7vGJqJAJUCBRAwLhaV fjuD7tLfgD0BAYnfA/0XByiiqDX/cxgWt9syiobJ0TrTKloJcEgzxnKmqHH7rhqn wWGQA2pbWPGW1AwLtkeE+JYyk21YQZZxYWerK3JUi8a/ye4EaaJSs8mcw9YCwdPC Xa0nlalh09/FBEt83l5auNbw+zl9AcrOIGsTQcAr0Vy5nnV9IEfi6WZ3/aQ734kB FQMFEC/gRoaxVzBJFqEkZQEBEXcIAI6z9nUinIomouzB/3v1Fu9+kLOLiva+7Mp1 8UT40FXvHSabXe/cSV1//lnlYHJnfpJCPFSEjGox1pVBp9pLmiJBmubLfUrojIAn FDB081n6kB0B4BKb2rUiNghvT4CzpBZ149g/2NGscRIeQOCYkA2cBxT44v2luuqN 3Ahg9bWu+kjnxUKIK9Da/8D0ur5HiinBDevPiVf3/uoOdZ8F7alxqitBcC5ctIYR tr8fgdQq8is6dbeNxDMraV5vEpEN27AU4xOetymdFUufbU1K6Riw5TVZni9qXAgU ZS3zyFw7wqJ/SWILMWp+99ss921b+GpL+/m6S4j7LTXvFvcfy9aJAJUDBRAv2A0p Kci4nVVqSmcBAcfoA/9Pt3BeJ3TdTtQzb9DNT7LoXiQesYG68lzIl7BZsRvXoi2Q yeCPNc/juTGBnKBHgxZezJCW8TaKdJjNEncv7p+1o+9fwmy9UKWXskh6N+Y0ZlhJ bD0T+8+L+Wxpr6k3dao/GfOnCvw8vpvzDV9lnjtqe2B1mU5eAY76FFtZXvM9xw== =xN9o -----END PGP PUBLIC KEY BLOCK----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA01970 for ietf-open-pgp-bks; Mon, 24 Nov 1997 03:24:39 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA01966 for ; Mon, 24 Nov 1997 03:24:35 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Nov 1997 11:25:07 +0000 Message-ID: <34796347.888AAEC7@cs.ucl.ac.uk> Date: Mon, 24 Nov 1997 11:21:43 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: platypus@acmeonline.net CC: IETF OpenPGP Subject: Re: Armour References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > There is in my view two > groups of appiliactions that we should try and retain compatabilty unless > there is a very good resons against. > > The first group is the pgp[2|5] programs themselfs propper, this has been > already meantioned often and there is nothing orginal in this argument. > > The second group is all the scrips, hacks, glue and basic applications of > cyrto wich works with pgp[2|5]. These things tend to use pgp as a tool > rather then aplication all by itself. Meany of these things don't have > (or would be inapproprate to a have) Mime capatability but have a sence of > asscii armor. I would not like to see these things broken for the sake of > computaional estitics. Don't forget, as Ian Grigg pointed out, that PGP 2|5 software won't disappear overnight. We can continue to use them in many situations where backward compatibility is important. Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA01063 for ietf-open-pgp-bks; Mon, 24 Nov 1997 03:03:02 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA01055; Mon, 24 Nov 1997 03:02:52 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id WAA08948; Mon, 24 Nov 1997 22:02:19 +1100 Received: from shirley (dformosa@dialin-30 [137.154.130.30]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id WAA27576; Mon, 24 Nov 1997 22:02:15 +1100 (EST) Date: Mon, 24 Nov 1997 20:47:13 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Dave Crocker / IMC cc: ietf-open-pgp@imc.org Subject: Re: Armour In-Reply-To: <199711232024.MAA22139@proper.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sun, 23 Nov 1997, Dave Crocker / IMC wrote: > At 05:29 AM 11/24/97 +1100, David Formosa wrote: > >And consider all the aplications that have been built ontop of PGP. > > well, we really are re-cycling arguments. this one is the compatibility > issue again. It however is a diffrent compatibility argument. There is in my view two groups of appiliactions that we should try and retain compatabilty unless there is a very good resons against. The first group is the pgp[2|5] programs themselfs propper, this has been already meantioned often and there is nothing orginal in this argument. The second group is all the scrips, hacks, glue and basic applications of cyrto wich works with pgp[2|5]. These things tend to use pgp as a tool rather then aplication all by itself. Meany of these things don't have (or would be inapproprate to a have) Mime capatability but have a sence of asscii armor. I would not like to see these things broken for the sake of computaional estitics. [...] > 2. Installed base compatibility > > It has been observed a number of times that that is already lost for > other reasons, so use of MIME rather than Armour does not create a new > problem. The second population will have problems if Ascii armour is removed, in addtion as the backwards compatiblity will be only lost for a subsection of the population (thouse covered by verious patents) why brake it for everybody else? [...] > The need to document prior use is well served by having an appendix > which describes how to do armouring, for implementations needing to > interwork with pre-standards implementation. However it is clear that most implementaitons will need to interwork with the pre-standards indeed it should be a SHOULD. [...] > The argument that it is acceptable to require both or make both > optional misunderstand the additional overhead caused by requiring > redundant mechanisms or the difficulty achieving interworking when > everything is optional. Of cause but interworking is not going to happen unless we have interopablity with the old code base. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHlNJqQK0ynCmdStAQHDSQQAzH8Wf5Vrw4xgghH64K0arfUqNzlu6lvB 9mmR25Dq7DSeOZ8K9APnTGcJbi5ycXAhpgeXLzziFYjRsaQXZDQPLPJx4LeWAnb0 yVgLf3NlR/HCYCovbEFYd3j6OJ0HCMFd4CR6vvQEKooo72BDIAGmhVutALZhf0Dr MC8f3/BYOZc= =IsxR -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA29082 for ietf-open-pgp-bks; Mon, 24 Nov 1997 01:53:07 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA29078 for ; Mon, 24 Nov 1997 01:53:02 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id UAA08299 for ; Mon, 24 Nov 1997 20:52:41 +1100 Received: from shirley (dformosa@dialin-30 [137.154.130.30]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id UAA24741 for ; Mon, 24 Nov 1997 20:52:38 +1100 (EST) Date: Mon, 24 Nov 1997 19:37:24 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: IETF OpenPGP Subject: Re: hand huffman encoding at PGP world HQ In-Reply-To: <347860E3.2E4E0626@cs.ucl.ac.uk> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Sun, 23 Nov 1997, Ian Brown wrote: > I also absolutely agree with Adam's suggestion of simplifying data > structures. I'm just starting to implement PGP 5 packets; they are > *horrendously* over-complicated by the facts Adam mentioned. As he has > said before, "bits are cheap" - we can spare a few here and there ;-) I would have to dissagry with this comment. There is anouther signiture standard wich seems to approxmitly double the size of the post. If this item is mailed to a popular email list or a usenet newsgroup, it is very likely that the cost of sending redundent bits will eceed any value lost by forgery. [...] > Of course keep the description of the current system for backward > compatibility as a MAY. It is my view that meany peaple are under valueing backwards compatibility. The first thing that peaple are going to ask when thay download there new Open-PGP based product is "Will this work with PGP?". We must view backward compatibility as one of the over wealming factor that should only be sacrifesed for a condtion that would stop us from getting O-PGP into the 'marketplace'. Niceities like tidying up the presentaion layer protocol (Mime vs Ascii armor) or the way PGP veiws objects is not worth loosing the related backwards capisty. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHk8yaQK0ynCmdStAQGhkwP/W9fmq3wVxERv362LEFtr7Le7C59Qjg+i qWY1PcWZk1QMVYPUnkXSYEkHrlAV4wKSo87wuuQY5id5V9/y2SLqIb72+w4LrNKA n7NTrBfx3gd7wxWVvllBmPzWebxz8q/0aRg062d7cj3QYrA2NAwV/F1mEK76zTYl 8GqGjgWVWAU= =45r6 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA28521 for ietf-open-pgp-bks; Mon, 24 Nov 1997 00:56:36 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA28516 for ; Mon, 24 Nov 1997 00:56:32 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id LAA29522; Mon, 24 Nov 1997 11:25:10 +0100 (MET) Message-ID: <3479420D.27A54854@systemics.com> Date: Mon, 24 Nov 1997 08:59:57 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: david@sternlight.com CC: ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving References: <347524CA.345F5028@sternlight.com> <3475D1D8.83230A86@sternlight.com> <655ila$vkj@camel20.mindspring.com> <3476B712.D6F7B841@sternlight.com> <3477725f.2410710@165.87.194.249> <3478aeca.62569222@news.waikato.ac.nz> <3479b3c7.24386586@news2.ibm.net> <347924de.10890440@smtp1.ibm.net> <34793505.17CAB964@sternlight.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Sternlight wrote: > > I became aware of the post below only indirectly. I'll comment. David, there are some things that are obviously wrong, and some things that are, well, not quite absolutely wrong. Regardless, this is not really a forum for bashing PGP Inc and their product, although it seems like it at times. I'll just add what I know to your comments. > > >=====================8<=================== > > > > >At 5:30 PM -0800 11/22/97, David Sternlight wrote: > > >>And while you're introducing gratuitous issues unrelated to the > > discussion, > > >>why did PGP disable RSA key generation in Free PGP 5.0, and remove RSA > > >>compatibility completely from Free PGP 5.5 > > > > >Very simple. How can we with good conscience allow users to generate > > >keys > > >which we don't feel meet our security standards? We can't. Case > > >closed. > > This is a bogus explanation for two reasons: > 1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most > versions of pay PGP 5.0. I agree that there are lot of questions here... > 2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see > below). Yet : > a. MD5 is a hash function not an encryption algorithm. OK. Actually there are concerns with PGP. It is not with the RSA algorithm, that remains strong, and it is not with the actual RSA usage. Rather, it is with the format of the 2.6 packets and identifiers. As I recall, the flaws are: * create an arbitrary ID, and therefore spoof a key server * create a key with the same fingerprint as another, under some conditions, and thus spoof the server/key. For more detail, check out Gary's HIP-paper on http://www.hotlava.com/doc/fag-pgp/ I should note that PGP Inc have stated that all but one of the issues was known and fixed. So there are problems with the old PGP system. But, and it's an important but, these (key) problems only effect keyservers in general. As most people don't use key servers, this is not a tremendous problem, and certainly not justification for dropping the old formats. It is of course more important to PGP Inc as their products use key servers automatically. As to the MD5 weakness, yes, you are correct there: theoretical weaknesses do not mean an unseemly dumping of the existing user base is warranted. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA28020 for ietf-open-pgp-bks; Mon, 24 Nov 1997 00:04:14 -0800 (PST) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA28016 for ; Mon, 24 Nov 1997 00:04:10 -0800 (PST) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id CAA26103 for ; Mon, 24 Nov 1997 02:04:47 -0600 (CST) Received: from lax-ca66-23.ix.netcom.com(207.223.161.87) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma026100; Mon Nov 24 02:04:28 1997 Message-ID: <34793505.17CAB964@sternlight.com> Date: Mon, 24 Nov 1997 00:04:34 -0800 From: David Sternlight Reply-To: david@sternlight.com Organization: DSI/USCRPAC/IER X-Mailer: Mozilla 4.04 (Macintosh; U; PPC) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: PGP evolving, improving References: <347524CA.345F5028@sternlight.com> <3475D1D8.83230A86@sternlight.com> <655ila$vkj@camel20.mindspring.com> <3476B712.D6F7B841@sternlight.com> <3477725f.2410710@165.87.194.249> <3478aeca.62569222@news.waikato.ac.nz> <3479b3c7.24386586@news2.ibm.net> <347924de.10890440@smtp1.ibm.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms6508C516026A442844B60424" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms6508C516026A442844B60424 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit I became aware of the post below only indirectly. I'll comment. > >=====================8<=================== > > >At 5:30 PM -0800 11/22/97, David Sternlight wrote: > >>And while you're introducing gratuitous issues unrelated to the > discussion, > >>why did PGP disable RSA key generation in Free PGP 5.0, and remove RSA > >>compatibility completely from Free PGP 5.5 > > >Very simple. How can we with good conscience allow users to generate > >keys > >which we don't feel meet our security standards? We can't. Case > >closed. This is a bogus explanation for two reasons: 1. PGP Inc. disabled RSA key generation in free PGP 5.0 but kept it in most versions of pay PGP 5.0. 2. Their "explanation" wasn't about RSA keys but the MD5 algorithm (see below). Yet : a. MD5 is a hash function not an encryption algorithm. b. There have been no practical cases of signature spoofing with MD5--it hasn't been broken. c. The concern is mostly theoretical and remote. Even if one could generate a spurious message with the same hash as a real one, the spurious messages would overwhelmingly likely be gibberish. d. No general method has been shown which generates a hashed message with spurious but substantive motivated content having the same hash as a particular "real" message. e. The alternatives PGP 'likes" simply have a larger hash space but the same weakness. If a general solution to faking hashes is found the "new" hashes PGP uses would be just as vulnerable as MD5. Absent a general solution, chances of a motivated and genuine-seeming message having the same hash as the one being spoofed are essentially nil for MD5 as for longer substitutes. f. Moving to a new, longer hash function is about of the same class as moving from a 1024 to a 2048 bit key--theoretically more secure but not, in general, practically so. There is plenty of time to do so in an evolutionary way without vitiating existing keys, existing signatures, and the existing web of trust, as PGP Inc. has so vitiated with Free PGP 5.52. c. PGP Inc. has made no attempt to remove MD5 in pay PGP 5.0 In short, PGP Inc. has taken the weakest and most vulnerable sector--the free users, and shoved it to them in an authoritarian "big brother" way. (Ironic, that, given many PGP' staffers' and the founder's ideological pretensions). Since that is the "huge" RSA-key user base (check the MIT and linked international servers) PGP is waving around to justify itself both in press releases and to the IETF, a more egregious case of biting the hand that indirectly feeds one is hard to imagine. > >If you're unfamiliar with why RSA keys are not as secure as we'd like, > >you > >should check archives of the newsgroups for the past few years. The > >weaknesses of MD5 MD5 is not "RSA keys". RSA keys have not been shown in any way to be insecure any more than other keys of comparable length. The author purports to be a PGP expert. Not a very impressive demonstration of expertise. > and the KeyID attacks were the two primary security > >issues we felt absolutely had to be addressed in 5.0. But they weren't by dropping RSA. Pay PGP 5.0 still has RSA in most versions. > The development > >team > >couldn't have cared less about RSA licensing issues. The only issue > was > >security. Nonsense.Free PGP 5.0 still has RSA encryption and decryption. Only key generation has been disabled. Pay PGP 5.0 (most versions) have RSA key generation as well. This is a bogus explanation. > Fixing those required a new key format. As long as we were > >changing the key format, we decided to switch to unencumbered > algorithms > >at > >the same time since the hit was the same either way -- everyone would > >need > >new keys. Then why didn't you drop RSA encryption and decryption in Free PGP, and RSA key generation as well in pay PGP.? And it's a lot more than screwing users by making them get new keys. The free user base on which PGP made its reputation is now forced to get new signatures and reconstruct the entire web of trust as well with Free PGP 5.52, which contains no RSA. Brave talk, but if you had any integrity you would have explained any concerns and left it up to users by preserving all options--not crammed it down the free user's throats. This is especially underhanded-seeming since Free PGP 5.0 uses RSAREF, which can generate RSA keys, carries no fees, and is not in legal dispute as between PGP Inc. and RSADSI. > If a particular user doesn't mind the security issues with > >RSA > >keys, they should feel free to continue using them although the number > >of > >versions supporting those keys available from us will undoubtedly > >continue > >to dwindle, and at the same time the number of versions and platforms > >supporting DH/DSS keys will continue to grow dramatically. Pretty evasive and doesn't resolve the blatant contradictions in the above. > > > >-Will > > >Will Price, Architect/Sr. Mgr. > >Pretty Good Privacy, Inc. > David Sternlight, Ph.D. --------------ms6508C516026A442844B60424 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIKjQYJKoZIhvcNAQcCoIIKfjCCCnoCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CIUwggPPMIIDOKADAgECAhAnuK6izE0BOIf7uTQQ8usCMA0GCSqGSIb3DQEBAgUAMGIxETAP BgNVBAcTCEludGVybmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVy aVNpZ24gQ2xhc3MgMiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcjAeFw05NzA4MjEwMDAw MDBaFw05ODA4MjEyMzU5NTlaMIIBEjERMA8GA1UEBxMISW50ZXJuZXQxFzAVBgNVBAoTDlZl cmlTaWduLCBJbmMuMTQwMgYDVQQLEytWZXJpU2lnbiBDbGFzcyAyIENBIC0gSW5kaXZpZHVh bCBTdWJzY3JpYmVyMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvQ1BT IEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk2MSYwJAYDVQQLEx1EaWdpdGFsIElEIENs YXNzIDIgLSBOZXRzY2FwZTEZMBcGA1UEAxMQRGF2aWQgU3Rlcm5saWdodDEjMCEGCSqGSIb3 DQEJARYUZGF2aWRAc3Rlcm5saWdodC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB AN09h1fHJlSiS54oM5YjKy9J6wMmjUFL58Xkwc6JiCBftinxpbm2ziTPSAn4TMhSVbZnuC1m oDZln2HSvkRS61+BwYL3yw9kus2/Tyoi4gparm1O+CRlRkudAP8w7cHax6AZXTr7KDQA/mOq nXSPERdO3XZIgvVRXvL7VIVt++F7AgMBAAGjgdMwgdAwCQYDVR0TBAIwADCBrwYDVR0gBIGn MIAwgAYLYIZIAYb4RQEHAQEwgDAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24u Y29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24A AAAAAAAwEQYJYIZIAYb4QgEBBAQDAgeAMA0GCSqGSIb3DQEBAgUAA4GBAE8QvB3wHstP4Ggj +WuQRdIKOsO4U3F5mUjfle6hatqCA1fvD3Kzmrr4KSvBes2CH0BKV/Mmb/rRkkwXaspTkSIC 0ENT789yEuv/aoOVogJVaKYHz7bgNkSuwa6O8SKHkrGHdQRxl3J+GN1SEgOzkW7A15d702QM 0tR6rtxMvtxYMIICeTCCAeKgAwIBAgIQUNNSlJEvedMV4ysxrIVI8DANBgkqhkiG9w0BAQIF ADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNs YXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwNjI3 MDAwMDAwWhcNOTgwNjI3MjM1OTU5WjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNDAyBgNVBAsTK1ZlcmlTaWduIENsYXNzIDIgQ0EgLSBJbmRpdmlk dWFsIFN1YnNjcmliZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALoD7ZzMoZFxgx+b yB2eT7R1731MMPOyqjS/mdtGxtSYxx1FDuewxtFZ7RIBv/1CgtNn9wnSI4Gp2uTPtSmqopqt WhNJ2VIxUz3a1andsmdxkdAPW3jF3qVBV0jX9PpH7knRPW6Q52wj0mZ/4XbxLqDdHcvVIXCI cp5kpm/P7v3fAgMBAAGjMzAxMA8GA1UdEwQIMAYBAf8CAQEwCwYDVR0PBAQDAgEGMBEGCWCG SAGG+EIBAQQEAwICBDANBgkqhkiG9w0BAQIFAAOBgQAN6OSPQTmZ8ouFAbfodckgYj0dsq43 RhipxsLh/k6LwgZbQUbv8sxw0AEqFp5AUak+wBPYFljrwLCW/qnQZbM1RsFBCP6IlPSbtgyv YbUZrIGeVCdsNpBTxypskPapJdjkip4YXyd8jdn10TX+OZmd7OjE9vRuXjCXTgiI0JmvnzCC AjEwggGaAgUCowAAATANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNOTkxMjMxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEB BQADgY0AMIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFg a355LPoGDzqu9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fM CGw/PrNK/P9LbCPVUIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQAD gYEAe6+kHC/Amw47XPyo5tGWD0hySYXlrxojAOPpu4A0bLI/hKg8cnCzTN5z+nyE0pKlADcJ wgM0IwO37XaW3D5Phf1YF/QEvuxRHtx629uu6GF42mU4R6wdA3Bt6eO7oEqfQOq823O/Z01d xnwgXOfoogorwgl010z+2+lrAmNdOacxggHQMIIBzAIBATB2MGIxETAPBgNVBAcTCEludGVy bmV0MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE0MDIGA1UECxMrVmVyaVNpZ24gQ2xhc3Mg MiBDQSAtIEluZGl2aWR1YWwgU3Vic2NyaWJlcgIQJ7iuosxNATiH+7k0EPLrAjAJBgUrDgMC GgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTk3MTEy NDA4MDQzN1owIwYJKoZIhvcNAQkEMRYEFLiubsWbkOqEGP/4R67V0eVrF2pWMFIGCSqGSIb3 DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAi8ApLjdcoTUhx4M57D4B 68vfaTSiHlSg2j5ro55i9jZY9cbqyes4zxbXOGbx49F/2ttjRpwfS6Kl8Iu57r8Kn5o7cxTr QC/BKFLQ+7Hu6fcY6UJ7lfmW6mQb9KPXHR++hmIyrialBgMQGCxbKP4NTe43vU3SE0omEwzk RLrjlhA= --------------ms6508C516026A442844B60424-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA28013 for ietf-open-pgp-bks; Mon, 24 Nov 1997 00:03:50 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA28003; Mon, 24 Nov 1997 00:03:43 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id KAA29362; Mon, 24 Nov 1997 10:32:26 +0100 (MET) Message-ID: <347935B2.36C64BA7@systemics.com> Date: Mon, 24 Nov 1997 08:07:14 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Dave Crocker / IMC CC: ietf-open-pgp@imc.org Subject: Re: Armour References: <19971121164757.06784@songbird.com> <199711232024.MAA22139@proper.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Crocker / IMC wrote: > well, we really are re-cycling arguments. this one is the compatibility > issue again. Well, I guess we'll keep re-cycling until the WG has reached that concensus that is required to accept each and every proposal. Pedalling on... > 1. Technical I agree that technical concerns are not of prime importance. > 2. Installed base compatibility > > It has been observed a number of times that that is already lost for > other reasons, so use of MIME rather than Armour does not create a new > problem. OK. This is a missing assumption that I for one did not pick up, but am now seriously thinking about. It has taken a long time to get here, I hope everybody is still with us. A few (open) questions: 1. Is this WG happy to take as a given, or a working assumption, or a fundamental position (pick your own term), that the compatibility with the installed base is lost? 2. If compatibility with the installed base (as inferred above) is *not* lost, does the proposal that MIME should "replace" Armour (ignoring how&what) still have any merit? (I don't know the answers to these questions myself, I'm very interested to hear what others have to say.) > In this case > standardizing the prior use of armour will prevent PGP from being fully > integrated into the Internet technical suite and would require > implementation of redundant technology. Dave, I don't think you and I are connected over the same Internet. The net I am connected to includes PGP, and has for a number of years. It will continue to do so, and I say this with complete and utter conviction as the Internet I am connect to does not exclude technologies because they are old, because there is an alternative, or because some bunch of bureaucrats at the IETF might deign to pronounce otherwise. One of the wonderful discoveries of the Internet was to never limit the possibilities of multiple, apparantly competing standards. In this sense, the Internet is a pure market. It remains pure and unlimited until some limit comes along. PGP is currently facing no high level technologically imposed limits, and thus will remain as a viable security protocol for many many years, in whatever variant we can think of. I consider the above sweeping generalisation, "prevent PGP from being fully integrated into the Internet technical suite," to be out of place, unbacked and generally plain wrong. Statements such as whether we wish to "participate in the suite of Internet technology," and whether the group is being "uncooperative towards true integration with Internet mail and web standards..." only serve to flag to me, and perhaps others, that the rest of the discussion has nothing to add to the group, so if there are good points in there, they tend to be hidden. Maybe this is why I missed the very important assumption I discuss above. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA25322 for ietf-open-pgp-bks; Sun, 23 Nov 1997 18:08:15 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA25318 for ; Sun, 23 Nov 1997 18:08:12 -0800 (PST) Received: from s20.term1.sb.rain.org (s16.term1.sb.rain.org [198.68.144.146]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id SAA04115 for ; Sun, 23 Nov 1997 18:10:50 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id RAA02289 for ietf-open-pgp@imc.org; Sun, 23 Nov 1997 17:54:03 -0800 Date: Sun, 23 Nov 1997 17:54:03 -0800 From: Hal Finney Message-Id: <199711240154.RAA02289@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: hand huffman encoding at PGP world HQ Sender: owner-ietf-open-pgp@imc.org Precedence: bulk It is true that Phil Zimmermann has been the chief advocate of making PGP data structures as concise as possible. (I don't know whether Jon actually goes around the office singing songs about it or not.) Phil is out of the country now so I will try to relay some of his thinking. First, the difficulty is really not as large as people are making out. The code to read the packet lengths in the various cases is less than a page, and it's very simple. Read a byte to see if it is the old or new packet formats. In the old case, read 1, 2, or 4 bytes to get the length; in the new case, read 1 byte and if it's 0xc0 or over, read a second. The payoff is that you have slightly reduced the size of all the PGP exchanged data. By itself it is not so much, but as a philosophy applied throughout the design, these savings add up. The alternative philosophy of making everything 32 or 64 bits can lead to bloated data structures. It's easier on the coder, but every user pays the cost in terms of larger data. Phil contrasts PGP's philosophy of a clean interface with SMIME. Look at a PGP cleartext signature: -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5.2 iQA/AwUBNHijtqy7FkvPc+xMEQJ9EQCg98ARQWaclA7enOcIroIRiaGJeQsAn1om OZVLRqiOTCRBMJSZ6QX2pbUZ =Juy1 -----END PGP SIGNATURE----- Phil has proposed simplifications to shorten this to: -----BEGIN PGP SIGNATURE----- iQA/AwUBNHijtqy7FkvPc+xMEQJ9EQCg98ARQWaclA7enOcIroIRiaGJeQsAn1om OZVLRqiOTCRBMJSZ6QX2pbUZ=Juy1 -----END PGP SIGNATURE----- (He'd like to see the -----END line go away, too, since it is redundant.) You can hardly imagine a more concise signature block than this. Compare that with SMIME. If you've seen an SMIME signed message in any public forum, you've probably also seen complaints about it. The signature block is about 50+ lines long. Now, this is largely a design error in the client software, in that it is including the whole certificate chain in the signature. But it is probably going to be a factor in slowing acceptance of SMIME. Nobody likes a technology which brings them tons of flames every time they send a clearsigned message. Phil has worked from the beginning to make PGP be as usable and attractive to end users as possible, taking into consideration "real world" issues. Where PEM envisioned a complex hierarchical certification structure which didn't exist except on paper, PGP created the web of trust which could work locally and be useful from the beginning. In the case of SMIME, probably the designers of the client software envisioned a world where everyone was using MIME and no one would care how big and bloated the signatures were, since they wouldn't see them. But that's not the real world. PGP's philosophy has been one of being willing to pay a cost in implementation complexity in order to reduce objectionable aspects of the software to end users. Part of that has been making the data structures as compact as possible. These efforts to use concise data structures are costly to implementors, but beneficial to users. You pay the cost once per implementation - a few pages of code for this and similar features. But the benefit is felt every time a message is sent. It doesn't take much to swing the cost-benefit balance in favor of making things nicer for users. Let me make one technical point, in case all this philosophizing is unpersuasive. Part of the purpose of the new packet length headers is to allow "one pass" processing. You can put out a packet length header which says "will be followed by 2K of data, then another packet length header". This allows you to start emitting data even when you don't know the total length of the data in advance, and also allows lengths greater than 2^32 bits. This is one of several technical changes which are designed to allow one-pass processing. Yesterday I explained how the new ascii armor header line and the one-pass signature packets also supported this capability. It's an important feature which allows software to get by without the use of temporary files. Any changes to another packet length header format should provide some way of allowing one-pass processing. A simple 32 bit length will not be adequate. Hal Finney hal@rain.org hal@pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA24897 for ietf-open-pgp-bks; Sun, 23 Nov 1997 17:20:55 -0800 (PST) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA24893 for ; Sun, 23 Nov 1997 17:20:51 -0800 (PST) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id TAA29353; Sun, 23 Nov 1997 19:20:08 -0600 (CST) Received: from ffd-ca1-12.ix.netcom.com(205.186.177.44) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma029306; Sun Nov 23 19:19:24 1997 Message-Id: <3.0.3.32.19971123170234.006bcdcc@popd.netcruiser> X-Sender: JonWienk@popd.netcruiser X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 23 Nov 1997 17:02:34 -0800 To: Ian Grigg , Adam Back From: Jonathan Wienke Subject: PGP 5.x will communicate with 2.6.x Cc: ietf-open-pgp@imc.org In-Reply-To: <34787589.53549753@systemics.com> References: <199711231524.PAA02504@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 06:27 PM 11/23/97 +0000, Ian Grigg wrote: >This is not the effect that is occurring with the pgp5.0, as that has >IMHO failed, because it is practically incompatible. I'm not saying >pgp5 has failed, just that you need to consider other models. The >result with pgp5.0 is that if you upgrade, you won't be able to talk to >all your non-upgraded contacts at all, so you won't upgrade. (I'm not >entirely sure what is going on here, but I think what happens is that as >soon as the RSA keys get any of the extra packets added to them, it >appears that 2.6 will reject them in a variety of ways. I've tried with >3 different people to get comms between 2.6 (and Cryptix) and pgp5.0. >No joy yet.). As long as only old-style RSA keys are used when encrypting a message 5.x will talk to 2.6.x. If you create an RSA key with a CMRK packet or other 5.x features, it is not hard to understand why 2.6.x would break. I created the following key with 2.6.2 and then imported it into PGP 5.5: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP for Business Security 5.5 mQBNAzR4zmUAAAECAMYAlJypnCgZOLMnXu/RAdbhKtMGbMgFcKP9TEWN18aruWbj 7tyb1X1O5j0CRhg81Db+bVugZHpzWCtwekTC0TkABRG0FFNtYWxsIDIuNi4yIFRl c3QgS2V5 =cQvS - -----END PGP PUBLIC KEY BLOCK----- Here is the preceding text encrypted with PGP 5.5: - -----BEGIN PGP MESSAGE----- Version: PGP for Business Security 5.5 hQBMA1grcHpEwtE5AQH/eKTF2p0v8yAP6ThbZEIIPSX+wI0tLy/0qgj5U9Wy3WZJ LDdJUyQdK8M1l4Un7kMLtuAZeatZNp1gGVbnYX/fVqUDrNDfwpolf6hV6kpJfEpM Qh8KVmS59+BWQ1ogNzLjZfMQFzlBzO9b4OGTQmoSF+Nb4OWjQzk7LWklCVjbR39U fZXiPf/9F9LYQo1BTUts60VxUaLVjP4YL2Dmjbp3MR+kWBNMGaVa23dcqY6GAZ9T OuYTa5SuqYeFdRUBmWBQrpKnc6/WRW2ZieT8UE+C+x9tg7qj9yRvybdO9mz422nX J/1tP3IUrgtRDr1QD8D24PWh4ekCcBEcDVmBvvhl6uKvAN6Pq5Ks34dlnwfyfNhV HVaDa/wjTY+BY3rYWp8/hcSd6ZMNZfytyAlc46m1rdH7g/yysiujXVPPK0yYczKF nJ2VUIZnm3H0OIML0W6M4SmG+ZC6E7sXWViZ5Sf+kSTqyinsx9G8Zni687i8WrGp np4fILEwh96poQ0C2i+lAhBwiGWY6yND3ggTE4vD2t1nPXYcuS0B4WE/edO86j6Z dOctlCUSc6nI/cWk7nPovFnOdhQjaqykQMbXziwPwLcepW2eGz92o+iyRN+jIS1v 6f9Cvw7+PHwXP4QW7nCq0RxcBwikN6sLDHqT2fU6C/dKdVWj2WHkdoI0/34bwXvW mNwob3a+n1AXhW1BkYp/GM3fVbzPLbsZ3MLgpxVplg0XjnasfRxswFjNI/5DhLLP PI1jaKdU9VTXf8BYGYA6csgHbkFste/xaTbfYg/uHT305lvlyLxrSCbp/qCKjhZd 7O8gpqRN3PoVARgmbcv6lZf8y7SD5kr9vtStKb3WUihQK0VP/+k7ngP9LMZtz4Gy dMHz1/CQGRzvB1CzjkSoQU7WQQDAo6MaKbHc+Lpd+Cjy46AlIEx9/7HjZJR9Mqd5 49vs1OgWCWb6IWJt21kOLuof6TCMZ7Lb4F9lQY30KqMzRTM4BG+kNC99UZhtJ4SJ 4JJX7VAgo9Thj3zTGdcDXj9LC8aWuXs11wcliilOXVnWsaI4UDBz5DdVS2OMni9u vR4apl03yBCuoZr/yKXSOG7+hq1QzATuGblrUqeaiQSMa5rB0OwxtMPCyPcf54eJ r7r/ESi4onmdmNhPj7LA3TMJNwdfMvtXuNxCu/XuhCFClUYKzvvosjHgHepJQ4vn uLq57t5WlMcxzp9p/lXa1q+WLO8wXcRy+b2R02kYw9fTAKTa3YZKTCGiucYry2kn /N9SyYJCCgxSz3g0ZOCjWRxwgt6sFXB/dhyIKd4FHgAWVb1/cN3LBU7CYqH8cjDv CnnhNh4gsq2w3VcPiXA= =YsJ8 - -----END PGP MESSAGE----- Here is the preceding ciphertext successfully decrypted by PGP 2.6.2 (line breaks added during encryption): At 06:27 PM 11/23/97 +0000, Ian Grigg wrote: >This is not the effect that is occurring with the pgp5.0, as that has >IMHO failed, because it is practically incompatible. I'm not saying >pgp5 has failed, just that you need to consider other models. The >result with pgp5.0 is that if you upgrade, you won't be able to talk to >all your non-upgraded contacts at all, so you won't upgrade. (I'm not >entirely sure what is going on here, but I think what happens is that as >soon as the RSA keys get any of the extra packets added to them, it >appears that 2.6 will reject them in a variety of ways. I've tried with >3 different people to get comms between 2.6 (and Cryptix) and pgp5.0. >No joy yet.). As long as only old-style RSA keys are used when encrypting a message 5.x will talk to 2.6.x. If you create an RSA key with a CMRK packet or other 5.x features, it is not hard to understand why 2.6.x would break. I created the following key with 2.6.2 and then imported it into PGP 5.5: - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: PGP for Business Security 5.5 mQBNAzR4zmUAAAECAMYAlJypnCgZOLMnXu/RAdbhKtMGbMgFcKP9TEWN18aruWbj 7tyb1X1O5j0CRhg81Db+bVugZHpzWCtwekTC0TkABRG0FFNtYWxsIDIuNi4yIFRl c3QgS2V5 =cQvS - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 iQA/AwUBNHjSJsJF0kXqpw3MEQJLcACaA++2vNRYjewYCIFLg22NOBkFBPUAniRE 5t1QMphVFFMlr1lSGgBUSQWz =qLLM -----END PGP SIGNATURE----- Jonathan Wienke PGP Key Fingerprints: 7484 2FB7 7588 ACD1 3A8F 778A 7407 2928 3312 6597 8258 9A9E D9FA 4878 C245 D245 EAA7 0DCC "If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home from us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you. May your chains set lightly upon you; and may posterity forget that ye were our countrymen." -- Samuel Adams "Stupidity is the one arena of of human achievement where most people fulfill their potential." -- Jonathan Wienke Never sign a contract that contains the phrase "first-born child." RSA export-o-matic: print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Sun, 23 Nov 1997 16:26:59 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id CAA27883; Mon, 24 Nov 1997 02:55:38 +0100 (MET) Message-ID: <3478CAA5.3278145@systemics.com> Date: Mon, 24 Nov 1997 00:30:29 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org CC: wprice@pgp.com Subject: Interoperability Policy of PGP Inc Clarified Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Attached is a conversation between David Sternlight and PGP Inc's Will Price conducted on mac-crypto (and X-posted by Bob Hettinga). I believe this offers sufficient insight into the interoperability issue to be of importance to this WG. I am cross-posting without comment for the moment. =====================8<=================== At 5:30 PM -0800 11/22/97, David Sternlight wrote: >And while you're introducing gratuitous issues unrelated to the discussion, >why did PGP disable RSA key generation in Free PGP 5.0, and remove RSA >compatibility completely from Free PGP 5.5 Very simple. How can we with good conscience allow users to generate keys which we don't feel meet our security standards? We can't. Case closed. If you're unfamiliar with why RSA keys are not as secure as we'd like, you should check archives of the newsgroups for the past few years. The weaknesses of MD5 and the KeyID attacks were the two primary security issues we felt absolutely had to be addressed in 5.0. The development team couldn't have cared less about RSA licensing issues. The only issue was security. Fixing those required a new key format. As long as we were changing the key format, we decided to switch to unencumbered algorithms at the same time since the hit was the same either way -- everyone would need new keys. If a particular user doesn't mind the security issues with RSA keys, they should feel free to continue using them although the number of versions supporting those keys available from us will undoubtedly continue to dwindle, and at the same time the number of versions and platforms supporting DH/DSS keys will continue to grow dramatically. -Will Will Price, Architect/Sr. Mgr. Pretty Good Privacy, Inc. 555 Twin Dolphin Dr, Ste.570 Redwood Shores, CA 94065 Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Pager (310)247-6595 wprice@pgp.com =====================8<=================== -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA23346 for ietf-open-pgp-bks; Sun, 23 Nov 1997 14:20:09 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA23342 for ; Sun, 23 Nov 1997 14:20:05 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.8/8.6.9) id OAA08320; Sun, 23 Nov 1997 14:23:43 -0800 Date: Sun, 23 Nov 1997 14:23:43 -0800 Message-Id: <199711232223.OAA08320@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ian Brown Cc: IETF OpenPGP Subject: Re: The case against redundancy and isolation In-Reply-To: <34782441.774275FF@cs.ucl.ac.uk> References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> <199711221710.JAA06567@einstein.bluemoney.com> <34782441.774275FF@cs.ucl.ac.uk> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ian Brown writes: > > No, Armor doesn't effect the > > security of PGP itself, but it does affect how OP products will or > > can be used in the "real world" and therefore affects the "level of > > security provided by" the PGP system. (if noone used PGP, PGP is still > > secure, but the system is not because it isn't used). > > Jeremey, you are trying to redefine the meaning of "security of a > system". I have never read any security literature which says, for > example, "DES is more secure than IDEA because it is more widely > used." Certainly not, I do not mean that PGP is "more secure" because it has ASCII armoring capability (I thought I made this clear in that paragraph). What I mean is that a communications security system benefits from wide deployment and use. Re-designing the system in ways that render previous versions incompatible does not promote security. If there is a compelling reason to change it (for instance if past versions had protocol flaws, etc) then so be it, but I see no such reason here. All I see is 'standardization'. One can provide countless examples of standardization gone haywire (S/MIME, ASN.1, X.509, SET, etc.) and it does not always serve the end goal. I absolutely agree that support for MIME is important, MIME is a standard that is widely used. My argument is simply that ASCII armor is not a transport issue, rather it is an important functionality of PGP itself. > Taking Jon's point: is the ability to do armour critical to an OP > implementation on a smartcard, used for example to authenticate a user > at login? > Probably not, I can't see a case where it would be used. This is a good point, and makes a strong case for making ASCII armor a SHOULD and not a MUST. I wonder how feasible 100% compliance with OP is on a smartcard at all, with or without ASCII armor. Unfortunately, I think ASCII armor should be a MUST in almost every other case. Hrm. Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHis6S/fy+vkqMxNAQHdyQP6A+TTgJS/YkroErIs+GMOXh0VT8pofpgQ 4JJG4N17ix1t8jLzylMILxhLoKbB+EIV0hIyRdolhLOfptvroEATqUVeOKft1M6s NWwzMwdTexp2S3qV9w1YMkigGCvhX6dQZsHmJ3K+OAFBMiOxQz/g96pJ2cm7e03S 7KO+NTsHZgM= =95Bz -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA23257 for ietf-open-pgp-bks; Sun, 23 Nov 1997 14:11:46 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA23253 for ; Sun, 23 Nov 1997 14:11:40 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id LAA06392; Mon, 24 Nov 1997 11:12:42 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88032315727128>; Mon, 24 Nov 1997 11:12:37 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-open-pgp@imc.org Subject: Re: hand huffman encoding at PGP world HQ Cc: wprice@pgp.com Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Mon, 24 Nov 1997 11:12:37 (NZDT) Message-ID: <88032315727128@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>The last time I vented about this issue (I think on this list) someone >>relayed that at PGP they had gone stomping around the office singing >>"every bit you save, we'll be watching you,..." to the tune of the >>"every move you make, ..." melody. >A complete fabrication of course. I've never heard of this nor the perversion >of it posted by Guttman. The bit savers in the development group were soundly >criticized, but by that time it was too late. Most of this format stuff was >done before the company was even formed. Just to set the record straight on this: >I concur completely. I once got so fed up with this habit that I tromped >around the office singing, "Every bit is sacred / Every bit is great / When a >bit is wasted / Phil gets quite irate." > >Consider this to be one of the prime things to correct. Personally, I think >that numbers should never (well, hardly ever) be smaller than 32 bits. > > Jon >--- >Jon Callas jon@pgp.com >Chief Scientist 555 Twin Dolphin Drive >Pretty Good Privacy, Inc. Suite 570 >(415) 596-1960 Redwood Shores, CA 94065 Could we resolve this by making 32 bits a MUST and the other oddball stuff a MAY, or a deprecated MAY? Since the format gives you the option of choosing what you like, all that's necessary is to deprecate the weird stuff (perhaps MUST emit 32-bit lengths, MUST read 32-bit lengths, MAY read other types). Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA23027 for ietf-open-pgp-bks; Sun, 23 Nov 1997 13:43:06 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA23023 for ; Sun, 23 Nov 1997 13:43:02 -0800 (PST) Received: from [205.180.137.244] (atropos.pgp.com [205.180.137.244]) by fusebox.pgp.com (8.8.7/8.8.5) with ESMTP id NAA08452 for ; Sun, 23 Nov 1997 13:44:07 -0800 (PST) X-Sender: wprice@205.180.136.16 Message-Id: In-Reply-To: <199711231608.QAA02970@server.test.net> Mime-Version: 1.0 Date: Sun, 23 Nov 1997 13:44:20 -0800 To: ietf-open-pgp@imc.org From: Will Price Subject: Re: hand huffman encoding at PGP world HQ Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 8:08 AM -0800 11/23/97, Adam Back wrote: >I just read the draft. Lots and lots of bit twiddling, 0 < x < 192 if >this bit is set, then 2 << x-192+y if this bit set, 8 bit proprietry >floating point format, the legacy length of length bit twiddling (0 in >two bit field masked out of CTB is 1 byte length field, 1 is 2 byte, 2 >is 3 byte 3 is undefined). > >Arrrgh! > >All this bit twiddling and little hacks to scrimp on an extra bit here >and there is dangerous! Which hacker is it at PGP Inc that thrives on >these bit twiddling hacks? Come one 'fess up! I couldn't agree more with you on this one issue. I've been saying this for years. Unfortunately, I think the point is really moot. These are format issues. The format is already there and you can't really change it fundamentally without violating the WG charter. >The last time I vented about this issue (I think on this list) someone >relayed that at PGP they had gone stomping around the office singing >"every bit you save, we'll be watching you,..." to the tune of the >"every move you make, ..." melody. A complete fabrication of course. I've never heard of this nor the perversion of it posted by Guttman. The bit savers in the development group were soundly criticized, but by that time it was too late. Most of this format stuff was done before the company was even formed. - -Will Will Price, Architect/Sr. Mgr. Pretty Good Privacy, Inc. 555 Twin Dolphin Dr, Ste.570 Redwood Shores, CA 94065 Direct (650)596-1956 Main (650)572-0430 Fax (650)631-1033 Pager (310)247-6595 wprice@pgp.com Internet Text Paging: PGPkey: -----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5.2 iQA/AwUBNHijtqy7FkvPc+xMEQJ9EQCg98ARQWaclA7enOcIroIRiaGJeQsAn1om OZVLRqiOTCRBMJSZ6QX2pbUZ =Juy1 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA22334 for ietf-open-pgp-bks; Sun, 23 Nov 1997 12:26:02 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA22330 for ; Sun, 23 Nov 1997 12:25:58 -0800 (PST) Received: from omni.imc.org (pm3-13.netgate.net [205.214.163.13]) by proper.com (8.8.7/8.7.3) with SMTP id MAA22139; Sun, 23 Nov 1997 12:24:04 -0800 (PST) Message-Id: <199711232024.MAA22139@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Sun, 23 Nov 1997 12:26:08 -0800 To: platypus@acmeonline.net From: Dave Crocker / IMC Subject: Re: Armour Cc: Kent Crispin , ietf-open-pgp@imc.org In-Reply-To: References: <19971121164757.06784@songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 05:29 AM 11/24/97 +1100, David Formosa wrote: >And consider all the aplications that have been built ontop of PGP. well, we really are re-cycling arguments. this one is the compatibility issue again. To whit, these seem to be the categories of concerns and their answers: 1. Technical There is no strong argument that either MIME or Armour are superior at doing protection against the vagaries of transport. It is worth noting that Armour combines the control information with the data, whereas MIME keeps them separate. This facilitates processing by recipients who either do not have the necessary security software or who want to defer its use. That is, for authenticated data which is not also encrypted, the main data can be kept cleartext whereas with Armour it is not. 2. Installed base compatibility It has been observed a number of times that that is already lost for other reasons, so use of MIME rather than Armour does not create a new problem. There needs to be a distinction between pre-standards work, versus requirements of the standard. When incorporating existing technology into the standards process, this is always a challenge. In this case standardizing the prior use of armour will prevent PGP from being fully integrated into the Internet technical suite and would require implementation of redundant technology. The need to document prior use is well served by having an appendix which describes how to do armouring, for implementations needing to interwork with pre-standards implementation. The argument that it is acceptable to require both or make both optional misunderstand the additional overhead caused by requiring redundant mechanisms or the difficulty achieving interworking when everything is optional. If there are other categories of argumentation, I've missed them. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA22173 for ietf-open-pgp-bks; Sun, 23 Nov 1997 12:07:29 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA22169 for ; Sun, 23 Nov 1997 12:07:24 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA04721; Mon, 24 Nov 1997 09:08:14 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <88031569025766>; Mon, 24 Nov 1997 09:08:10 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: aba@dcs.ex.ac.uk Subject: Re: hand huffman encoding at PGP world HQ Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Mon, 24 Nov 1997 09:08:10 (NZDT) Message-ID: <88031569025766@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >The last time I vented about this issue (I think on this list) someone >relayed that at PGP they had gone stomping around the office singing >"every bit you save, we'll be watching you,..." to the tune of the >"every move you make, ..." melody. It was "Every bit is sacred, every bit is great, if a bit gets wasted, Phil gets quite irate", but your suggestion is equally appropriate. >I hereby call for length fields to be universally encoded as a 32 bit >integer. And all the above bit twiddling to be trashed. Relegate LOL >(length of length) and all the other length bit twiddling to MAY for >backwards compatibility. > >I would also argue for scrapping the non standard CFB hack (resyncing on >semantic boundaries) and putting in place standard cipher-block-sized CFB. I agree with both of these in principle, but how much hassle will it cause for implementors (and existing users)? If you do this then you're completely breaking compatibility with existing implementations, in which case you may as well do it properly and use ASN.1 or something similar which allows you to write a very precise definition of the message format which is simultaneously usable as the input to a parser which interprets the format. At the moment every PGP implementation has to be hand-coded and tuned, creating the potential for any number of bugs and problems, as Adam has pointed out. (The 32-bit fixed length may be a problem in the future when files grow over 4GB. Can the PGP encoding handle > 4GB data units at all?). It depends on how essential backwards compatibility is - if you're going to break it, it would be nice to move other things more into line with what the rest of the world is doing (eg use real X.509v3 cert extensions rather than trying to reinvent them yourself and ending up with something which is functionally identical to, but completely incompatible with, the X.509 certs which everyone else uses). Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA21979 for ietf-open-pgp-bks; Sun, 23 Nov 1997 11:45:00 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA21975 for ; Sun, 23 Nov 1997 11:44:55 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id GAA03381; Mon, 24 Nov 1997 06:44:31 +1100 Received: from shirley (dformosa@dialin-32 [137.154.130.32]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id GAA00620; Mon, 24 Nov 1997 06:44:29 +1100 (EST) Date: Mon, 24 Nov 1997 05:29:10 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Kent Crispin cc: ietf-open-pgp@imc.org Subject: Re: Armour In-Reply-To: <19971121164757.06784@songbird.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 21 Nov 1997, Kent Crispin wrote: > On Fri, Nov 21, 1997 at 01:27:38PM -0800, Dave Crocker / IMC wrote: [...] > In particular, the fact that simple MUA interfaces appear in many many > scripts, cgi programs, and so on virtually guarantees a 10 year > lifetime. So think about the following: > > mail $user <$file > > Imagine it is embedded in a cgi script, possibly sending a requested > file to a user. How do I leave an encrypted file on disk so it can > be sent? And consider all the aplications that have been built ontop of PGP. Things such as anon-remailers, secure (new|rm)group commands, NoCeM implentations ect. All of wich will have to be converted over to MIME, this makes Ascii armor a MUST for the forseeable future. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHh2AqQK0ynCmdStAQFsuAP/QdsTfXn4E3E1gNjQjDLOA8/BWItqNRUK l86Y4ip/w3fw5/qWn0AlbdyyOgfAl8MCze72qDfFHnyOELh2y6bXJrk9KXxAJZfM adIA9PgnIsfica8StQ2dUyKXqK1eBzpu4bALwDCfkdVtCB9A74GKpJRkiuVMZmvB TGk6lTT0EUk= =WE5q -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA21257 for ietf-open-pgp-bks; Sun, 23 Nov 1997 10:27:24 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA21252 for ; Sun, 23 Nov 1997 10:27:20 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id UAA26488; Sun, 23 Nov 1997 20:53:45 +0100 (MET) Message-ID: <34787589.53549753@systemics.com> Date: Sun, 23 Nov 1997 18:27:21 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Adam Back CC: stewarts@ix.netcom.com, ietf-open-pgp@imc.org, jon@pgp.com Subject: Re: case for removing subpacket type 10 References: <199711231524.PAA02504@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > > The bad news is that, while the Criticality Bit is only sketchily > > documented, it sounds like part of a CMRist plot, to make use of the > > ARR mandatory if the recipient requests it > > I see the problem -- ouch -- if a vendor choses to, they can make > their software mark ARRs as critical and old software will say that > the self signature failed. Which could result in the software not > using the key. > > I think the fact that doing so introduces compatibility problems > protects us from this happening, a vendor's corporate customers may > get irate when they are unable to communicate with OpenPGP compliant > implementations due to such a purposely introduced incompatibility. Nope, just the reverse. Your comment above has helped me see what Bill was talking about. Introducing compatibility problems in this way can be solved by upgrading to the latest release, so it becomes a tool for migrating your user base onto the new software. The technique is to make the software basically work, so as to limit the downside. MS are the masters of knowing which bugs not to fix. Mathematically, look to epidemic theory, which says something to the effect that if each instance causes k people to upgrade, where k is some number greater than 1 (i.e., 1.1) then it will work. Of course, it also works a lot better if you can offer a few new features with the upgrade. This is not the effect that is occurring with the pgp5.0, as that has IMHO failed, because it is practically incompatible. I'm not saying pgp5 has failed, just that you need to consider other models. The result with pgp5.0 is that if you upgrade, you won't be able to talk to all your non-upgraded contacts at all, so you won't upgrade. (I'm not entirely sure what is going on here, but I think what happens is that as soon as the RSA keys get any of the extra packets added to them, it appears that 2.6 will reject them in a variety of ways. I've tried with 3 different people to get comms between 2.6 (and Cryptix) and pgp5.0. No joy yet.). In the case of the Criticality bit, you will still have comms, but the various MUAs will alert you to problems, which is ideal. No loss of functionality, but an annoying reminder to upgrade every time you talk to someone :-) On this basis alone, I think we'd like to avoid a standardised "please upgrade me" virus. I think the issue here surrounds the nature of the extension. Normally, if one wanted to hack in and add the whatiwant feature, one would do it in such a way that the feature was innocuous to older non-conforming software. So the feature has to be an addition, without which the sum is unchanged from the older standard. In the new packets as discussed here, the PGP Inc whatiwant feature is a *subtraction* in that it applies some limit to the power of the signature. Now, you can't take something away, and then put it back whilst talking to those that don't understand the new mathematics. PGP Inc people have recognised this, and have added an additional feature that says "on any subtraction, reject the lot." If everybody understands that there is a subtraction going on, then at least if they can't put back that which was lost, then they can consider the whole things broken. Hal said: - On a self-signature, ignore the key if you don't understand the subpacket type. This is because the self-signature may be saying something important qualifying the meaning of the key or how it is intended to be used by the owner. If you don't know what he's saying, it's safest not to use the key. This is trouble piled upon trouble. Trying to set this sort of behaviour up in complex software is tricky, and is best avoided unless you're well paid to do precisely that (and I hope the folks at PGP Inc are indeed well paid). Putting it into a standard is equivalent to institutionalising software failures. I would suggest that the Criticality bit be dropped. > > (there _is_ the semantics issue of what the program should do if it > > understands the Additional Recipient Request and doesn't feel like > > cooperating :-) > > Well a cypherpunk or pro privacy advocate's PGP patch / implementation > can do one of a number of things: Precisely. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA21206 for ietf-open-pgp-bks; Sun, 23 Nov 1997 10:20:41 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA21202 for ; Sun, 23 Nov 1997 10:20:37 -0800 (PST) Received: from hayek.guvnet (wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id UAA26456; Sun, 23 Nov 1997 20:47:19 +0100 (MET) Message-ID: <34787407.8BB8B42@systemics.com> Date: Sun, 23 Nov 1997 18:20:55 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Adam Back CC: ietf-open-pgp@imc.org Subject: Re: hand huffman encoding at PGP world HQ References: <199711231608.QAA02970@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > > I just read the draft. Lots and lots of bit twiddling, 0 < x < 192 if > this bit is set, then 2 << x-192+y if this bit set, 8 bit proprietry > floating point format, the legacy length of length bit twiddling (0 in > two bit field masked out of CTB is 1 byte length field, 1 is 2 byte, 2 > is 3 byte 3 is undefined). > > Arrrgh! > > All this bit twiddling and little hacks to scrimp on an extra bit here > and there is dangerous! Which hacker is it at PGP Inc that thrives on > these bit twiddling hacks? Come one 'fess up! To be fair, when pgp[12].x was being hacked up, modems where slow, the Internet was still non-commercial, hacker power rulze OK. The whole net was singing "every bit you save, we'll be watching you,..." It's also true that PGP Inc still believe that bit-saving is a Good Thing; someone on mac-crypto is arguing (Will Price?) that S/MIME is bad because it has sigs in the two to ten K range, in complete contrast to the lessons of Microsoft and the Internet. Simplifying the structure and so forth is a good idea. I wish. But you are arguing for a new standard that would be completely non-compatible. It's logical that you would argue that a minimal implementation such as this would only include pgp2.6 compatibility, and even pgp5.x compatibility, as a may. Many have argued on this list for this sort of thing, and maybe it is time to reverse the opportunity versus interoperability priorities. Maybe it is time to recognise that the Open PGP result will be incompatible with the user base, and no holds are barred. That the current software base is not suitable for standardisation. >From a commercial point of view this is very attractive. Rewrite from the ground up makes more sense, as I agree with you that the cost of implementating a simple standard from scratch is less than the cost of implementing the pgp5.x model. Then, introduce a compatibility hack using pgp2.6 for the "classic" segment (if you can, simply invoke the old pgp. Guarunteed interoperability :-) . There is an issue here on commercial grounds that will probably provoke some interesting discussions. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA20930 for ietf-open-pgp-bks; Sun, 23 Nov 1997 09:55:11 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA20926 for ; Sun, 23 Nov 1997 09:55:07 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id UAA26381; Sun, 23 Nov 1997 20:23:50 +0100 (MET) Message-ID: <34786ED3.13100E24@systemics.com> Date: Sun, 23 Nov 1997 17:58:43 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: why MIME in the standard? References: <199711231540.PAA02955@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > Doesn't seem like a big deal implementation-wise -- the complexity > saving of removing the checksum probably more than compensates for > having to output and parse a fixed Content-Type: string. I don't think it is a big deal implementation-wise either. It is deployment that is my concern. Changing all those servers over, changing all the scripts over, upgrading all pgp script copies to handle mime because they can no longer get the AA keys from where ever they got them from before. All those interoperability issues can be solved in one of two ways: by having one software source (as in pgp2.6 up to nowish) and by having a standard that insists on interoperable feature sets. We write standards to solve the problem of interoperability in the absence of common source. We do not write standards to make it easier to implement, except as a secondary opportunity. As interoperability is the issue, IMNSHO, and everything that is out there with the label PGP attached to it uses Armour, then Armour it is. Add MIME to the standard if we believe this is the "way to go" by all means. But that's in the opportunity basket, not the interoperability basket. People like Dave Crocker are going to be possible proven "right" by events here But this is small change compared to the cost of breaking the current user base, no matter how "wrong" it might be. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA20871 for ietf-open-pgp-bks; Sun, 23 Nov 1997 09:50:17 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA20867 for ; Sun, 23 Nov 1997 09:50:12 -0800 (PST) Received: from omni.imc.org (d32.netgate.net [205.214.160.66]) by proper.com (8.8.7/8.7.3) with SMTP id JAA21951; Sun, 23 Nov 1997 09:48:23 -0800 (PST) Message-Id: <199711231748.JAA21951@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Sun, 23 Nov 1997 09:44:21 -0800 To: Kent Crispin From: Dave Crocker / IMC Subject: Re: The case against redundancy and isolation Cc: IETF OpenPGP In-Reply-To: <19971123061808.39639@songbird.com> References: <34782441.774275FF@cs.ucl.ac.uk> <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> <199711221710.JAA06567@einstein.bluemoney.com> <34782441.774275FF@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 06:18 AM 11/23/97 -0800, Kent Crispin wrote: >If the mailer does all the work for you, then why argue that mime is >necessary as a part of the OP spec? I don't mean that to be flip; I am Kent, et al, One of the problems in this discussion is that we seem to have a collection of people lobbying hard for a particular position, without having sufficient technical understanding of the position they are arguing against. This means that what is really needed is a tutorial, rather than a debate. Tutorials are fine, but not in the middle of a debate. In this case, the tutorial is about the basics of specifying MIME usage. First, "the mailer" does not do all the work for you. When you define a new kind of data you must specify details about the way MIME is used for that object, in particular naming the content type and any associated parameters, as well as the likely need for content transfer encoding. When the object gets interesting, you also need to specify whether it is treated as monolithic, with a single MIME wrapper around it or whether it is separated into pieces, using MIME's Multipart mechanism. "The work" that mailers can do, now, is that they already have all the code for parsing and dispatching these issues. If they must support armour, they must add code for it, yet it is entirely redundant with the services provided by MIME. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA20484 for ietf-open-pgp-bks; Sun, 23 Nov 1997 09:03:33 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA20480 for ; Sun, 23 Nov 1997 09:03:24 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 23 Nov 1997 17:02:33 +0000 Message-ID: <347860E3.2E4E0626@cs.ucl.ac.uk> Date: Sun, 23 Nov 1997 16:59:15 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Adam Back CC: IETF OpenPGP Subject: Re: hand huffman encoding at PGP world HQ References: <199711231608.QAA02970@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I also absolutely agree with Adam's suggestion of simplifying data structures. I'm just starting to implement PGP 5 packets; they are *horrendously* over-complicated by the facts Adam mentioned. As he has said before, "bits are cheap" - we can spare a few here and there ;-) A scheme with "32 bit length fields, whole byte (gasp the extravagance, a whole 8 bits!) packet types, 64 bit CFB etc." would be much easier for new implementors. Using standard cipher-block-sized CFB would make it *much* easier for people to implement PGP with any of the crypto libraries springing up, without requiring said libraries to do non-standard encryption modes. It may also reassure relatively new crypto people that we are not doing anything 'funny' which may compromise security. (I know we're not, but it's easier to explain to someone who doesn't know that if you can simply point to a page in Schneier). Of course keep the description of the current system for backward compatibility as a MAY. But to quote Dave Crocker yet again ;-), we can view our nascent standard's non-MUST backward compatibility as a problem or an opportunity. I think we should seize this opportunity now while we have the chance. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA20365 for ietf-open-pgp-bks; Sun, 23 Nov 1997 08:51:30 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA20361 for ; Sun, 23 Nov 1997 08:51:24 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 23 Nov 1997 16:51:00 +0000 Message-ID: <34785E2F.7A89CBAF@cs.ucl.ac.uk> Date: Sun, 23 Nov 1997 16:47:43 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Adam Back CC: stewarts@ix.netcom.com, ietf-open-pgp@imc.org, jon@pgp.com, iang@systemics.com Subject: Re: case for removing subpacket type 10 References: <199711231524.PAA02504@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > OK: so I call for subpacket 10 to be removed. Anyone else? I second that. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA20236 for ietf-open-pgp-bks; Sun, 23 Nov 1997 08:39:35 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA20231 for ; Sun, 23 Nov 1997 08:39:26 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 23 Nov 1997 16:40:21 +0000 Message-ID: <34785BB0.9537059B@cs.ucl.ac.uk> Date: Sun, 23 Nov 1997 16:37:04 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Kent Crispin CC: IETF OpenPGP , Adam Back Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> <199711221710.JAA06567@einstein.bluemoney.com> <34782441.774275FF@cs.ucl.ac.uk> <19971123061808.39639@songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Kent Crispin wrote: > If the mailer does all the work for you, then why argue that mime is > necessary as a part of the OP spec? I don't mean that to be flip; I am > asking for actual technical reasoning, maybe even with a concrete > example. How, precisely, do you imagine OP interacting with a mime > mailer such that OP has to know mime? I absolutely agree, Kent. This is the beauty of the MIME solution - it doesn't need to be part of the standard at all, apart from labelling the content-types - and that can go in OP-MIME instead. As Dave Crocker said, we can leave the 7-bit encoding functionality to MIME and concentrate on the security of the underlying binary data. Adam Back wrote: > However, there is another 7 bit transport problem which gets solved by > ascii armor currently: cut and paste operations on keys, eg look up on > a keyserver manually, or via finger, or appended to a mail. > > This could actually be acheived with MIME in place of armor -- just > include the Content-Type: headers and skip the checksum, and it's > basically the same thing. > > This would then need minimal MIME handling ability within the standard > and an implementation -- to be able to accept MIMEd key packets. There is actually already an application/pgp-keys content-type defined in PGP/MIME. Therefore, we can do the key-acceptance process even more easily than PGP 5 makes it (adding keys via the clipboard). Your mailer simply needs to be configured to use PGP as the "viewer" for an application/pgp-keys bodypart. The mailer could remove the MIME encoding and run PGP with the binary key data as input. PGP would recognise this and add the key. This would work just as well with keyserver output - when you retrieved a key, you wouldn't need to cut and paste it from your browser, the browser itself would run PGP on the key data. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA19883 for ietf-open-pgp-bks; Sun, 23 Nov 1997 08:09:22 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA19878 for ; Sun, 23 Nov 1997 08:09:14 -0800 (PST) Received: from server.test.net ([194.168.70.228]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAB24571; Sun, 23 Nov 1997 16:10:18 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id PAA02955; Sun, 23 Nov 1997 15:40:03 GMT Date: Sun, 23 Nov 1997 15:40:03 GMT Message-Id: <199711231540.PAA02955@server.test.net> From: Adam Back To: kent@songbird.com CC: ietf-open-pgp@imc.org In-reply-to: <19971123061808.39639@songbird.com> (message from Kent Crispin on Sun, 23 Nov 1997 06:18:08 -0800) Subject: why MIME in the standard? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Kent Crispin writes: > On Sun, Nov 23, 1997 at 12:40:33PM +0000, Ian Brown wrote: > [...] > > MIME 1) already exists, 2) is far more widely used than Armor, and 3) > > won't need to be implemented by an OP-MIME system as the mailer will do > > the work for you. > > If the mailer does all the work for you, then why argue that mime is > necessary as a part of the OP spec? I don't mean that to be flip; I am > asking for actual technical reasoning, maybe even with a concrete > example. How, precisely, do you imagine OP interacting with a mime > mailer such that OP has to know mime? I think that is a good point, and that for the purposes of mailer integration MIME could be defined to be outside the standard. Armor could then be the MAY legacy backwards compatibility mode for people who are not yet using a MIME aware mailer. However, there is another 7 bit transport problem which gets solved by ascii armor currently: cut and paste operations on keys, eg look up on a keyserver manually, or via finger, or appended to a mail. This could actually be acheived with MIME in place of armor -- just include the Content-Type: headers and skip the checksum, and it's basically the same thing. This would then need minimal MIME handling ability within the standard and an implementation -- to be able to accept MIMEd key packets. Doesn't seem like a big deal implementation-wise -- the complexity saving of removing the checksum probably more than compensates for having to output and parse a fixed Content-Type: string. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA19882 for ietf-open-pgp-bks; Sun, 23 Nov 1997 08:09:18 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA19873 for ; Sun, 23 Nov 1997 08:09:12 -0800 (PST) Received: from server.test.net ([194.168.70.228]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA24571 for ; Sun, 23 Nov 1997 16:10:15 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id QAA02970; Sun, 23 Nov 1997 16:08:14 GMT Date: Sun, 23 Nov 1997 16:08:14 GMT Message-Id: <199711231608.QAA02970@server.test.net> From: Adam Back To: ietf-open-pgp@imc.org Subject: hand huffman encoding at PGP world HQ Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I just read the draft. Lots and lots of bit twiddling, 0 < x < 192 if this bit is set, then 2 << x-192+y if this bit set, 8 bit proprietry floating point format, the legacy length of length bit twiddling (0 in two bit field masked out of CTB is 1 byte length field, 1 is 2 byte, 2 is 3 byte 3 is undefined). Arrrgh! All this bit twiddling and little hacks to scrimp on an extra bit here and there is dangerous! Which hacker is it at PGP Inc that thrives on these bit twiddling hacks? Come one 'fess up! It adds complexity all over the place, introduces numerous extra branches and possible failure points in the code... the likely coding failures could turn out to adversely affect security. To test all of the decision points in your software to check for correct operation, you construct test messages, and run a test job to exercise branches -- with all the extra conditions and combinations introduced by the bit twiddling it adds significant extra risk of a coding error slipping through. Also (thinking of the notional smart card hacker that Jon mentioned) bit twiddling causes code bloat, and performance degradation. Simplicity is important for security software. Add no more complexity than absolutely necessary. Simplicity is also important if we want people to implement to the standard. I hereby call for length fields to be universally encoded as a 32 bit integer. And all the above bit twiddling to be trashed. Relegate LOL (length of length) and all the other length bit twiddling to MAY for backwards compatibility. I would also argue for scrapping the non standard CFB hack (resyncing on semantic boundaries) and putting in place standard cipher-block-sized CFB. I'll relay a little hacking I did. I coded up an RSA and IDEA encryption app. I did the obvious things, used 32 bit length fields, whole byte (gasp the extravagance, a whole 8 bits!) packet types, 64 bit CFB etc. I used bits of SSLeay for bigints, the rest I coded myself. Took me about a week in total. It took me as long to frig with the bit twiddling that gives the bit-fetishist at PGP jollies (and diddling with the non standard CFB mode) to get it so that PGP could decode conventional encrypted messages my app created as it did to code the app! I expect other people will rediscover this experience if we keep this hand huffman encoding mentality in the standard. The last time I vented about this issue (I think on this list) someone relayed that at PGP they had gone stomping around the office singing "every bit you save, we'll be watching you,..." to the tune of the "every move you make, ..." melody. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA19509 for ietf-open-pgp-bks; Sun, 23 Nov 1997 07:23:38 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA19503 for ; Sun, 23 Nov 1997 07:23:34 -0800 (PST) Received: from server.test.net ([194.168.72.205]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA20491; Sun, 23 Nov 1997 15:24:36 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id PAA02504; Sun, 23 Nov 1997 15:24:21 GMT Date: Sun, 23 Nov 1997 15:24:21 GMT Message-Id: <199711231524.PAA02504@server.test.net> From: Adam Back To: stewarts@ix.netcom.com CC: ietf-open-pgp@imc.org, jon@pgp.com, iang@systemics.com In-reply-to: <3.0.3.32.19971122205401.006f5508@popd.ix.netcom.com> (message from Bill Stewart on Sat, 22 Nov 1997 20:54:01 -0800) Subject: case for removing subpacket type 10 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart writes: > So the Infamous Additional Recipient Request is just a subpacket of > known length, in a table of zero or more extension-like subpackets, > and the description of the Criticality Bit seems to imply that it's > ok to have subpacket types that aren't recognized and can be skipped > over because their lengths are known. So that's the good news. Seems to me that there is no problem at all just removing subpacket type 10 (the ARR/CMR subpacket). The draft already says that if an unrecognised subpacket is present in a self signature that it will be ignored. This is obviously needed to allow backwards compatibility when new subpackets are introduced. OK: so I call for subpacket 10 to be removed. Anyone else? > The bad news is that, while the Criticality Bit is only sketchily > documented, it sounds like part of a CMRist plot, to make use of the > ARR mandatory if the recipient requests it I see the problem -- ouch -- if a vendor choses to, they can make their software mark ARRs as critical and old software will say that the self signature failed. Which could result in the software not using the key. I think the fact that doing so introduces compatibility problems protects us from this happening, a vendor's corporate customers may get irate when they are unable to communicate with OpenPGP compliant implementations due to such a purposely introduced incompatibility. > (there _is_ the semantics issue of what the program should do if it > understands the Additional Recipient Request and doesn't feel like > cooperating :-) Well a cypherpunk or pro privacy advocate's PGP patch / implementation can do one of a number of things: a) as a special case ignore the criticality bit if combined with subpacket type 10 (ARR/CMR) b) pretend to capitulate with the "request" and stuff garbage in the extra PKE field instead of the session key; this will fool a policy enforcer policeman software which doesn't have the private key. c) capitulate and include a valid extra PKE field but automatically super encrypt to the real key holder only (optionally pad with a bit of garbage and white space to allow easy reconstruction with cut and paste, but to make auto detection difficult). Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA19162 for ietf-open-pgp-bks; Sun, 23 Nov 1997 06:19:32 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA19155 for ; Sun, 23 Nov 1997 06:19:27 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id GAA02923 for ietf-open-pgp@imc.org; Sun, 23 Nov 1997 06:18:10 -0800 Message-ID: <19971123061808.39639@songbird.com> Date: Sun, 23 Nov 1997 06:18:08 -0800 From: Kent Crispin To: IETF OpenPGP Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> <199711221710.JAA06567@einstein.bluemoney.com> <34782441.774275FF@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <34782441.774275FF@cs.ucl.ac.uk>; from Ian Brown on Sun, Nov 23, 1997 at 12:40:33PM +0000 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sun, Nov 23, 1997 at 12:40:33PM +0000, Ian Brown wrote: [...] > MIME 1) already exists, 2) is far more widely used than Armor, and 3) > won't need to be implemented by an OP-MIME system as the mailer will do > the work for you. If the mailer does all the work for you, then why argue that mime is necessary as a part of the OP spec? I don't mean that to be flip; I am asking for actual technical reasoning, maybe even with a concrete example. How, precisely, do you imagine OP interacting with a mime mailer such that OP has to know mime? -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA18607 for ietf-open-pgp-bks; Sun, 23 Nov 1997 04:43:04 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id EAA18603 for ; Sun, 23 Nov 1997 04:42:59 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 23 Nov 1997 12:43:46 +0000 Message-ID: <34782441.774275FF@cs.ucl.ac.uk> Date: Sun, 23 Nov 1997 12:40:33 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jeremey Barrett CC: IETF OpenPGP Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> <199711221710.JAA06567@einstein.bluemoney.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > No, Armor doesn't effect the > security of PGP itself, but it does affect how OP products will or > can be used in the "real world" and therefore affects the "level of > security provided by" the PGP system. (if noone used PGP, PGP is still > secure, but the system is not because it isn't used). Jeremey, you are trying to redefine the meaning of "security of a system". I have never read any security literature which says, for example, "DES is more secure than IDEA because it is more widely used." Even accepting your redefinition, making armour a MUST increases the effort needed to implement an OP-compatible system, so will reduce the use of the standard - thus reducing its 'security'. > It is reasonably easy to go > get a new version of PGP which doesn't use RSA or IDEA, or doesn't > default to them. You don't have to change the way you "do things" to > switch to ElGamal and CAST. MIME is different, because it is external > to PGP. And, as Dave Crocker has had to say over and over again, MIME is becoming very widely used in mailers. The vast majority of people don't even need to go out and get a new mailer to take advantage of it. > ASCII armor 1) already exists, 2) is widely used, and 3) is > quite trivial to implement MIME 1) already exists, 2) is far more widely used than Armor, and 3) won't need to be implemented by an OP-MIME system as the mailer will do the work for you. > My point is that the capacity for > 7-bit encoding is critical to PGP, and all OP-compliant products > should provide it regardless of what other 7-bit transport schemes > are supported. Taking Jon's point: is the ability to do armour critical to an OP implementation on a smartcard, used for example to authenticate a user at login? > I don't have > LDAP in my mail reader. Neither does anyone else, with the exception > of Netscape and Micro$oft users. Totally irrelevant to the argument. Regards, Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA14707 for ietf-open-pgp-bks; Sat, 22 Nov 1997 23:18:07 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA14703 for ; Sat, 22 Nov 1997 23:18:04 -0800 (PST) Received: from s20.term1.sb.rain.org (s08.term1.sb.rain.org [198.68.144.138]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id XAA00247 for ; Sat, 22 Nov 1997 23:20:39 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id XAA00865 for ietf-open-pgp@imc.org; Sat, 22 Nov 1997 23:03:13 -0800 Date: Sat, 22 Nov 1997 23:03:13 -0800 From: Hal Finney Message-Id: <199711230703.XAA00865@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: CMR as an extension _inside_ the standard (Re: CMR & ROT-13) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart writes, regarding signature subpackets: > 2 - signature creation time [And a bunch of similar good entries] > 4 - exportable [This isn't ITAR - this indicates whether > the signature can be transmitted to other people or is > for your own use only. So don't panic :-)] > 10 - The Infamous Additional Recipient Request > 16 - Issuer KeyID - Sounds Ominous and Not documented! Issuer keyid is what tells you who issued the signature. This information is in V3 signatures as well. > 12 - Revocation Key - Only for self-signatures(??) > so you can revoke your key after losing your key > 21 - Preferred hash algorithms > 22 - Preferred compression algorithms > 23 - key server preferences > 24 - preferred key server - presumably the Signer's preference > for finding further data about the Signer's key? > Bit 7 - Criticality Bit - [Semantics: I don't quite understand it? > Reject Key If you don't support the Subpacket Type, > or reject the signature rather than the whole key?] The criticality bit is intended to have two different meanings: - On a self-signature, ignore the key if you don't understand the subpacket type. This is because the self-signature may be saying something important qualifying the meaning of the key or how it is intended to be used by the owner. If you don't know what he's saying, it's safest not to use the key. - On other signatures, ignore the signature if you don't understand the subpacket type. The idea is that you understand the uses of the key that the owner specifies, but you don't understand what someone else is saying about the key. You ignore the whole signature by this other person because the subpacket may qualify the meaning of the signature (it may not be an identity signature, for example). > So the Infamous Additional Recipient Request is just a subpacket of known length, > in a table of zero or more extension-like subpackets, > and the description of the Criticality Bit seems to imply that it's > ok to have subpacket types that aren't recognized > and can be skipped over because their lengths are known. > So that's the good news. > > The bad news is that, while the Criticality Bit is only sketchily documented, > it sounds like part of a CMRist plot, to make use of the ARR mandatory if the > recipient requests it (there _is_ the semantics issue of what the program > should do if it understands the Additional Recipient Request and doesn't > feel like cooperating :-) The critical bit is intended to provide guidelines for the case where you don't recognize the subpacket type. It does not apply to cases where you recognize the subpacket but are choosing to ignore it. So it is irrelevant to the issue of the ARR subpacket. > The ugly news is that Additional Recipient Requests are a really weird thing > to attach to a signature, rather than part of the key itself - > I suppose that makes it easier for the Corporate Security Bureaucrats to request, > rather than having some special case part of the key generation, which would > be uglier, but it's still a strange place to put it. Putting information in a self-signature allows the user to modify it without invalidating all of the other signatures he has collected on his key. Preferred algorithms are another example where this may be very useful. > But in conjunction with the Criticality Bit, this extension method is a > Denial Of Service Attack - unless I'm misunderstanding the bit, > if the bit is set and the subpacket type is unrecognized, the recipient > is supposed to reject the entire key packet and not just the signature packet - > does this mean that somebody can sign your key with a Critically Bogus Subpacket > and prevent anybody from using your key? (e.g. by signing a keyserver key...) No, because this would be the second case above. All they can do is to make you ignore their signature, so they would accomplish nothing by it. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA14527 for ietf-open-pgp-bks; Sat, 22 Nov 1997 22:32:18 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA14523 for ; Sat, 22 Nov 1997 22:32:14 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id JAA24372; Sun, 23 Nov 1997 09:00:31 +0100 (MET) Message-ID: <3477CEB1.743889B6@systemics.com> Date: Sun, 23 Nov 1997 06:35:30 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Bill Stewart CC: ietf-open-pgp@imc.org, jon@pgp.com, Adam Back Subject: Re: CMR as an extension _inside_ the standard (Re: CMR & ROT-13) References: <3475709B.52A5DC4@systemics.com> <3.0.3.32.19971122205401.006f5508@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart wrote: > Jon's done a great job on the standard - I still find it hard to read, > partly because it's bottom-up rather than top-down, which makes it > easier to follow syntax and harder to follow semantics, and partly because > there's just a _lot_ of detail, and the newer features are pretty complex. Yes, I was always afraid of that, which was part of the reason I was concerned at getting the document out there. To be fair it was never likely to be anything else, as the architecture of PGP evolved from mysterious roots into the beast we now know and love. I hope there is time left after these other discussions going on for the WG to actually read the standard. > But if I do understand what's going on, the CMR support is just one entry > in a table that's needed anyway, plus a paragraph of apologies (:-), > and may be the primary motivation for one other feature. > > If I can modifiy Jon's syntax description a bit: > A Packet is a record containing the following in a tersely encoded format (:-) I'm sure ASN.1 would have been terser :-) > Packet Tag - indicates packet type, 0-15 (old) or 0-63 (new) ... > A Subpacket - [!!! FINALLY - THE FUN PART !!!] > Subpacket Length - (packed, one or two octets) > Subpacket Type-And-Criticality-Indicator - Octet > Subpacket Body - format is Subpacket Type dependent. > A Subpacket-Type-And-Criticality-Indicator Octet > Bits 0-6 - Subpacket Type, an entry from a table including ... > 10 - The Infamous Additional Recipient Request > 16 - Issuer KeyID - Sounds Ominous and Not documented! > 12 - Revocation Key - Only for self-signatures(??) > so you can revoke your key after losing your key > 21 - Preferred hash algorithms > 22 - Preferred compression algorithms > 23 - key server preferences > 24 - preferred key server - presumably the Signer's preference > for finding further data about the Signer's key? > Bit 7 - Criticality Bit - [Semantics: I don't quite understand it? > Reject Key If you don't support the Subpacket Type, > or reject the signature rather than the whole key?] > > So the Infamous Additional Recipient Request is just a subpacket of known length, > in a table of zero or more extension-like subpackets, > and the description of the Criticality Bit seems to imply that it's > ok to have subpacket types that aren't recognized > and can be skipped over because their lengths are known. > So that's the good news. In a sense what you are proposing is that sub packet 10 is reserved, has a length for skipping reasons, but no more. Yet another RFU number? I'll have to think about that (it took me about two weeks to develop my argument in the previous post - it's tricky stuff). > The bad news is that, while the Criticality Bit is only sketchily documented, > it sounds like part of a CMRist plot, to make use of the ARR mandatory if the > recipient requests it (there _is_ the semantics issue of what the program > should do if it understands the Additional Recipient Request and doesn't > feel like cooperating :-) And the notion that one would not support the subpacket but would support the bit - which you develop further below. I feel this is intuitively a non-starter. Once a progammer (or whoever) decides the subpacket(s) are not supported, then it is most likely the bit will be ignored, just from the human effort of trying to work out what the semantics of taking instructions from something you don't understand are. > The ugly news is that Additional Recipient Requests are a really weird thing > to attach to a signature, rather than part of the key itself - > I suppose that makes it easier for the Corporate Security Bureaucrats to request, > rather than having some special case part of the key generation, which would > be uglier, but it's still a strange place to put it. I guess this is a consequence of asking the respondent to participate in your recovery needs. Always likely to be clumsy as it bears no relationship to normal communications models. The only model where I can think of the respondent needing to play a part is secrets security, where everyone is encouraged to report comrades with treacherous thoughts. I suppose the effect looked for is that the recoveree initiator should sign their willfull acceptance so that the accessory responder can authenticate the entrance of the recoveror into the protocol. The special black box secret key generation methods would have been more robust. What I find the weirdest is that this system is at least deployed in test arenas, and for all we know in real customer sites. Somehow, the software engineering difficulties have been overcome, but I couldn't begin to work out the ramifications of such. Auditing, provability, reliability, ... my bind moggles! > But in conjunction with the Criticality Bit, this extension method is a > Denial Of Service Attack - unless I'm misunderstanding the bit, > if the bit is set and the subpacket type is unrecognized, the recipient > is supposed to reject the entire key packet and not just the signature packet - > does this mean that somebody can sign your key with a Critically Bogus Subpacket > and prevent anybody from using your key? (e.g. by signing a keyserver key...) Highly amusing :-) I'm sure there is an explanation on its way. In the meantime, one could try it. I believe that pgp5.0 supports all the above fields, and there are keyservers. Well spotted! Thinking about it, there's something odd in the way the signature tells the software where to pick up the key to check the signature... -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA14165 for ietf-open-pgp-bks; Sat, 22 Nov 1997 21:46:32 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA14156 for ; Sat, 22 Nov 1997 21:46:26 -0800 (PST) Received: from omni.imc.org (d10.netgate.net [205.214.160.42]) by proper.com (8.8.7/8.7.3) with SMTP id VAA20495; Sat, 22 Nov 1997 21:44:28 -0800 (PST) Message-Id: <199711230544.VAA20495@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Sat, 22 Nov 1997 21:46:23 -0800 To: Lindsay Mathieson From: Dave Crocker / IMC Subject: Re: The case against redundancy and isolation Cc: Ian Brown , IETF OpenPGP In-Reply-To: <199711230251.SAA13117@mail.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:43 AM 11/23/97 +0000, Lindsay Mathieson wrote: >>From your points (not quoted) I would assume you prefer the option of >basically ignoring the Armour issue - leave it documented and as a MAY. I >would prefer that myself. It keeps the spec simple and fast out the door. It is unlikely that the work of the group with be either useful or acceptable if it ignores specification of at least one "transport" environment, such as for email or the web. The reason for pressing the point about full and legitimate integration with MIME is that it takes care of at least two major Internet application environments at the same time. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA13818 for ietf-open-pgp-bks; Sat, 22 Nov 1997 20:55:16 -0800 (PST) Received: from dfw-ix13.ix.netcom.com (dfw-ix13.ix.netcom.com [206.214.98.13]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA13814 for ; Sat, 22 Nov 1997 20:55:12 -0800 (PST) Received: (from smap@localhost) by dfw-ix13.ix.netcom.com (8.8.4/8.8.4) id WAA16484; Sat, 22 Nov 1997 22:55:41 -0600 (CST) Received: from pax-ca14-15.ix.netcom.com(204.31.233.79) by dfw-ix13.ix.netcom.com via smap (V1.3) id rma016409; Sat Nov 22 22:54:06 1997 Message-Id: <3.0.3.32.19971122205401.006f5508@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sat, 22 Nov 1997 20:54:01 -0800 To: ietf-open-pgp@imc.org, jon@pgp.com From: Bill Stewart Subject: Re: CMR as an extension _inside_ the standard (Re: CMR & ROT-13) Cc: Adam Back , iang@systemics.com In-Reply-To: <199711222216.WAA02916@server.test.net> References: <3475709B.52A5DC4@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> That leaves us with the fourth option. Say nothing and do not document it. >> This of course will be problematic for programmers, as they test their >> code against 5.x, and discover the strange packets. It may be that it doesn't cause a problem. Jon's done a great job on the standard - I still find it hard to read, partly because it's bottom-up rather than top-down, which makes it easier to follow syntax and harder to follow semantics, and partly because there's just a _lot_ of detail, and the newer features are pretty complex. But if I do understand what's going on, the CMR support is just one entry in a table that's needed anyway, plus a paragraph of apologies (:-), and may be the primary motivation for one other feature. If I can modifiy Jon's syntax description a bit: A Packet is a record containing the following in a tersely encoded format (:-) Packet Tag - indicates packet type, 0-15 (old) or 0-63 (new) Packet Length - optionally indeterminate Packet Body - format and semantics depend on Packet Tag A Transferable Key Packet probably has Public Key syntax Packet Tag = 6? A Transferable Key Packet has One Public Key Packet Zero or more revocation signatures One or more User-ID-With-Optional-Signatures entities Zero or more Subkey-With-Signature entities ["entity" isn't a PGP Packet format, it's a group of packets I've defined for increased syntactical precision] A User-ID-With-Optional-Signatures entity is One UserID Packet Zero or more Signature_Packets [Semantics: These signature packets each sign the concatenation of the public key, the user id, and signature info.] A Subkey-With-Signature entity is One Subkey Packet Maybe[??] zero or more subkey revocation packets[??] One or more Signature_Packets [Semantics: These signature packets each sign the concatenation of the public key, the subkey, and signature info.] A Signature_Packet is a packet with PacketTag=2, either Version 3 or Version 4 Signature Packet Format A Version 4 Signature Packet contains Version Number (octet = 4) Signature Type (octet - e.g. binary, text, several keycerts, revocations) Public Key Algorithm (octet - e.g. RSA, DSA, EG, ...) Hash Algorithm (octet - e.g. SHA-1, MD5, RIPEMD-160, ...) Octet Count for following hashed subpacket data (2 octets, weird format) Subpacket_Data_Entity - gets hashed Octet Count for following unhashed subpacket data (2 octets, weird format) Subpacket_Data_Entity - doesn't get hashed Left-16-bits-of-signed-hash-value Field - for checking success Signature - Algorithm-specific collection of multi-precision integers A Subpacket_Data_Entity - [My term. Draft section 5.2.2.1] Length-Of-Subpacket-Set (two octets, probably packed format?) Zero or More Subpackets A Subpacket - [!!! FINALLY - THE FUN PART !!!] Subpacket Length - (packed, one or two octets) Subpacket Type-And-Criticality-Indicator - Octet Subpacket Body - format is Subpacket Type dependent. A Subpacket-Type-And-Criticality-Indicator Octet Bits 0-6 - Subpacket Type, an entry from a table including 2 - signature creation time [And a bunch of similar good entries] 4 - exportable [This isn't ITAR - this indicates whether the signature can be transmitted to other people or is for your own use only. So don't panic :-)] 10 - The Infamous Additional Recipient Request 16 - Issuer KeyID - Sounds Ominous and Not documented! 12 - Revocation Key - Only for self-signatures(??) so you can revoke your key after losing your key 21 - Preferred hash algorithms 22 - Preferred compression algorithms 23 - key server preferences 24 - preferred key server - presumably the Signer's preference for finding further data about the Signer's key? Bit 7 - Criticality Bit - [Semantics: I don't quite understand it? Reject Key If you don't support the Subpacket Type, or reject the signature rather than the whole key?] So the Infamous Additional Recipient Request is just a subpacket of known length, in a table of zero or more extension-like subpackets, and the description of the Criticality Bit seems to imply that it's ok to have subpacket types that aren't recognized and can be skipped over because their lengths are known. So that's the good news. The bad news is that, while the Criticality Bit is only sketchily documented, it sounds like part of a CMRist plot, to make use of the ARR mandatory if the recipient requests it (there _is_ the semantics issue of what the program should do if it understands the Additional Recipient Request and doesn't feel like cooperating :-) The ugly news is that Additional Recipient Requests are a really weird thing to attach to a signature, rather than part of the key itself - I suppose that makes it easier for the Corporate Security Bureaucrats to request, rather than having some special case part of the key generation, which would be uglier, but it's still a strange place to put it. But in conjunction with the Criticality Bit, this extension method is a Denial Of Service Attack - unless I'm misunderstanding the bit, if the bit is set and the subpacket type is unrecognized, the recipient is supposed to reject the entire key packet and not just the signature packet - does this mean that somebody can sign your key with a Critically Bogus Subpacket and prevent anybody from using your key? (e.g. by signing a keyserver key...) Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA13121 for ietf-open-pgp-bks; Sat, 22 Nov 1997 18:51:58 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id SAA13117 for ; Sat, 22 Nov 1997 18:51:53 -0800 (PST) Message-Id: <199711230251.SAA13117@mail.proper.com> Received: (qmail 19518 invoked from network); 23 Nov 1997 02:52:51 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 23 Nov 1997 02:52:51 -0000 Date: 23 Nov 1997 3:43:17 GMT From: Lindsay Mathieson Subject: Re: The case against redundancy and isolation To: Ian Brown , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >As Dave said, I think this argument is just going round in circles >now. >We seem to have clarified at least some points. I believe none of the >following is contentious: >From your points (not quoted) I would assume you prefer the option of basically ignoring the Armour issue - leave it documented and as a MAY. I would prefer that myself. It keeps the spec simple and fast out the door. We are in danger of getting into discussion on how PGP objects are transported, which I believe is best left to other groups/specs. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 23, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12970 for ietf-open-pgp-bks; Sat, 22 Nov 1997 18:23:45 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12966 for ; Sat, 22 Nov 1997 18:23:39 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id NAA26709; Sun, 23 Nov 1997 13:23:13 +1100 Received: from shirley (dformosa@dialin-32 [137.154.130.32]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id NAA17809; Sun, 23 Nov 1997 13:23:11 +1100 (EST) Date: Sun, 23 Nov 1997 12:08:06 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Ian Grigg cc: ietf-open-pgp@imc.org Subject: Re: CMR & ROT-13 (Re: Draft comments) In-Reply-To: <3475709B.52A5DC4@systemics.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 21 Nov 1997, Ian Grigg wrote: [...] > > > 6.2 - I know the inclusion of ROT-n started as a joke - but it's in > > > there! Eeeek! > > > > I thought Jon was joking about these! Remove at once please! > > Yes, there should be no weakness. I know ROT-n is a joke to some, but > if Caeser used it, then so can others. If a test case is needed, it > should be plain and open. Not that I think one is. I too can see a need for something like ROT-n for testinng. As PGP is not just an encytion system but also has key manigment, signing ascii armore ect it would be usefull to be able to sepreate off one part of the system with know working code. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHeB/KQK0ynCmdStAQFrZQP/avok50mrjjFUcltV8lMTAPnRcE2Rxe/S pebEWgX5Wd9Pf+gwLu4581ZAlWQ7eDLu6VtMFFw9J8rf2JBNvVEhIBBMW2O54bqC j2kTDivKDZmiy9QgnOhmsrbzBFHiTxELfqDiF5p0uGhe1+4MPZ+5I4rf9aF2eBu9 RxZwSMt2nvM= =3fO0 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12890 for ietf-open-pgp-bks; Sat, 22 Nov 1997 18:11:19 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12884 for ; Sat, 22 Nov 1997 18:11:12 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id NAA26668; Sun, 23 Nov 1997 13:10:45 +1100 Received: from shirley (dformosa@dialin-32 [137.154.130.32]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id NAA17582; Sun, 23 Nov 1997 13:10:42 +1100 (EST) Date: Sun, 23 Nov 1997 11:55:37 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Alex Le Heux cc: ietf-open-pgp@imc.org Subject: Re: Ancient Technology In-Reply-To: <3.0.3.32.19971121123331.0095add0@mail.xs4all.nl> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 21 Nov 1997, Alex Le Heux wrote: > In an ever faster changing world of computers regular users of PGP > seem to be very reluctant to change anything. Securaty applications tend to encourage a conservative[1] viewpoint even when the person is noramly quite open to cahnge. This is most likly a good thing. [...] > Of course there is a strong case for continuing support for AA > (backwards compatibility and all that), but the new standard should > not be based on it. It's ancient technology. But as I understand this is _not_ a new standard. It is the documentation of an existing standard. So it is neccery to retain backwards capasity with pgp itself. [1] Conservitive as meaning unwilling to change. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHd/D6QK0ynCmdStAQEWEAQAnf0PtjRRawDHmSzd/jh+KQ5cRu7HlpXP OtNNoEXweqhGyTYCWh+PRgP+hdh86mOE+zGLjzk7fbyD19JENV9ju03YyyNlYH+A oLEIJRCaE2K+UTwC7+6tyE9uPdiiDGDqTVAKmuq3xu6sK8OspeK4ZwEkCkmDhstu OebaaRNMTOg= =rdbI -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA12449 for ietf-open-pgp-bks; Sat, 22 Nov 1997 17:23:08 -0800 (PST) Received: from mail-gw.pacbell.net (mail-gw.pacbell.net [206.13.28.25]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA12445 for ; Sat, 22 Nov 1997 17:23:04 -0800 (PST) Received: from a (ppp-207-104-64-177.psdn11.pacbell.net [207.104.64.177]) by mail-gw.pacbell.net (8.8.8/8.7.1+antispam) with SMTP id RAA13859 for ; Sat, 22 Nov 1997 17:24:06 -0800 (PST) Message-ID: <3477852F.40C@pacbell.net> Date: Sat, 22 Nov 1997 17:21:51 -0800 From: Gary Liu Reply-To: garygliu@pacbell.net X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: Why Rabin algorithm has mostly been ignored? References: <3.0.3.32.19971121170210.00a3b510@mail.pgp.com> <3.0.3.32.19971121172420.00bd2330@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas wrote: > It's in there now. Obviously, there needs to be more discussion of what > kind of Rabin you want, straight Rabin, Williams's variants, or what. > Please bring this up on the list. Jon, thanks for putting it in. I think the Rabin algorithm may use the following specifics, which can be found in "Handbook of Applied Cryptography" by Alfred J. Menezes, Paul C. van Oorschot and Scott A. Vanstone. 1) In key generation, generate two primes p and q such that p=3 mod 8 and q=7 mod 8. The public key is simply n=p*q and the private key is p and q. Quantities a, b satisfying a*p+b*q=1 and d=(n-p-q+5)/8 may also be calculated at the stage of key generation and stored as private key data (to simplify decryption and signature generation calculations). 2) Encryption: c=m**2 mod n. Note: It is necessary to have some salt and redundancy in m. Since m is at least 512 bits and the symetric key is something around 128 bit, there is plenty of room to put redundancy and salt in ESK. At this time, it is probably sufficient to specify that the first octet of m signifies the salting and redundancy scheme. (Redundancy will prevent the chosen ciphertext attack mentioned by Hal Finney.) 3) Decryption: compute the four square roots of c. r=c**((p+1)/4) mod p s=c**((q+1)/4) mod q x=(a*p*s + b*q*r) mod n y=(a*p*s - b*q*r) mod n where a and b are intergers satisfying a*p+b*q=1. Then use the redundancy information in m to determine which of r,s,x,and y is the decrypted message m. 4) Signature generation: (a) Compute m1=R(m) where R(m) is the redundancy function specified by ISO/IEC-9796. Note: This ensures that m1=6 mod 16. (b) Compute Jacobi symbol J=(m1,n). (c) If J=1 then the signature is s=m1**d mod n. (d) If J=-1 then the signature is s=(m1/2)**d mod n. 5) Signature verification: (a) Compute m2=s**2 mod n. (b) If m2=6 mod 8 take m1=m2. (c) If m2=3 mod 8 take m1=2*m2. (d) If m2=7 mod 8 take m1=n-m2. (e) If m2=2 mod 8 take m1=2*(n-m2). (f) Verify that m1 has the correct format specified in ISO/IEC-9796. (g) Recover signed message m=Rinv(m1), where Rinv is the inverse function of R. I think the above Rabin scheme is pretty neat. It does not double the ciphertext as ElGamal does. It is extremely fast in encryption and verification. Althogh the decryption and signature generation is slightly more complicated than RSA, the complication is not in the computation intensive part, and therefore, does not affect the efficiency of the algorithm. I have implemented the above algorithm without much difficulty and found that the decryption and signature generation are just as fast as RSA but the encryption and verification are much faster. The above may be the scheme you call "straight Rabin". we probably should also reserve a number for Williams's variant, which takes modular cube instead of modular square. Gary Liu Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA11594 for ietf-open-pgp-bks; Sat, 22 Nov 1997 15:03:56 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA11589 for ; Sat, 22 Nov 1997 15:03:52 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id BAA23361; Sun, 23 Nov 1997 01:32:17 +0100 (MET) Message-ID: <347765A7.790D4278@systemics.com> Date: Sat, 22 Nov 1997 23:07:19 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Adam Back CC: ietf-open-pgp@imc.org Subject: Re: CMR as an extension outside the standard (Re: CMR & ROT-13) References: <199711222216.WAA02916@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > > This of course will be problematic for programmers, as they test their > > code against 5.x, and discover the strange packets. > > This problem highlights the usefulness of the extension mechanism Jon > Callas described briefly. If PGP implements controversial extensions > as extensions, the compatibility problem vanishes -- implementations > which don't have the extension coded already have a defined way to > safely ignore it. I agree that it would be nice to have a defined extension mechanism. There are lots of things one could do with the PGP infrastructure if one had the time, and a decent way of adding some extra features. My normal rule is "no change" and I've pushed that on many occasions here. That's probably because I'm old and tired and have been on the business end of many a programmer's last minute addition. They are usually simple in the mind of the proposer and a nightmare, or worse, for everybody else down the chain of software deployment. However, given the trauma caused by the CMR feature and the likely cost to the credibility of the standard if this goes in, I think a change is needed here. The addition of the extension mechanism would (as a MAY to provide and a MAY to ignore and a SHOULD or MUST to not blow up) might be sufficient to provide the flexibility to replace the CMRK, for those who have decided it is a good thing. > > I don't however see this as a problem, as there is little to stop > > PGP Inc from publishing a separate document which can become known. > > As the programmers are coding up the pgp code, and as this feature > > is only used by PGP Inc code, they know where to ask. > > I'd sooner discourage them also from using the CMR feature at all, due > to the security risks, and negative political aspects. However, if > they insist, it's their reputation, but I would think a good way to > implement it would be to implement it using the extension mechanism. Well, it is not up to the IETF or anyone to stop any company from shooting itself in the corporate foot. The standard should be neutral on that, and not try and discourage such and such a feature. OTOH, it should definately not leave the way open for generations of programmers to copy footwear ventilation features into their code. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA11292 for ietf-open-pgp-bks; Sat, 22 Nov 1997 14:26:47 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA11288 for ; Sat, 22 Nov 1997 14:26:42 -0800 (PST) Received: from server.test.net ([194.168.59.4]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA11024; Sat, 22 Nov 1997 22:27:24 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id WAA02916; Sat, 22 Nov 1997 22:16:22 GMT Date: Sat, 22 Nov 1997 22:16:22 GMT Message-Id: <199711222216.WAA02916@server.test.net> From: Adam Back To: iang@systemics.com CC: ietf-open-pgp@imc.org In-reply-to: <3475709B.52A5DC4@systemics.com> (message from Ian Grigg on Fri, 21 Nov 1997 11:29:31 +0000) Subject: CMR as an extension outside the standard (Re: CMR & ROT-13) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Grigg writes: > [about ARR/CMR] > > That leaves us with the fourth option. Say nothing and do not document > it. > > This of course will be problematic for programmers, as they test their > code against 5.x, and discover the strange packets. This problem highlights the usefulness of the extension mechanism Jon Callas described briefly. If PGP implements controversial extensions as extensions, the compatibility problem vanishes -- implementations which don't have the extension coded already have a defined way to safely ignore it. > I don't however see this as a problem, as there is little to stop > PGP Inc from publishing a separate document which can become known. > As the programmers are coding up the pgp code, and as this feature > is only used by PGP Inc code, they know where to ask. I'd sooner discourage them also from using the CMR feature at all, due to the security risks, and negative political aspects. However, if they insist, it's their reputation, but I would think a good way to implement it would be to implement it using the extension mechanism. > Or, we can simply say nothing and leave the feature as a new, untried > idea by one commercial venture in the marketplace for Open PGP product. Absolutely. Also they should implement it within the extension frameworks so that they do not introduce compatibility problems. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08127 for ietf-open-pgp-bks; Sat, 22 Nov 1997 09:07:03 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08121 for ; Sat, 22 Nov 1997 09:06:55 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id JAA06567; Sat, 22 Nov 1997 09:10:36 -0800 Date: Sat, 22 Nov 1997 09:10:36 -0800 Message-Id: <199711221710.JAA06567@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Ian Brown Cc: IETF OpenPGP Subject: Re: The case against redundancy and isolation In-Reply-To: <3476F29C.F3ADAD0C@cs.ucl.ac.uk> References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Ian Brown writes: > As Dave said, I think this argument is just going round in circles now. > We seem to have clarified at least some points. I believe none of the > following is contentious: Indeed, so I'll go 'round once more :-) > > 1. We should not MUST MIME *or* Armour. Both increase the amount of code > needed for a minimal implementation, which none of us want. As Dave > said, linearly increased code increases exponentially the potential for > errors. We differ in opinion here, but so be it. I agree MIME should not be a MUST, but I believe Armor should be a MUST. > > 2. We are not trying to eliminate Armour. It is entirely appropriate > that it should be in there as an option to provide backward > compatibility, if implementors so wish. > > 3. Both systems are for converting fully secure binary PGP data into a > form which can be safely stored in/sent across 7-bit systems. Mail is > such a system. Armour/MIME does nothing for security. As Dave and Jon > have both said, OP is NOT a mail standard. It is a security standard. > 7-bit conversion should therefore not be a MUST. As Lindsay Mathieson > said, we can safely assume most file systems can cope with 8-bit > data. I'll disagree one last time with this. No, Armor doesn't effect the security of PGP itself, but it does affect how OP products will or can be used in the "real world" and therefore affects the "level of security provided by" the PGP system. (if noone used PGP, PGP is still secure, but the system is not because it isn't used). 7-bit conversion is fundamental to the viability of a tool like PGP, and is therefore not external to defining OP. > > Jeremey Barrett wrote: > > > As Jon pointed out, PGP is not email software, there are a host > > of other applications for PGP, which might well benefit (and do) > > from ASCII armor. > > The only way these applications will benefit from armor is if they need > to send data across a 7-bit system. Everywhere else can store objects in > their original 8-bit format. Agreed. I find myself doing this quite regularly. > > > My point is that _requiring_ MIME eliminates a set of users. That's > > all. Eliminating users decreases the security of the system, because > > less people have the necessary tools. If security is the goal (and > > as I read the wg charter, "The whole purpose of Open-PGP is to provide > > security services") then the elimination of ASCII armor is > > contradictory to the goals of the wg, IMO. It should be a MUST. > > If we follow this logic, RSA and IDEA should be a MUST. We eliminate far > more users by not specifying this than by not making armor > compulsory. Perhaps true, but not in the same sense. It is reasonably easy to go get a new version of PGP which doesn't use RSA or IDEA, or doesn't default to them. You don't have to change the way you "do things" to switch to ElGamal and CAST. MIME is different, because it is external to PGP. > > > I thought we were discussing PGP, not email. Last time I checked noone > > has implemented file encryption, or encrypted archiving tools, or > > remailers, or keyservers, or nym servers, or anything other than > > email (and on occasion news) using MIME. Nor should they. > > That's right. Armor is used in systems that use 7-bit mail systems as > their transport mechanism. Therefore, Armor is only relevant if we are > discussing PGP as an e-mail standard. You are arguing against yourself > here. It is only relevant in the case of any 7-bit transport, yes. (be that email or news or what-have-you). My point is that the capacity for 7-bit encoding is critical to PGP, and all OP-compliant products should provide it regardless of what other 7-bit transport schemes are supported. Relying on the existence of an external infrastructure (MIME) for the simple ability to send OP messages over 7-bit transport mechanisms is not sound, as Rodney said. And since ASCII armor 1) already exists, 2) is widely used, and 3) is quite trivial to implement, it is the logical choice for built-in 7-bit support. > > File encryption and archiving tools can support 8-bit data. They do not > require armor. Remailers are using mail transport. The main reason > keyservers use armor is that they originally used mail transport. It > would be just as appropriate, and faster, for the Web/LDAP-based systems > to transfer keys as binary data. See http://solo.dc3.com/pks/kfmts.html > for one that allows this. The idea that we should reimplement all the existing PGP infrastructure in the name of 'standards' is hogwash. I don't have LDAP in my mail reader. Neither does anyone else, with the exception of Netscape and Micro$oft users. Supporting all those things is great, but removing the simple functionality of PGP in favor of increasingly complex and difficult protocols and software is not a step in the right direction. Anyway... the horse is dead. Regards, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHcR7C/fy+vkqMxNAQGLJQP/UbBBh2sNb0cVuyeLrIUZn1rcZ5VMbx8Y T1UYXTDNRDYAKQxI7ha9CB5BEdCuVxv+sfMrb4yIrZTaLKZyyUma5KwhghsqnhUI 8/eDicoVu/0DuGOArUI9fFBHRWF/YVIql4sTgXHh4/K8aS9hGgMXMHe0wy5zb/CK mRg1v8URXp4= =uvi4 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA07807 for ietf-open-pgp-bks; Sat, 22 Nov 1997 08:25:54 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA07803 for ; Sat, 22 Nov 1997 08:25:48 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id IAA24203 for ietf-open-pgp@imc.org; Sat, 22 Nov 1997 08:24:31 -0800 Message-ID: <19971122082429.54506@songbird.com> Date: Sat, 22 Nov 1997 08:24:29 -0800 From: Kent Crispin To: IETF OpenPGP Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3476F29C.F3ADAD0C@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <3476F29C.F3ADAD0C@cs.ucl.ac.uk>; from Ian Brown on Sat, Nov 22, 1997 at 02:56:28PM +0000 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Sat, Nov 22, 1997 at 02:56:28PM +0000, Ian Brown wrote: > As Dave said, I think this argument is just going round in circles now. > We seem to have clarified at least some points. I believe none of the > following is contentious: > > 1. We should not MUST MIME *or* Armour. Both increase the amount of code > needed for a minimal implementation, which none of us want. As Dave > said, linearly increased code increases exponentially the potential for > errors. > > 2. We are not trying to eliminate Armour. It is entirely appropriate > that it should be in there as an option to provide backward > compatibility, if implementors so wish. > > 3. Both systems are for converting fully secure binary PGP data into a > form which can be safely stored in/sent across 7-bit systems. Mail is > such a system. Armour/MIME does nothing for security. As Dave and Jon > have both said, OP is NOT a mail standard. It is a security standard. > 7-bit conversion should therefore not be a MUST. As Lindsay Mathieson > said, we can safely assume most file systems can cope with 8-bit data. All sounds good to me... -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA07790 for ietf-open-pgp-bks; Sat, 22 Nov 1997 08:23:50 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA07786 for ; Sat, 22 Nov 1997 08:23:45 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id IAA24175 for ietf-open-pgp@imc.org; Sat, 22 Nov 1997 08:22:28 -0800 Message-ID: <19971122082227.16707@songbird.com> Date: Sat, 22 Nov 1997 08:22:27 -0800 From: Kent Crispin To: ietf-open-pgp@imc.org Subject: Re: The case against redundancy and isolation References: <19971120184831.17558@sobolev.rhein.de> <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> <3.0.3.32.19971121131410.0335c230@mail.communities.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <3.0.3.32.19971121131410.0335c230@mail.communities.com>; from Jim McCoy on Fri, Nov 21, 1997 at 01:14:10PM -0800 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, Nov 21, 1997 at 01:14:10PM -0800, Jim McCoy wrote: > I hate to burst the bubble of everyone at PGP, Inc. but right now and > for the forseeable future PGP is _only_ email. It is not for general > purpose encryption because in those cases people use toolkits that do > not carry around as much bogus baggage as PGP does (like Ascii > Armoring for example...) I beg to differ. When I encrypt a file (which I do on occasion) PGP is the tool of choice. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA07130 for ietf-open-pgp-bks; Sat, 22 Nov 1997 07:08:57 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA07126 for ; Sat, 22 Nov 1997 07:08:52 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 22 Nov 1997 15:09:45 +0000 Message-ID: <3476F4FB.F1145AC3@cs.ucl.ac.uk> Date: Sat, 22 Nov 1997 15:06:35 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Kent Crispin CC: IETF OpenPGP Subject: Re: CMR References: <34755C2E.4219D908@cs.ucl.ac.uk> <19971121225734.06956@songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Black Unicorn wrote: > Which is why, as part of a general document destruction and retention > policy, you cycle the CMR key every year (or other period), securely delete > the old secret key, and thus kill all the "tobacco memos." The problem with this, as Adam and others have pointed out, is that you have different storage requirements for different types of material. Regulatory bodies may require certain materials to be stored for say 7 years. Other types of material may need to be securely wiped ASAP. This means that you need different CMR keys for different purposes. But how do you implement this properly using CMR? Say I work for such a company. Which CMR request should be on my general-purpose public key? Kent Crispin wrote: > Of couse, this is a problem intrinsic to either CMR or CKE. You are in > precisely the same trouble with key escrow -- they save the mail, then > demand the escrowed key via court order. You're right, if it is simple CKE. However, following Adam's GAK-resistant design principles, the escrow should be done as close to the user as possible. So to take Microsoft's example: these dynamite messages should have ONLY been encrypted to the message recipient. Once the recipient received and decrypted the message, if it was necessary to store it, they would then encrypt it with the company escrow key. This escrowed storage copy would remain physically inside the organisation - no competitor or regulatory body could have intercepted and stored a copy. If the organisation wished to securely wipe the data, it could do so knowing that no-one else could have intercepted the copy. And since the recipient used Forward Secrecy ;-), by the time the courts came to demand the recipient's private key so they can decrypt their intercepted and stored message, said private key would have been long ago securely wiped. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA07024 for ietf-open-pgp-bks; Sat, 22 Nov 1997 06:58:55 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA07016 for ; Sat, 22 Nov 1997 06:58:50 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 22 Nov 1997 14:59:38 +0000 Message-ID: <3476F29C.F3ADAD0C@cs.ucl.ac.uk> Date: Sat, 22 Nov 1997 14:56:28 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jeremey Barrett CC: IETF OpenPGP , rdenny@dc3.com Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> <199711211820.KAA04398@einstein.bluemoney.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk As Dave said, I think this argument is just going round in circles now. We seem to have clarified at least some points. I believe none of the following is contentious: 1. We should not MUST MIME *or* Armour. Both increase the amount of code needed for a minimal implementation, which none of us want. As Dave said, linearly increased code increases exponentially the potential for errors. 2. We are not trying to eliminate Armour. It is entirely appropriate that it should be in there as an option to provide backward compatibility, if implementors so wish. 3. Both systems are for converting fully secure binary PGP data into a form which can be safely stored in/sent across 7-bit systems. Mail is such a system. Armour/MIME does nothing for security. As Dave and Jon have both said, OP is NOT a mail standard. It is a security standard. 7-bit conversion should therefore not be a MUST. As Lindsay Mathieson said, we can safely assume most file systems can cope with 8-bit data. Jeremey Barrett wrote: > As Jon pointed out, PGP is not email software, there are a host > of other applications for PGP, which might well benefit (and do) > from ASCII armor. The only way these applications will benefit from armor is if they need to send data across a 7-bit system. Everywhere else can store objects in their original 8-bit format. > My point is that _requiring_ MIME eliminates a set of users. That's > all. Eliminating users decreases the security of the system, because > less people have the necessary tools. If security is the goal (and > as I read the wg charter, "The whole purpose of Open-PGP is to provide > security services") then the elimination of ASCII armor is > contradictory to the goals of the wg, IMO. It should be a MUST. If we follow this logic, RSA and IDEA should be a MUST. We eliminate far more users by not specifying this than by not making armor compulsory. > I thought we were discussing PGP, not email. Last time I checked noone > has implemented file encryption, or encrypted archiving tools, or > remailers, or keyservers, or nym servers, or anything other than > email (and on occasion news) using MIME. Nor should they. That's right. Armor is used in systems that use 7-bit mail systems as their transport mechanism. Therefore, Armor is only relevant if we are discussing PGP as an e-mail standard. You are arguing against yourself here. File encryption and archiving tools can support 8-bit data. They do not require armor. Remailers are using mail transport. The main reason keyservers use armor is that they originally used mail transport. It would be just as appropriate, and faster, for the Web/LDAP-based systems to transfer keys as binary data. See http://solo.dc3.com/pks/kfmts.html for one that allows this. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA03174 for ietf-open-pgp-bks; Sat, 22 Nov 1997 01:53:37 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA03170 for ; Sat, 22 Nov 1997 01:53:29 -0800 (PST) Received: from server.test.net ([194.168.63.63]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA7013; Sat, 22 Nov 1997 09:54:23 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id JAA00200; Sat, 22 Nov 1997 09:53:17 GMT Date: Sat, 22 Nov 1997 09:53:17 GMT Message-Id: <199711220953.JAA00200@server.test.net> From: Adam Back To: jon@pgp.com CC: I.Brown@cs.ucl.ac.uk, dpkemp@missi.ncsc.mil, ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971121105638.00ba5100@mail.pgp.com> (message from Jon Callas on Fri, 21 Nov 1997 10:56:38 -0800) Subject: Re: CMR Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: > At 04:20 PM 11/21/97 +0000, Ian Brown wrote: > > No, I don't. But as PGP Inc are pushing CMR as a corporate solution > which gives the ability to snoop on employees' e-mail, I just wanted to > point out one of the negative consequences for such unethical companies > ;-) > > We are doing no such thing. Could we have some clarification on what purpose PGP is pushing the CMR feature for. Lots of disclaimers about what it's not for: but what _is_ it for? The fact that it is currently in the draft I think entitles the WG to some kind of explanation. PGP might not be pushing CMR for the purpose of allowing corporate snooping; but that is what the CMR design is ideal for. We already went through the process of showing that recovering from lost passphrases is better achieved with local escrow. CMR doesn't acheive it's stated purpose, weakens security, and is politically dangerous to boot. David Kemp was arguing for snooping: > So you accept it as a given that shredding evidence is appropriate > and desirable behavior in a free society? Yes. This is what Phil Zimmermann designed the pgp -w option is for: to shred files. Communications and storage security is all about denying third party access to communications and storage. What better way to deny access of communications than to destroy them after reading. This is what the pgp -m option is for: to discourage the recipient from storing in plaintext. > Even if said shredding is conducted by the White House (or #10 > Downing Street)? Everything cuts two ways. Next thing you'll be telling us sending messages the government can't read "isn't appropriate and desirable behaviour in a free society". When Phil Zimmermann spoke at the Privacy International organised conference in London he made the point that he hoped the new Labour government would not forget the wire taps and snooping they had been subjected to by GCHQ on the behalf of the Tory government prior to winning the election. He hoped they would remember these lessons, and avoid government key escrow. PGP Inc is firmly against government key escrow. The name PGP must _never_ become associated with untoward backdoors. Companies have a perfectly legitimate need to "shred" their data after it is no longer needed by them. Saying that individuals or companies must keep records to enable others to incriminate them is prior restraint. Some companies are required to keep various records for periods of time. There is no obligation to keep records after these stipulated times, and many company communications are not kept at all, by design. To do otherwise would be fool hardy. Tim May, an ex-Intel engineer, gave the example that they had a policy of purging old notes, papers, periodically. He considered the purpose of this to prevent discovery processes. It is dangerous for companies to keep around old communications which they no longer need. Ian posted another example. Why do you think companies have paper shredders? Companies legal departments set policies for records keeping; several people who have spent much time in corporate environments gave examples of destroying old records. The motive is obvious: to minimise information available in a discovery processes, such as Microsoft is enduring now. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA02204 for ietf-open-pgp-bks; Fri, 21 Nov 1997 23:13:48 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id XAA02198 for ; Fri, 21 Nov 1997 23:13:41 -0800 (PST) Message-Id: <199711220713.XAA02198@mail.proper.com> Received: (qmail 25306 invoked from network); 22 Nov 1997 07:14:37 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 22 Nov 1997 07:14:37 -0000 Date: 22 Nov 1997 8:5:9 GMT From: Lindsay Mathieson Subject: Re: Armour To: Dave Crocker / IMC , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >>In particular, what format would MIME leave encrypted files on disk >so >>my above simple archaic email example would work? How well does >MIME >>work with stored objects? How does the MIME standard actually deal >with >>stored objects? Another point - pgp 2.6.x is quite capable of generating & decoding 8 bit binary objects for storage on disk, and I believe we can safely assume most file systems can cope with 8 bit data -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 22, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA02091 for ietf-open-pgp-bks; Fri, 21 Nov 1997 22:58:57 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA02087 for ; Fri, 21 Nov 1997 22:58:53 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id WAA19534 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 22:57:36 -0800 Message-ID: <19971121225734.06956@songbird.com> Date: Fri, 21 Nov 1997 22:57:34 -0800 From: Kent Crispin To: IETF OpenPGP Subject: Re: CMR References: <34755C2E.4219D908@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <34755C2E.4219D908@cs.ucl.ac.uk>; from Ian Brown on Fri, Nov 21, 1997 at 10:02:22AM +0000 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, Nov 21, 1997 at 10:02:22AM +0000, Ian Brown wrote: > Several people have made the point that, while companies may wish to be > able to recover some stored e-mail, they most definitely do NOT want > other items to be recoverable in the case of court demands that material > be handed over. Microsoft is providing a prime example of this right > now. The Department of Justice is using, to great effect, internal > Microsoft e-mail to show that they did not originally intend to > integrate Internet Explorer with Windows. > [...] > > Your company may take great steps to securely delete such sensitive > mail. If it has already travelled over an insecure network, it could be > intercepted and stored by a competitor. Encryption will prevent them > reading it then. But what if they get a court order demanding you hand > over your Corporate Message Recovery Key? If all your mail is also > encrypted to this CMRK, you're in trouble. Of couse, this is a problem intrinsic to either CMR or CKE. You are in precisely the same trouble with key escrow -- they save the mail, then demand the escrowed key via court order. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA02029 for ietf-open-pgp-bks; Fri, 21 Nov 1997 22:49:00 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA02024 for ; Fri, 21 Nov 1997 22:48:50 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id WAA19429 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 22:47:33 -0800 Message-ID: <19971121224730.57104@songbird.com> Date: Fri, 21 Nov 1997 22:47:30 -0800 From: Kent Crispin To: ietf-open-pgp@imc.org Subject: Re: Armour References: <199711212133.NAA17838@proper.com> <3.0.3.32.19971120173237.00b93640@mail.pgp.com> <9711211516.AA67240@watpub1.watson.ibm.com> <199711212133.NAA17838@proper.com> <19971121164757.06784@songbird.com> <199711220521.VAA18301@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199711220521.VAA18301@proper.com>; from Dave Crocker / IMC on Fri, Nov 21, 1997 at 09:05:21PM -0800 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, Nov 21, 1997 at 09:05:21PM -0800, Dave Crocker / IMC wrote: > Kent, > > Well, how about this? Opposite sides of the fence... Not really -- I don't have a position on this. But it seems that it's being debated as a religious issue, rather than a technical one. That is, you assert that mime solves the full pgp problem domain; others assert that there are areas that mime doesn't address. You seem to be taking the tack that these individuals are reacting in a patently reactionary mode, and express a lot of frustration over it. There is a real possiblity that you indeed *are* dealing with purely reactionary thinking. But there is also the possibility that "the other side" has a valid intuition that they aren't expressing well, or that you just aren't hearing -- they aren't dumb, you know. If there are valid reasons for ascii armor, then it would be good if they are brought out. > At 04:47 PM 11/21/97 -0800, Kent Crispin wrote: > > It is quite possible that > >"simple" mailers will persist for another 10 or more years. > > This is certain to be true, but is a likelihood which needs to be used > carefully. For example, why project that the MUA will be unchanged but > that fancy new encryption sofware will be added? I'm not thinking that fancy new encryption technology will be added. Someone could produce a standard compliant simple OP application next year, and it could be in use for another 10 years. > More importantly, why > jerk the standards specification around to accomodate that particular > scenario? Why do you view it as "jerking around"? It is a completely valid thing for a standard to codify an existing practice, is it not? > If they want new security technology, why is it unreasonable to > require that relevant additional capabilities be added. There's an "if" there. I'm not sure that the sole purpose of the standard is to define "new security technology". [...] > >The claim is that PGP has uses independent of the net [so IETF > >standardization?] -- that is, independent of the problem of > >transmitting data securely over the net; and it really may be that > > The IETF does interchange standards, not file standards. Indeed. But half the functionality of PGP has to do with files, not interchange. If I encrypt something on disk, that's not an interchange. That something may be transported by ftp, or kermit, or any number of ad hoc transfer protocols, instead of smtp or http. > >MIME is not the best way to support *those* uses. > > The sun might not come up tomorrow, to. "Might" is a mighty weak approach > to debating technical choices. If there is a specific problem with MIME > for specific situations, let's hear about them and look at them. I believe that Hal Finney did just post a lengthy post on this very topic. > Across the many messages on this topic, the arguments for retaining > amouring seem to be using cases which are irrelevant to IETF work, ^^^^^^^^^^^^^^^^^^^^^^^ This is precisely the point of my bracketed comment above -- some parts of pgp *are* irrelevant to IETF work, I believe. But they are *important* parts of pgp. It may well be that an IETF standard is inappropraite for pgp -- file security is a vital component of pgp, I don't see the IETF relevance, for example. > matters > of unfounded fantasy, or based on errors. > > All in all, this is getting to be rather frustrating. > > >I am not an expert in either MIME or PGP, so I may just be blowing > >smoke. > > Gad, what an opening. I appreciate the opportunity, Kent, except for the > effort needed to skip rise above it... Perhaps if you could avoid thinking about this as combat :-) > >In particular, what format would MIME leave encrypted files on disk so > >my above simple archaic email example would work? How well does MIME > >work with stored objects? How does the MIME standard actually deal with > >stored objects? > > MIME is not about storage, it is about transmission. BINGO! > In any event, if you > need information about MIME, I encourage you to read the relevant RFCs and > learn about it. It's remarkably difficult to condut a debate in which one > of the sides is not familiar with basic facts. (On the other hand, it's > pretty easy when BOTH sides are ignorant...) Actually, Dave, I *have* read the rfcs (though it's been a while) and I *do* understand the "basic facts" of mime -- in fact, I understand mime better than I understand pgp [OK, hold your breath, the urge will pass, I'm just testing you :-)]. I said I "wasn't an expert". I didn't say I was "totally ignorant". -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA01565 for ietf-open-pgp-bks; Fri, 21 Nov 1997 21:44:40 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA01560 for ; Fri, 21 Nov 1997 21:44:33 -0800 (PST) Received: from s20.term1.sb.rain.org (s29.term1.sb.rain.org [198.68.144.159]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id VAA04110 for ; Fri, 21 Nov 1997 21:47:04 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id VAA10727 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 21:29:53 -0800 Date: Fri, 21 Nov 1997 21:29:53 -0800 From: Hal Finney Message-Id: <199711220529.VAA10727@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Draft comments Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: > At 11:04 AM 11/19/97 +0000, Ian Brown wrote: > Sec Comments > > 2.4.1 - Just one quibble. Since Armour is largely for backward > compatibility with the 4 million users of PGP 2.6, do we *really* need > to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could > Message-ID also go? It does say in PGP/MIME that "When the amount of > data to be transmitted requires that it be sent in many parts, the MIME > message/partial mechanism should be used rather than the multipart ASCII > armor PGP format." > > I've already said my part on why I think armour is *not* primarily for > backwards compatibility. The PART X headers are not a new header, though. > They are an old header. I don't mind losing them, or deprecating them. There is a new mechanism here. It used to be that you had to say PART X/Y, like PART 3/10. This meant that you had to know how many parts there would be, total. One of the design goals of several of the new changes (new format message length headers, one-pass signature packets) is to allow processing data where you don't know how big it is ahead of time. Old PGP had to use a lot of temp files because it kept having to complete one phase of the processing before it could begin the next one. Any time you use a temp file, this could potentially leave incriminating data on the disk (even a secure wipe is not guaranteed to work). Eliminating temp files reduces this risk. The new PART X combined with the MessageID armor header is designed to allow one-pass processing without knowing how many parts there will be in advance. The MessageID also allows different messages to be decoded even when they are interspersed. > 2.6 - I'm not sure what jdcc means by "Should the armor header line stay > or go... I think anything that reduces parsing complexity is a Good > Thing." I agree, but by this do you mean it saves implementations > parsing the algorithm fields in the actual signature itself? > > I meant that new combined header that has a begin-message and the hash > announcement. I think that as long as the "Hash:" header line can have > multiple hashes there (or it is legal to have multiple hash headers), then > we don't need this, and it simplifies to just remove it. This is just meant as a shorthand, moving the hash line up to the end of the armor header line. A similar change allows the CRC hash to be at the end of the last signature line instead of on a line of it own. It's really to reduce visual clutter. PGP cleartext signatures are so clean and nice, especially compared with the S/MIME alternative, that there has been a desire expressed to keep them as clean as possible. > 5.2.2.2 > > {{Editor's note: It would be nice to have a signature that applied to > > the key alone, rather than a key plus a user name... --jdcc}} > > What would it mean to have just key material signed by someone else? > > Right now, all the signatures sign the key material and a user name, thus > binding the user name to to the key. All of the subpackets, because they > are on an identity signature, apply only to that one username. I added in > this draft language to make that specific -- see the paragraph on them > being interpreted narrowly. If you wanted, for example, to set a symmetric > algorithm preference for the entire key, or for someone to issue some > statement about the entire key, then there has to be a signature type that > spans the entire key. Actually, key-revocation signatures are directly on keys, and subkey signatures are directly on subkeys. No userids are involved in either of these kinds of signatures. I agree with Jon that there could be other kinds of signatures which would be most logical to apply directly to a key or subkey. > 5.4 - Is the one-pass signature packet *really* necessary? > > It depends on what you mean by really. Without it, you have to verify a > signature with a two-pass scheme (hence the name "one-pass signature") and > this requires storing the whole message during the time that the signature > is being computed. This leads either to a slowdown, or a breakdown of the > whole system (a relay system could not verify a signature on a message > larger than its storage). So no, it's not *really* necessary -- PGP has > survived for years without it. Is it useful? Yes, very. It's actually an issue more for signature creation than verification. The signature packet has to go at the front of the message. But you don't have the hash until you've gotten to the end of the message. Now you have to go back and stick the signature at the front. This requires a lot of buffering, temp files, and such. With the one-pass packet you put the signature at the end. No more temp files, one less security risk. > 8.1 - Why not use the BNF-like notation from section 7.2 to describe > keyring structure also? > > I think the keyring structure is outside the scope of this document. All > the current implementations I know of use a sequential file of keys, but I > think that longterm that is going to be inadequate, and a real database is > required. Beyond that statement, I have to do a lot of handwaving. > Traditionally, IETF documents leave on-disk structure, and things like that > to the implementor. A related issue is transferrable key structure. A BNF would seem appropriate in that case. Hal Finney Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA01564 for ietf-open-pgp-bks; Fri, 21 Nov 1997 21:44:38 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA01555 for ; Fri, 21 Nov 1997 21:44:32 -0800 (PST) Received: from s20.term1.sb.rain.org (s29.term1.sb.rain.org [198.68.144.159]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id VAA04105 for ; Fri, 21 Nov 1997 21:47:03 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id VAA10686 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 21:07:58 -0800 Date: Fri, 21 Nov 1997 21:07:58 -0800 From: Hal Finney Message-Id: <199711220507.VAA10686@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Why Rabin algorithm has mostly been ignored? Sender: owner-ietf-open-pgp@imc.org Precedence: bulk People have been scared of Rabin encryption because it has a chosen ciphertext attack which reveals the key. The attacker needs to be able to get the key holder to Rabin decrypt the encrypted session key, then to tell him what the decrypted value was. In normal circumstances this is unlikely to be a problem. If the decryption of the ESK packet produces garbage, there is no reason to send the decrypted garbage back to the attacker. As long as you just destroy the garbage, you are OK. Still I think there may be some fear about using an algorithm which has this potential vulnerability. Hal Finney Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA01315 for ietf-open-pgp-bks; Fri, 21 Nov 1997 21:23:05 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA01311 for ; Fri, 21 Nov 1997 21:23:00 -0800 (PST) Received: from omni.imc.org (d10.netgate.net [205.214.160.42]) by proper.com (8.8.7/8.7.3) with SMTP id VAA18301; Fri, 21 Nov 1997 21:21:08 -0800 (PST) Message-Id: <199711220521.VAA18301@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Fri, 21 Nov 1997 21:05:21 -0800 To: Kent Crispin From: Dave Crocker / IMC Subject: Re: Armour Cc: ietf-open-pgp@imc.org In-Reply-To: <19971121164757.06784@songbird.com> References: <199711212133.NAA17838@proper.com> <3.0.3.32.19971120173237.00b93640@mail.pgp.com> <9711211516.AA67240@watpub1.watson.ibm.com> <199711212133.NAA17838@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Kent, Well, how about this? Opposite sides of the fence... At 04:47 PM 11/21/97 -0800, Kent Crispin wrote: > It is quite possible that >"simple" mailers will persist for another 10 or more years. This is certain to be true, but is a likelihood which needs to be used carefully. For example, why project that the MUA will be unchanged but that fancy new encryption sofware will be added? More importantly, why jerk the standards specification around to accomodate that particular scenario? If they want new security technology, why is it unreasonable to require that relevant additional capabilities be added. >file to a user. How do I leave an encrypted file on disk so it can >be sent? This line of question is based on the possibility that MIME formatting is somehow meaningfully different from PGP amouring. With respect to this line of question, it isn't. >The claim is that PGP has uses independent of the net [so IETF >standardization?] -- that is, independent of the problem of >transmitting data securely over the net; and it really may be that The IETF does interchange standards, not file standards. >MIME is not the best way to support *those* uses. The sun might not come up tomorrow, to. "Might" is a mighty weak approach to debating technical choices. If there is a specific problem with MIME for specific situations, let's hear about them and look at them. Across the many messages on this topic, the arguments for retaining amouring seem to be using cases which are irrelevant to IETF work, matters of unfounded fantasy, or based on errors. All in all, this is getting to be rather frustrating. >I am not an expert in either MIME or PGP, so I may just be blowing >smoke. Gad, what an opening. I appreciate the opportunity, Kent, except for the effort needed to skip rise above it... >In particular, what format would MIME leave encrypted files on disk so >my above simple archaic email example would work? How well does MIME >work with stored objects? How does the MIME standard actually deal with >stored objects? MIME is not about storage, it is about transmission. In any event, if you need information about MIME, I encourage you to read the relevant RFCs and learn about it. It's remarkably difficult to condut a debate in which one of the sides is not familiar with basic facts. (On the other hand, it's pretty easy when BOTH sides are ignorant...) d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA29279 for ietf-open-pgp-bks; Fri, 21 Nov 1997 18:19:24 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA29274 for ; Fri, 21 Nov 1997 18:19:19 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id SAA22303; Fri, 21 Nov 1997 18:20:14 -0800 (PST) Message-Id: <3.0.3.32.19971121182014.00a358d0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 18:20:14 -0800 To: Ian Brown , IETF OpenPGP From: Jon Callas Subject: Re: Draft comments In-Reply-To: <3472C7D4.F1097051@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:04 AM 11/19/97 +0000, Ian Brown wrote: Took a while to plough through! It's a pretty good document overall - please don't take the following comments as quibbling in any way, I'm just trying to contribute ;-) Thanks. Now you see why it took so long to produce. I couldn't have gotten it out even *this* fast without Hal, Rodney, Lutz, and Paul Hoffman. They did about 95% of the writing, and I just pulled it together. Sec Comments 2.4.1 - Just one quibble. Since Armour is largely for backward compatibility with the 4 million users of PGP 2.6, do we *really* need to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could Message-ID also go? It does say in PGP/MIME that "When the amount of data to be transmitted requires that it be sent in many parts, the MIME message/partial mechanism should be used rather than the multipart ASCII armor PGP format." I've already said my part on why I think armour is *not* primarily for backwards compatibility. The PART X headers are not a new header, though. They are an old header. I don't mind losing them, or deprecating them. 2.6 - I'm not sure what jdcc means by "Should the armor header line stay or go... I think anything that reduces parsing complexity is a Good Thing." I agree, but by this do you mean it saves implementations parsing the algorithm fields in the actual signature itself? I meant that new combined header that has a begin-message and the hash announcement. I think that as long as the "Hash:" header line can have multiple hashes there (or it is legal to have multiple hash headers), then we don't need this, and it simplifies to just remove it. 3.5 - Are the S2K functions really necessary? Are dictionary attacks on passphrases in an (at least) 128-bit keyspace likely to be successful? If so, I still agree with jdcc that the Iterated-Salted algorithm should be dropped. Yes, I think dictionary attacks are trivial to do successfully, and salted hashes are the way to thwart them. 5.1 - "An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects." Is this purely for legal (RSAREF) reasons? The international version of PGP 2.6 can generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is there any *technical* reason why OP implementations should not generate version 2 packets? When PGP 2.6 was created, the version number of the packets was bumped from 2 to 3, but nothing else was changed. It's really only there so you can tell whether a message was made by 2.5 or 2.6. There is no technical reason not to generate a V2 packet, but there is no technical reason *to* generate them, either. RFC 1991 says on the subject: "A version number of 2 or 3 is currently allowed for each packet format. New versions will probably be numbered sequentially up from 3. For backwards compatibility, implementations will usually be expected to support version N of a packet whenever they support version N+1. Version 255 may be used for experimental purposes." This paragraph is my rationale for preferring V4 to V3, and noting that V2 is identical to V3, but that it must not be generated. 5.2.2.2 "Preferred hash algorithms" - you mention "If this subpacket is not included, ZIP is preferred." Would it be useful to put a sentence of this type in the preferred symmetric and hash algorithms also? We have 3DES and SHA-1 as MUSTs, so they could be used... The reason I put that there is that this preference is different in semantics from the others. You see, most implementations of PGP compress by default. The main reason for this packet is so that a key can say, "Hey, if you send me a compressed message, I can't read it." This is so that a minimal implementation -- one that does not have compression (remember, the MUST algorithm for compression is uncompressed) -- can advertise that it doesn't have compression. I put that sentence in there so that all the existing keys in the world will continue to work the way they always have. > {{Editor's note: It would be nice to have a signature that applied to > the key alone, rather than a key plus a user name... --jdcc}} What would it mean to have just key material signed by someone else? Right now, all the signatures sign the key material and a user name, thus binding the user name to to the key. All of the subpackets, because they are on an identity signature, apply only to that one username. I added in this draft language to make that specific -- see the paragraph on them being interpreted narrowly. If you wanted, for example, to set a symmetric algorithm preference for the entire key, or for someone to issue some statement about the entire key, then there has to be a signature type that spans the entire key. > {{Editor's note: There is presently no way for a key-signer (a.k.a. > certifier) to sign a main key along with a subkey. There are a number > of useful situations for a set of keys (main plus subkeys) to all be > signed together... --jdcc}} Could you give a few examples? A feature of the V4 keys is to have a main key and some number of subkeys. Certifications (a.k.a. key signatures) are over the main key only. This means that you can replace your encryption key without losing your signatures. This is a Good Thing. However, a number of people, including you and Adam, are proposing that as an alternative to ARR/CMR/whatever that some form of "key escrow" be used. Adam and I are starting to work on a paper that compares "shared key" (the Crypto-Correct term for placing a secret key in a third party's possession) and "multiple encryption" schemes for providing access to data. As presently described, the key-replacement mechanisms make it impossible to implement a shared-key access system. (In the Bad Old Days, I bragged that PGP 5 was "escrow-resistant" -- but it now seems that what I used to think of escrow is actually a feature to a lot of people.) So we need to have a mechanism that lets someone sign not only your top-level key, but some number of subkeys, too. I can think of two main ways to do this: (1) Add a new signature type. This new signature type is like an existing certification signature, but certifies a list of subkeys, too. We'd have to devise a syntax for it. (2) Add a subpacket type. This subpacket would be included in a certification signature and would state that a subkey (specified by algid and fingerprint) is to be included in the hash. More than one of these subpackets means more than one key is part of the certification. I think (2) is better -- which you can probably tell because I started to design the thing. There are other ways to do it, but I think that a subpacket is preferable, because it piggybacks on the existing signature-plus-subpacket framework. 5.4 - Is the one-pass signature packet *really* necessary? It depends on what you mean by really. Without it, you have to verify a signature with a two-pass scheme (hence the name "one-pass signature") and this requires storing the whole message during the time that the signature is being computed. This leads either to a slowdown, or a breakdown of the whole system (a relay system could not verify a signature on a message larger than its storage). So no, it's not *really* necessary -- PGP has survived for years without it. Is it useful? Yes, very. 5.10 - I think you're right about there being so many problems with Trust packets, we should forget them. Your idea about them being implementation dependent is good, except that different OP implementations may want to use the same keyring. For example, I use PGP 2.6.3i and my mail encrypting program with the same keyring. If they implement trust packets differently, it would be very confusing. I think we should just specify that they should be ignored. All PGP implementations have "export" and "import" functions, and don'e merely pass keyrings around. Passing a keyring *works* but it's not a good idea, because it leaks all your trust information. If an implementation 8.1 - Why not use the BNF-like notation from section 7.2 to describe keyring structure also? I think the keyring structure is outside the scope of this document. All the current implementations I know of use a sequential file of keys, but I think that longterm that is going to be inadequate, and a real database is required. Beyond that statement, I have to do a lot of handwaving. Traditionally, IETF documents leave on-disk structure, and things like that to the implementor. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA28165 for ietf-open-pgp-bks; Fri, 21 Nov 1997 17:01:14 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA28161 for ; Fri, 21 Nov 1997 17:01:11 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id RAA21622; Fri, 21 Nov 1997 17:02:09 -0800 (PST) Message-Id: <3.0.3.32.19971121170210.00a3b510@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 17:02:10 -0800 To: garygliu@pacbell.net, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Why Rabin algorithm has mostly been ignored? In-Reply-To: <34762A6A.3166@pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 04:42 PM 11/21/97 -0800, Gary Liu wrote: Why Rabin algorithm has been mostly ignored in discussions, implementations and standards? It seems to me that Rabin algorithm is a very decent alternative to RSA. It is extremely fast in encryption and verification (only one modular square), just as efficient as RSA in signing and decryption, and as secure as RSA (also depends on the difficulty of factoring). I just do not understand why it has been mostly ignored. Have I missed something? Had you suggested it to me, I would have gladly put it in. Would you like me to do that now? Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA27946 for ietf-open-pgp-bks; Fri, 21 Nov 1997 16:49:22 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA27940 for ; Fri, 21 Nov 1997 16:49:17 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id QAA16015 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 16:48:00 -0800 Message-ID: <19971121164757.06784@songbird.com> Date: Fri, 21 Nov 1997 16:47:57 -0800 From: Kent Crispin To: ietf-open-pgp@imc.org Subject: Re: Armour References: <3.0.3.32.19971120173237.00b93640@mail.pgp.com> <9711211516.AA67240@watpub1.watson.ibm.com> <199711212133.NAA17838@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199711212133.NAA17838@proper.com>; from Dave Crocker / IMC on Fri, Nov 21, 1997 at 01:27:38PM -0800 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Fri, Nov 21, 1997 at 01:27:38PM -0800, Dave Crocker / IMC wrote: > One more time, folks: If you are using the absence of MIME from some > current usage of email then you are using a fundamentally flawed argument. > MIME is being adopted. The rate of adoption (i.e., growth in use) is > proceeding nicely. We are not early in the process, so the assessment does > not represent fantasy. I don't know if this is the argument, but I am not sure I believe that it is flawed, in any case. "Widespread" adoption of MIME is not the same as "universal" adoption of MIME. It is quite possible that "simple" mailers will persist for another 10 or more years. In particular, the fact that simple MUA interfaces appear in many many scripts, cgi programs, and so on virtually guarantees a 10 year lifetime. So think about the following: mail $user <$file Imagine it is embedded in a cgi script, possibly sending a requested file to a user. How do I leave an encrypted file on disk so it can be sent? > If you are noting that some use of PGP is, or can be, outside of > environments that use MIME (i.e., not Internet mail and not the Web), then > you are right that they would have to add MIME support to work. What you > are missing is that MIME has become the standard way of solving such > packaging, labeling and protecting requirements for the net. The claim is that PGP has uses independent of the net [so IETF standardization?] -- that is, independent of the problem of transmitting data securely over the net; and it really may be that MIME is not the best way to support *those* uses. I am not an expert in either MIME or PGP, so I may just be blowing smoke. But perhaps there may be some actual technical issues here. In particular, what format would MIME leave encrypted files on disk so my above simple archaic email example would work? How well does MIME work with stored objects? How does the MIME standard actually deal with stored objects? Here's another use for ascii armor -- suppose I want to send an encrypted file via email and I *don't* want it to be automatically presented for decryption? How do I instruct PGP to produce such a file? -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA27901 for ietf-open-pgp-bks; Fri, 21 Nov 1997 16:43:39 -0800 (PST) Received: from mail-gw2.pacbell.net (mail-gw2.pacbell.net [206.13.28.53]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA27897 for ; Fri, 21 Nov 1997 16:43:36 -0800 (PST) Received: from a (ppp-207-214-252-64.psdn11.pacbell.net [207.214.252.64]) by mail-gw2.pacbell.net (8.8.8/8.7.1+antispam) with SMTP id QAA25726 for ; Fri, 21 Nov 1997 16:44:33 -0800 (PST) Message-ID: <34762A6A.3166@pacbell.net> Date: Fri, 21 Nov 1997 16:42:18 -0800 From: Gary Liu Reply-To: garygliu@pacbell.net X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Why Rabin algorithm has mostly been ignored? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In draft-ietf-openpgp-formats-00.txt: > 6.1 Public Key Algorithms > > 1 - RSA (Encrypt or Sign) > 2 - RSA Encrypt-Only > 3 - RSA Sign-Only > 16 - Elgamal > 17 - DSA (Digital Signature Standard) > 100 to 110 - Private/Experimental algorithm. > > Implementations MUST implement DSA for signatures, and Elgamal for > encryption. Implementations SHOULD implement RSA encryption. > Implementations MAY implement any other algorithm. > > {{Editor's note: reserve an algorithm for elliptic curve? Note that > I've left Elgamal signatures completely unmentioned. I think this is > good. --jdcc}} Why Rabin algorithm has been mostly ignored in discussions, implementations and standards? It seems to me that Rabin algorithm is a very decent alternative to RSA. It is extremely fast in encryption and verification (only one modular square), just as efficient as RSA in signing and decryption, and as secure as RSA (also depends on the difficulty of factoring). I just do not understand why it has been mostly ignored. Have I missed something? Gary Liu Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA27772 for ietf-open-pgp-bks; Fri, 21 Nov 1997 16:32:37 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA27768 for ; Fri, 21 Nov 1997 16:32:33 -0800 (PST) Received: from s20.term1.sb.rain.org (s25.term1.sb.rain.org [198.68.144.155]) by coyote.rain.org (8.8.8/8.8.8) with ESMTP id QAA08339 for ; Fri, 21 Nov 1997 16:34:58 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id QAA10298 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 16:18:12 -0800 Date: Fri, 21 Nov 1997 16:18:12 -0800 From: Hal Finney Message-Id: <199711220018.QAA10298@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org Subject: Re: Armour Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I would have some questions about using PGP-MIME for all the ascii output modes, outside of the email environment. With email (and the web and news) there is a distinction between header and body. MIME requires some data to go into the header, and some to go into the body. If you're just encrypting files but you want ascii output for some reason, you would have to introduce the notion of a header and body within a file. You'd have header lines as for email, then a blank, then the body of the encrypted data, all within the file. So an encrypted, ascii-encoded file would look like this (example from RFC2015): Mime-Version: 1.0 Content-Type: multipart/encrypted; boundary=foo; protocol="application/pgp-encrypted" --foo Content-Type: application/pgp-encrypted Version: 1 --foo Content-Type: application/octet-stream -----BEGIN PGP MESSAGE----- Version: 2.6.2 hIwDY32hYGCE8MkBA/wOu7d45aUxF4Q0RKJprD3v5Z9K1YcRJ2fve87lMlDlx4Oj eW4GDdBfLbJE7VUpp13N19GL8e/AqbyyjHH4aS0YoTk10QQ9nnRvjY8nZL3MPXSZ g9VGQxFeGqzykzmykU6A26MSMexR4ApeeON6xzZWfo+0yOqAq6lb46wsvldZ96YA AABH78hyX7YX4uT1tNCWEIIBoqqvCeIMpp7UQ2IzBrXg6GtukS8NxbukLeamqVW3 1yt21DYOjuLzcMNe/JNsD9vDVCvOOG3OCi8= =zzaA -----END PGP MESSAGE----- --foo-- Now if you want to send this to someone, you have two ways you can go. First, you can just send the file itself as an attachment. In that case the recipient would receive the file, then he needs to run his MIME parser on that disk file. But if his MIME parser is part of his mail client, he may have difficulty convincing it to parse the MIME information in a disk file. The second approach is to take that file and put the headers from it (the first three lines above) into the outgoing mail header part, with the rest of the file going into the outgoing mail body. If you do this, then the recipient will see the file as an ordinary MIME message and he will be able to decrypt it easily. However this sending mechanism is a bit ad hoc. The sending mail client would have to have a special kind of file-sending mode, or recognize that a file being sent as an attachment looks like it already has MIME headers in it, so it should be treated specially. Another issue related to headers is that all encrypted or signed parts must themselves be in "MIME canonical format (body and headers)". This means (I think) that there needs to be one or more MIME header lines put before the cleartext of the data which will be signed or encrypted. As with the earlier case, confusion can arise once you move outside the email environment. You could clearsign a file on disk, and then later want to encrypt it. Now, the file already has MIME headers from clear- signing. Should the encryption program check and/or ask whether the file is already in MIME canonical form, or should it just assume that it is not, and always wrap the file in its own headers before encrypting? Or suppose you are decrypting a PGP-MIME file. Are you supposed to leave the MIME headers in the output? If the output is just some data which the user encrypted, it would probably be best to remove the MIME headers and undo whatever content-transfer-encoding is specified. On the other hand if the output is a MIME multipart, then maybe you should leave them in. It seems to me that MIME is not very well suited to providing the ascii encoding for a general purpose encryption utility, unless it is tightly integrated into a MIME-aware environment. I would welcome suggestions for how these situations would be handled. A limitation with PGP-MIME is that data which is signed and encrypted must be in 7-bit form. This means that if you are signing and encrypting 8-bit data, and you are going to produce ASCII output using PGP-MIME, you must first convert the input to 7-bit form, probably using base64 encoding. This will bloat the size of the output file. This restriction makes sense in the email environment, where gateways may want to strip off the encryption and leave a legal MIME message which has no 8-bit data. But if we are generalizing beyond mail applications this limitation may not be appropriate. Related to this, with PGP we have two types of "ascii" signatures: cleartext signatures, and ascii armored non-cleartext signatures. PGP-MIME has only one type. There is no mechanism in PGP-MIME to create the equivalent of an ascii armored non-cleartext signature (like what would be created with "pgp -sa" using PGP 2.6.2). There is also no PGP-MIME way of encoding a detached signature, as far as I know. In this sense, PGP-MIME is more than just a transport layer for PGP messages. It applies its own set of rules and semantics to the data being transported. While these rules are often reasonable and appropriate for the email environment, they are not as flexible as the general capability to transport any PGP data which PGP's ascii armor provides. Hal Finney Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA26716 for ietf-open-pgp-bks; Fri, 21 Nov 1997 15:15:27 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA26712 for ; Fri, 21 Nov 1997 15:15:22 -0800 (PST) Received: from omni.imc.org ([207.94.139.169]) by proper.com (8.8.7/8.7.3) with SMTP id PAA17930 for ; Fri, 21 Nov 1997 15:13:32 -0800 (PST) Message-Id: <199711212313.PAA17930@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Fri, 21 Nov 1997 15:06:43 -0800 To: ietf-open-pgp@imc.org From: Dave Crocker / IMC Subject: Re: Armour In-Reply-To: <199711212219.OAA04747@einstein.bluemoney.com> References: <199711212133.NAA17838@proper.com> <3.0.3.32.19971120173237.00b93640@mail.pgp.com> <9711211516.AA67240@watpub1.watson.ibm.com> <199711212133.NAA17838@proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:19 PM 11/21/97 -0800, Jeremey Barrett wrote: >I thought we were discussing PGP, not email. Last time I checked noone Responses like this are coming from a number of people. They are, frankly, beginning to look like willful and selective listening. In other words, they are highly counterproductive. I made the email comment in response to the clear misunderstanding about the status of email and the status of MIME usage within email. I.e., about the status of MIME. The focus was not email, it was MIME. IS THIS CLEAR, FOLKS? WE ARE DISCUSSING MIME, NOT EMAIL. This point is being ignored. We need, instead, to pay attention to it. Let me try it yet again: The Internet standard way of packaging, labeling and adding transport protection is MIME. It is not a political correctnet issue about the "official" choice. It is a matter of what is actually being USED. The fact that it is not "universal" is because it is new enough to be still going through adoption, i.e., growing in use. The growth is going just fine, thank you very much. If this group insists on trying to standardize a separate mechanism for doing the same things as MIME, it will be declaring itself as separate from the general Internet technical community and it will be adding entirely unnecessary redundancy and complexity to its specification and to the resulting products. One would think that those interested in promoting the commercial success of PGP would want to be careful to avoid taking any step which would (further) marginalize it from the commercial sector. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA26709 for ietf-open-pgp-bks; Fri, 21 Nov 1997 15:15:19 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA26705 for ; Fri, 21 Nov 1997 15:15:16 -0800 (PST) Received: from omni.imc.org ([207.94.139.169]) by proper.com (8.8.7/8.7.3) with SMTP id PAA17918; Fri, 21 Nov 1997 15:13:23 -0800 (PST) Message-Id: <4.0.32.19971121104143.00eb5250@imc.org> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Fri, 21 Nov 1997 15:10:47 -0800 To: Jon Callas From: Dave Crocker / IMC Subject: Re: Armour Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971120173237.00b93640@mail.pgp.com> References: <346DB3C5.55F6BF9C@cs.ucl.ac.uk> <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk John, At 05:32 PM 11/20/97 -0800, Jon Callas wrote: >PGP objects (messages, keys, files, etc.) are constructed so as to not have >a lot of known plaintext in them. Whatever your opinion is about this, it's Actually, the "bracketing" aspect of armouring is specifically about adding known plaintext, so that the boundaries of the PGP data can be detect. But, as you say, we digress... >Most of the present key servers, from the HTTP ones to the LDAP ones >transport their keys in armored form. The idea that the key server has to >have a MIME handler in it seems silly. The web already supports MIME. What seems REALLY silly is making it support an additional mechanism for accomplishing the same functions. People have been tending to refer to this debate as having to do with MIME for email. While it does include that, it's important to think larger. MIME has become the Internet standard mechanism for wrapping 'documents'. Not just for email. Again I would like to remind people that this debate is really about the question of having PGP properly integrate into the Internet standards data architecture or whether it wants to remain an independent effort (which one might call a 'wart on the side' but that would sound more dismissive or condescending than I really intend.) >PGP objects are not just mail messages. Any data-thingie that you want to That's correct. They need to be MIME objects and MIME isn't just email. >encrypt can be put into PGP format, and if you don't trust raw binary, >armor works. Let me say this again, OP is *NOT* an email-encryption >standard, it is a data-object encryption standard (I'm quoting our esteemed Right. And MIME is a data packaging, labeling and protecting standard. Each should try to focus on their own topics and not do the work of the other. >There are people who want to put PGP, especially OP, especially a >minimalistic OP into a number of limited environments -- pagers, PDAs, >smart cards (which are still a few years off, as they are *really* >limited). These people need to have a minimal set of things to implement. If you think that these object will not already be doing MIME, you need to look more closely into their product plans. >I think that it is wrong to make MIME a MUST feature. It is obvious to me See above. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA26560 for ietf-open-pgp-bks; Fri, 21 Nov 1997 15:07:00 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA26555; Fri, 21 Nov 1997 15:06:56 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id PAA19780; Fri, 21 Nov 1997 15:07:55 -0800 (PST) Message-Id: <3.0.3.32.19971121150755.00a62830@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 15:07:55 -0800 To: Dave Crocker / IMC , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Armour In-Reply-To: <199711212133.NAA17838@proper.com> References: <9711211516.AA67240@watpub1.watson.ibm.com> <3.0.3.32.19971120173237.00b93640@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:27 PM 11/21/97 -0800, Dave Crocker / IMC wrote: One more time, folks: If you are using the absence of MIME from some current usage of email then you are using a fundamentally flawed argument. MIME is being adopted. The rate of adoption (i.e., growth in use) is proceeding nicely. We are not early in the process, so the assessment does not represent fantasy. One more time: PGP is not limited to email. I agree wholeheartedly that in the long-term, MIME is the answer for email and related technologies. PGP can be used for other technologies too. In the OpenPGP working group, we are working on a suite of documents. One of them is OP-FORMATS. One is OP-MIME. I think it is right and proper to encourage the use of MIME with email. I do not think it is at all proper to saddle a pager network, an electronic commerce system, or other legitimate uses of OpenPGP with MIME handling, when all they want to do is move a secure block of data around. At the BOF for the working group, our area director described PGP as an "object encryption system" -- a term I've been using ever since, because I think it's a good description of what PGP is. One of the important uses of PGP is email encryption, but that is not the only use for it. The place to solve the PEM/MOSS problem is the OP-MIME spec. Here, I have no problems with a statement saying when someone SHOULD use MIME, and I'd love to discuss that. The only thing that I, Rodney, Bill Geiger, and others are objecting to is pushing MIME into places where it is not needed nor wanted. If this stops being a "there can be only one" type of discussion, I think you'll find us being more cooperative. I'd love to see some suggestions on how to word such a paragraph. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA25868 for ietf-open-pgp-bks; Fri, 21 Nov 1997 14:15:43 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA25863; Fri, 21 Nov 1997 14:15:37 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id OAA04747; Fri, 21 Nov 1997 14:19:24 -0800 Date: Fri, 21 Nov 1997 14:19:24 -0800 Message-Id: <199711212219.OAA04747@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker / IMC Cc: ietf-open-pgp@imc.org Subject: Re: Armour In-Reply-To: <199711212133.NAA17838@proper.com> References: <3.0.3.32.19971120173237.00b93640@mail.pgp.com> <9711211516.AA67240@watpub1.watson.ibm.com> <199711212133.NAA17838@proper.com> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Dave Crocker / IMC writes: > One more time, folks: If you are using the absence of MIME from some > current usage of email then you are using a fundamentally flawed argument. > MIME is being adopted. The rate of adoption (i.e., growth in use) is > proceeding nicely. We are not early in the process, so the assessment does > not represent fantasy. I thought we were discussing PGP, not email. Last time I checked noone has implemented file encryption, or encrypted archiving tools, or remailers, or keyservers, or nym servers, or anything other than email (and on occasion news) using MIME. Nor should they. PGP is a powerful tool, used in many different ways. ONE of them is vanilla email. ALL of them benefit from ASCII armoring. ASCII armoring is essential to the survival of PGP and to the security of the "PGP system", and the many systems built on top of it now and in the future. > > If you are noting that some use of PGP is, or can be, outside of > environments that use MIME (i.e., not Internet mail and not the Web), then > you are right that they would have to add MIME support to work. What you > are missing is that MIME has become the standard way of solving such > packaging, labeling and protecting requirements for the net. > > There is nothing wrong with PGP's having invented its own solution, at the > time that was done. > > There is everything wrong with failing to switch to MIME use now. > One can implement MIME support without "switching to it". PGP/MIME is good. PGP/MIME SHOULD be done. ASCII armor MUST be done. Regards, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHYI2S/fy+vkqMxNAQF08QQAzqvjJQyk6kXL1mMYVX17qJAnOO9whZfo r7+fz7m0olINBSB7UBRE1jkhV0Pjb6AugpQcF1eunyMI2xCE7tDfYegqz4/VlIW/ kLMRG6Dl+lL0n/Z2mXQuoZOxRAQLkvznqvQs+xKjX34pfx/0202Wme9xNxzcoOAs CBKqECim7EQ= =Ds9z -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA25647 for ietf-open-pgp-bks; Fri, 21 Nov 1997 13:59:06 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA25641 for ; Fri, 21 Nov 1997 13:58:58 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id IAA14969; Sat, 22 Nov 1997 08:58:19 +1100 Received: from shirley (dformosa@dialin-29 [137.154.130.29]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id IAA24469; Sat, 22 Nov 1997 08:58:15 +1100 (EST) Date: Sat, 22 Nov 1997 07:43:22 +1100 (EST) From: David Formosa X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: Jim McCoy cc: ietf-open-pgp@imc.org, jeremey@bluemoney.com Subject: Re: The case against redundancy and isolation In-Reply-To: <3.0.3.32.19971121131410.0335c230@mail.communities.com> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Fri, 21 Nov 1997, Jim McCoy wrote: > Contrary to the claims > being made, a vast majority of the mail agents in use today support > reading MIME message While this is true, mime complient newsreaders are not as commen. I would argue for the armor to be retained for news. [...] > Eliminating Ascii Armor has nothing to do with the security of the > system Agreed but I beleave that backwards capasity would cause a reduction of the system's securaty. Open-PGP should be capatable with PGP or we can't call it PGP. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett. I do not reply to munged addresses. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNHXycKQK0ynCmdStAQF+8gP+LqrDFHEgGyGZ4apAsDT9SaKDPOsETclI LAjEQ+wGifMSUkvN75tUxfbvCFUmbeGHlSXwRpAHW2BElmsEa2cliccbn3XdOmn0 1bj3oZELFayv980+4gzmgYzmUQPp73OEkMsdD6lpCLOGtKjEGIJjquryOmgjcZyi Epf93aiP5ZU= =UUUu -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA25291 for ietf-open-pgp-bks; Fri, 21 Nov 1997 13:35:43 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA25284 for ; Fri, 21 Nov 1997 13:35:38 -0800 (PST) Received: from omni.imc.org ([207.94.139.169]) by proper.com (8.8.7/8.7.3) with SMTP id NAA17838 for ; Fri, 21 Nov 1997 13:33:48 -0800 (PST) Message-Id: <199711212133.NAA17838@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Release Candidate 1 (build 230) Date: Fri, 21 Nov 1997 13:27:38 -0800 To: ietf-open-pgp@imc.org From: Dave Crocker / IMC Subject: Re: Armour In-Reply-To: <9711211516.AA67240@watpub1.watson.ibm.com> References: <3.0.3.32.19971120173237.00b93640@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk One more time, folks: If you are using the absence of MIME from some current usage of email then you are using a fundamentally flawed argument. MIME is being adopted. The rate of adoption (i.e., growth in use) is proceeding nicely. We are not early in the process, so the assessment does not represent fantasy. If you are noting that some use of PGP is, or can be, outside of environments that use MIME (i.e., not Internet mail and not the Web), then you are right that they would have to add MIME support to work. What you are missing is that MIME has become the standard way of solving such packaging, labeling and protecting requirements for the net. There is nothing wrong with PGP's having invented its own solution, at the time that was done. There is everything wrong with failing to switch to MIME use now. We went through this same, silly problem when PEM was being developed and it was one of the reasons PEM died. MOSS attempted to fix the problem but it was too late. It sure would be nice if folks learned some lessons from that experience. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA24842 for ietf-open-pgp-bks; Fri, 21 Nov 1997 13:09:55 -0800 (PST) Received: from homer.communities.com (root@homer.communities.com [205.162.51.9]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA24838 for ; Fri, 21 Nov 1997 13:09:51 -0800 (PST) Received: from igor.four11.com (igor.four11.com [205.180.227.86]) by homer.communities.com (8.7.5/8.7.3) with SMTP id OAA14382; Fri, 21 Nov 1997 14:40:09 -0800 Message-Id: <3.0.3.32.19971121131410.0335c230@mail.communities.com> X-Sender: mccoy@mail.communities.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 13:14:10 -0800 To: ietf-open-pgp@imc.org From: Jim McCoy Subject: Re: The case against redundancy and isolation Cc: jeremey@bluemoney.com In-Reply-To: <199711211820.KAA04398@einstein.bluemoney.com> References: <19971120184831.17558@sobolev.rhein.de> <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jeremey Barrett wrote: >It is equally obvious to the non-MIME mail reader that this ASCII >armored mail message was signed. However, it is not obvious that >a PGP/MIME signed message has anything but gibberish in it. Ever >used 'mail' to read a MIME message? :-) No, and I never tried to write a device driver using 'cat'. I know it can be done but so what? There comes a time when you just have to admit that there is only so far that you will go to be backwards compatible and these "but what if the mail agent doesn't understand MIME?" cries are becoming a bit rediculous. Contrary to the claims being made, a vast majority of the mail agents in use today support reading MIME message (and most of the people who are still using /bin/mail or versions of elm compiled in the 1980s are smart enough to be able to pipe things through mmencode, etc.) >In some cases, it is useful. In other cases, it's the wrong policy. >As Jon pointed out, PGP is not email software, there are a host >of other applications for PGP, which might well benefit (and do) >from ASCII armor. I hate to burst the bubble of everyone at PGP, Inc. but right now and for the forseeable future PGP is _only_ email. It is not for general purpose encryption because in those cases people use toolkits that do not carry around as much bogus baggage as PGP does (like Ascii Armoring for example...) >My point is that _requiring_ MIME eliminates a set of users. That's >all. Eliminating users decreases the security of the system, because >less people have the necessary tools. If security is the goal (and >as I read the wg charter, "The whole purpose of Open-PGP is to provide >security services") then the elimination of ASCII armor is >contradictory to the goals of the wg, IMO. It should be a MUST. Requiring MIME eliminates a very small set of users and makes it easier for developers to include support in future mailers so that those people stuck with obsolete mail agents can find a new and better one without too much trouble. Eliminating Ascii Armor has nothing to do with the security of the system (other than increasing its complexity and the probability of bugs), if the tools use Internet-Standard parts then it is likely that there will be more tools available and more users. jim Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA23600 for ietf-open-pgp-bks; Fri, 21 Nov 1997 11:49:48 -0800 (PST) Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com [128.221.131.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA23596 for ; Fri, 21 Nov 1997 11:49:44 -0800 (PST) Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA20759; Fri, 21 Nov 1997 14:50:07 -0500 Received: from ferguson by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA18211; Fri, 21 Nov 1997 14:50:06 -0500 Message-Id: <3.0.3.32.19971121143631.03c916dc@pop.pn.com> X-Pgp-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 14:36:31 -0500 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: Re: Armour Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I don't think it is architecturally sound to assume MIME is present where PGP is used. I also don't think it is reasonable to assume people will "just pipe it into their favorite un-mime/mime filter", as you can't assume a command line environment. I also don't think MIME is equivalent to Armoring, as it involves multi-part processing which is more complex. I think the armoring technique that OP inherits from PGP was useful, is still usefull, and should not be dropped. I don't think it's sound to assume that "everone can do MIME", any more than it is sound to assume "everyone can print PostScript". >Date: Fri, 21 Nov 1997 09:27:53 +0000 >From: Ian Brown >X-Mailer: Mozilla 4.02 [en] (WinNT; U) >To: Jon Callas >CC: IETF OpenPGP >Subject: Re: Armour >Sender: owner-ietf-open-pgp@imc.org > >Jon Callas wrote: > >> I mean safely holding an object in any system that can't handle raw binary. >> PGP objects (messages, keys, files, etc.) are constructed so as to not have >> a lot of known plaintext in them. Whatever your opinion is about this, it's >> the way PGP was designed. Phil has explained this to me in detail. This is >> also the rationale behind such things as that a V3 private key encrypts the >> body of the MPIs but not their length -- the length is known plaintext. > >I cannot see the relevance of this to the Armour debate. All that armour >does is take some binary PGP data and put it in a format which can be >used in 7-bit systems. Anyone can trivially reverse the process. It >certainly has nothing to do with the security of the underlying data. >The binary data is fully secure before it ever sees armour. I'm >surprised you seem to be arguing otherwise. > >Also, as much as I admire Phil, I thought we had agreed that "Phil has >spoken - it must be so" was not the attitude this group should take. > >> There are a number of places where having an armored binary object is >> useful. Mail is one. Network transport is another. > >Where MIME is also available, and does exactly the same job. > >> Any place where the >> receiving program is a C program is a third (anyone who is careless enough >> to call strfoo intead of memfoo can hurt themselves, and this is a hard bug >> to find -- I know, I've done it). > >So you're suggesting that programmers can't cope with handling binary >data, so we should convert everything to armour format first? > >> Most of the present key servers, from the HTTP ones to the LDAP ones >> transport their keys in armored form. The idea that the key server has to >> have a MIME handler in it seems silly. > >Why is it any sillier than having an armour handler, apart from the fact >that you've already implemented one? > >> PGP objects are not just mail messages. Any data-thingie that you want to >> encrypt can be put into PGP format, and if you don't trust raw binary, >> armor works. > >What do you mean by 'trust'? The security of the underlying data? >Armouring it doesn't increase that. Or 'trust' the encrypted object will >be safely transported across a 7-bit system? Are you saying MIME won't >do that? > >> P is *NOT* an email-encryption >> standard, it is a data-object encryption standard (I'm quoting our esteemed >> area director here). Of course, the most obvious use of a data-object >> encryption standard is to send secure mail, but that is among the uses of >> OP, not the sole one. > >Why are we arguing here? This is precisely the point several people have >made. Armour is only relevant to sending binary PGP objects across 7-bit >systems, of which mail is vastly the most common. Of course OP is not >just an e-mail standard. This is exactly why we shouldn't be making >systems largely used for mail transport an integral part of the >standard. > >> There are people who want to put PGP, especially OP, especially a >> minimalistic OP into a number of limited environments -- pagers, PDAs, >> smart cards (which are still a few years off, as they are *really* >> limited). These people need to have a minimal set of things to implement. > >Again, precisely the argument several people have made. > >> I think that it is wrong to make MIME a MUST feature. > >I agree! Did anyone ever say this? I said in my "draft comments" post >that I liked the armour description in the draft, which is: > >> 2.4 Conversion to Radix-64 >> >> OP's underlying native representation for encrypted messages, signature >> certificates, and keys is a stream of arbitrary octets. Some systems >> only permit the use of blocks consisting of seven-bit, printable text. >> For transporting OP's native raw binary octets through email channels, >> a printable encoding of these binary octets is needed. OP provides the >> service of converting the raw 8-bit binary octet stream to a stream of >> printable ASCII characters, called Radix-64 encoding or ASCII Armor. >> >> In principle, any printable encoding scheme that met the requirements >> of the email channel would suffice, since it would not change the >> underlying binary bit streams of the native OP data structures. The OP >> standard specifies one such printable encoding scheme to ensure >> interoperability. > >> it is wrong to cut out small developers by >> adding complexity and code size > >Absolutely! This is why armor shouldn't be a MUST! > >> I'll add as a related note that making MIME a requirement actually helps >> PGP Inc. Our toolkit does all the MIME/armor/compression handling >> transparently for the caller. We'll just shrug. I feel compelled myself, >> though, as editor of this spec to argue for a simple format spec, and then >> layer MIME handling on top of it for the benefit of the small developer. > >I couldn't agree more! I'm delighted it helps PGP Inc.! > >Ian. > > Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA22836 for ietf-open-pgp-bks; Fri, 21 Nov 1997 10:57:47 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA22832 for ; Fri, 21 Nov 1997 10:57:43 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA15603; Fri, 21 Nov 1997 10:56:39 -0800 (PST) Message-Id: <3.0.3.32.19971121105638.00ba5100@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 21 Nov 1997 10:56:38 -0800 To: Ian Brown , "David P. Kemp" From: Jon Callas Subject: Re: CMR Cc: IETF OpenPGP In-Reply-To: <3475B4C7.4715D8A9@cs.ucl.ac.uk> References: <199711211612.LAA06971@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 04:20 PM 11/21/97 +0000, Ian Brown wrote: No, I don't. But as PGP Inc are pushing CMR as a corporate solution which gives the ability to snoop on employees' e-mail, I just wanted to point out one of the negative consequences for such unethical companies ;-) We are doing no such thing. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA22074 for ietf-open-pgp-bks; Fri, 21 Nov 1997 10:17:25 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA22070 for ; Fri, 21 Nov 1997 10:17:20 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id KAA04398; Fri, 21 Nov 1997 10:20:58 -0800 Date: Fri, 21 Nov 1997 10:20:58 -0800 Message-Id: <199711211820.KAA04398@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Thomas Roessler Cc: ietf-open-pgp@imc.org Subject: Re: The case against redundancy and isolation In-Reply-To: <19971120184831.17558@sobolev.rhein.de> References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> <19971120184831.17558@sobolev.rhein.de> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Thomas Roessler writes: > On November 19 1997, Jeremey Barrett wrote: > > With MIME, it is immediately obvious to the recipient that > the message was signed or encrypted, whether or not they > may have a PGP-capable mail reader. It is also trivial to > use this non-PGP-aware software to handle PGP/MIME signed > messages correctly when replying. It is equally obvious to the non-MIME mail reader that this ASCII armored mail message was signed. However, it is not obvious that a PGP/MIME signed message has anything but gibberish in it. Ever used 'mail' to read a MIME message? :-) I'm not saying MIME is bad, I'm saying that eliminating ASCII armor is a step in the wrong direction. > > > I want to be able to send secure email to people who don't > > use MIME, that is a very useful feature of PGP in the > > context of email, and I don't see any reason at all to not > > include ASCII armoring in the draft. > > I want to be able to send PGP-signed email to mailing > lists where not everybody has PGP at hand. Nevertheless, > everybody should be able to properly handle my messages > (which might quite well include diff(1) output and similar > things). Separating the cryptographic signature from the > message's content proper is one of the most useful > features of multipart/signed messages. In some cases, it is useful. In other cases, it's the wrong policy. As Jon pointed out, PGP is not email software, there are a host of other applications for PGP, which might well benefit (and do) from ASCII armor. > > > Yes, PGP is about security, and requiring PGP users to use > > MIME mail readers does not result in an increase in > > security. Quite the opposite. > ^^^^^^^^^^^^^^^^^^^ > > How do you come to this conclusion? I'm actually quite > glad to use a MIME and PGP capable Mail User Agent. And > yes, I'm using it from my Unix shell. And yes, it's > freely available. My point is that _requiring_ MIME eliminates a set of users. That's all. Eliminating users decreases the security of the system, because less people have the necessary tools. If security is the goal (and as I read the wg charter, "The whole purpose of Open-PGP is to provide security services") then the elimination of ASCII armor is contradictory to the goals of the wg, IMO. It should be a MUST. > > > IMO ASCII-armored PGP is not a competing standard on encoding > > techniques, rather it is an integral part of PGP and security. > > I beg your pardon - PGP just works fine with binaryly > transmitted packet files. Yes, but ASCII armor has quite alot of use, both in email and other applications. It's crazy to require MIME _and_ eliminate ASCII armor. Regards, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHXQ9S/fy+vkqMxNAQGsDwP+J4Lews16nwWdyqFNloPpaUCcQ6v9SyO3 M9eS3uEJOfITn9AEDOaP73iKda4WapKNJzHqObXCjPmVBvGrOBx0ORW7GFVvI9u/ Yd4v26kli0ZkfxyE0sK3fYwoHxKnLGcS1eEnC0j8SteQsw6yDWIJcVDraoFPq8I6 YsM5bL5uZh0= =QZFb -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA19685 for ietf-open-pgp-bks; Fri, 21 Nov 1997 08:22:57 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA19677 for ; Fri, 21 Nov 1997 08:22:46 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Nov 1997 16:23:29 +0000 Message-ID: <3475B4C7.4715D8A9@cs.ucl.ac.uk> Date: Fri, 21 Nov 1997 16:20:23 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: "David P. Kemp" CC: IETF OpenPGP Subject: Re: CMR References: <199711211612.LAA06971@argon.ncsc.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > So you accept it as a given that shredding evidence is appropriate and > desirable behavior in a free society? Even if said shredding is > conducted by the White House (or #10 Downing Street)? No, I don't. But as PGP Inc are pushing CMR as a corporate solution which gives the ability to snoop on employees' e-mail, I just wanted to point out one of the negative consequences for such unethical companies ;-) Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA18260 for ietf-open-pgp-bks; Fri, 21 Nov 1997 07:17:35 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA18255 for ; Fri, 21 Nov 1997 07:17:31 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id KAA10974; Fri, 21 Nov 1997 10:16:10 -0500 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id KAA19836; Fri, 21 Nov 1997 10:16:09 -0500 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA67240; Fri, 21 Nov 1997 10:16:08 -0500 From: Uri Blumenthal Message-Id: <9711211516.AA67240@watpub1.watson.ibm.com> Subject: Re: Armour To: jon@pgp.com (Jon Callas) Date: Fri, 21 Nov 1997 10:16:08 -0500 (EST) Cc: I.Brown@cs.ucl.ac.uk, jon@pgp.com, stewarts@ix.netcom.com, aba@dcs.ex.ac.uk, ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971120173237.00b93640@mail.pgp.com> from "Jon Callas" at Nov 20, 97 05:32:37 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas says: > Armour was a very necessary part of PGP. But now we have MIME, which is > meant for the same purpose - safely transmitting binary data across > 7-bit or less mail systems. > > There are a number of places where having an armored binary object is > useful. Mail is one. Network transport is another. Any place where the > receiving program is a C program is a third (anyone who is careless enough > to call strfoo intead of memfoo can hurt themselves, and this is a hard bug > to find -- I know, I've done it). Let me summarize. MIME-things can use PGP. But MIME doesn't have to use PGP - there could be other, alternative tools. PGP-things may use MIME. But they may use other tools. Thus, both PGP and MIME need to be able to cope with armouring objects they deal with, independently from each other. Of course, when PGP is used *with* MIME, it is enough to armour only once - but PGP does not *force* you to armour, does it... What's the problem? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA14402 for ietf-open-pgp-bks; Fri, 21 Nov 1997 03:33:15 -0800 (PST) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA14397 for ; Fri, 21 Nov 1997 03:33:08 -0800 (PST) Received: from mothership (p.funk.org [194.109.61.126]) by smtp1.xs4all.nl (8.8.6/XS4ALL) with SMTP id MAA15884 for ; Fri, 21 Nov 1997 12:34:03 +0100 (MET) Message-Id: <3.0.3.32.19971121123331.0095add0@mail.xs4all.nl> X-Sender: alexlh@mail.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 21 Nov 1997 12:33:31 +0100 To: ietf-open-pgp@imc.org From: Alex Le Heux Subject: Ancient Technology Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been following the discussion about AsciiArmour and MIME for a while now, and I note some similarities with the storms of protest I got when I started using PGP 5.0. In an ever faster changing world of computers regular users of PGP seem to be very reluctant to change anything. When something new comes along (or threatens to come along as is the case here), PGP users everywhere seem to reject it immediately. There are some people who _still_ refuse to upgrade to version 5.0 because 'it sucks'. The same argument seems to be applied to MIME here. This may be true, but MIME is infinitely better than Yet-Another-Way-To-Encode-Things. The defacto standard for sending anything but plain-text-English emails is MIME. Ascii Armour is from the time that UUEncoding was the hip thing. The mailreaders of 99% of the internet users today already understand MIME, they don't understand AA, so adding support for PGP/MIME to them should be trivial. Of course there is a strong case for continuing support for AA (backwards compatibility and all that), but the new standard should not be based on it. It's ancient technology. Alex Le Heux -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNHVje9uYAh4dUSo/EQIMhwCgwZyTO8FbXLeWMfGBZuyT5qehxA0AnRKS 6LZfyHJbaIEiS1OVlp82aHJ/ =e6Vt -----END PGP SIGNATURE----- --- atrak: Don't tickle me while I'm thinking! Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA14337 for ietf-open-pgp-bks; Fri, 21 Nov 1997 03:26:54 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA14329 for ; Fri, 21 Nov 1997 03:26:43 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id NAA16131; Fri, 21 Nov 1997 13:54:15 +0100 (MET) Message-ID: <3475709B.52A5DC4@systemics.com> Date: Fri, 21 Nov 1997 11:29:31 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: CMR & ROT-13 (Re: Draft comments) References: <199711201952.TAA01904@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > > Ian Brown writes: > > "Additional request recipients" - as this is still such a controversial > > topic, I don't think it should be included in this first version of the > > standard. > > Seconded. > > Please let's concentrate on the core functionality without dragging in > controversial "message recovery" features. I must have missed the start of this conversation. I think there has been a lot of discussion on the issue. When the CMR thing hit the mailgroups, traffic jumped from about 2 a day (on this group) to something like 10 per day (on the subject, that I recorded). It would appear that community remains split on this issue, with the mostly PGP Inc-led proponents squaring off against the mostly Cypherpunk crypto-programmers. This is highly unusual. Normally, technical discussion results in consensus on these forums, as one would expect when one puts many highly expert voices into one confined space. I would suggest that nobody could deny the controversiality of the ARR/CMR feature. If we accept the controversy as something we must deal with, then there appear to be several options: 1. Document the feature, and include views on the pros and cons, in order to guide the future programmer. 2. Document the feature and say nothing. 3. Propose an alternative. 4. Stay silent. The first option means that we have an opinion, and we have to express it in words that will survive the critical assessment of generations of coders. I judge this as too difficult; if there is no consensus in the community, and by extension, no consensus in the WG, then we have no opinion. Further, to write such an opinion will require an unbiased editor, and we have none such. The second, then, avoids the opinion and simply leaves the programmers to pursue at their discretion. Such a tactic would seem innocuous, but is in fact more insiduous than that. Programmers and managers tend to avoid politics. Whilst those here are well versed on the topic, and other in the core crypto community are equally capable of making an independant judgement, not so the rest of the community. Programmers, designers and managers alike look to and IETF standard as a document of guidance. They have neither the time nor the patience to pursue subtleties as they pursue the race to market. If the feature is in there, it will be coded up. The appearance of the feature in the standard is an open and solid endorsement by the WG of the merits of this feature. Coders will give the WG its due. I am guessing that the WG is not happy with silent endorsement of the AAR feature. If it is, then the debate has not shown it, IMHO. Proposal of an alternative is technically plausible, but not appropriate in this forum. We are standards body, seeking to take existing good protocols, tidy them up into a single document and all agree to use this single document. Whilst there are many ways in which we can address the general class of issues in mind, they are all experimental, and it is not our job to sit here and write the methods in advance of market acceptance. That latter approach is the forte of the ISO standards committeess, which have not been shown to be a huge success. That leaves us with the fourth option. Say nothing and do not document it. This of course will be problematic for programmers, as they test their code against 5.x, and discover the strange packets. I don't however see this as a problem, as there is little to stop PGP Inc from publishing a separate document which can become known. As the programmers are coding up the pgp code, and as this feature is only used by PGP Inc code, they know where to ask. One could say a lot more about the difficulties of ignoring a feature in the standard. I've found some objections, such as existing code, conformance with the code base, need for such a feature, and I don't think they are sufficient under this most exceptional of circumstances. I plumb squarely for the fourth option. Say nothing. In summary, I think that the WG can attempt to describe the pros and cons, but we have no obvious means for doing that. Or we can simply document, at the cost of endorsing the feature as a WG supported method. We are not in a position to start hacking in new ideas. Or, we can simply say nothing and leave the feature as a new, untried idea by one commercial venture in the marketplace for Open PGP product. > > 6.2 - I know the inclusion of ROT-n started as a joke - but it's in > > there! Eeeek! > > I thought Jon was joking about these! Remove at once please! Yes, there should be no weakness. I know ROT-n is a joke to some, but if Caeser used it, then so can others. If a test case is needed, it should be plain and open. Not that I think one is. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA12975 for ietf-open-pgp-bks; Fri, 21 Nov 1997 02:31:57 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA12970 for ; Fri, 21 Nov 1997 02:31:52 -0800 (PST) Message-Id: <199711211031.CAA12970@mail.proper.com> Received: (qmail 12919 invoked from network); 21 Nov 1997 10:32:45 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 21 Nov 1997 10:32:45 -0000 Date: 21 Nov 1997 11:23:16 GMT From: Lindsay Mathieson Subject: Re: The case against redundancy and isolation To: "A. Padgett Peterson P.E. Information Security" , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Perhaps I am missing something but why not a MIME module type for >AsciiArmouring ? Its not needed - something that seems to be understated is that ASCII Armouring is identical to the standard MIME encoding (Base64) with the addition of a checksum, and as far as I can tell tht checksum is unneccessary as (some) PGP packets include checksums. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 21, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA12650 for ietf-open-pgp-bks; Fri, 21 Nov 1997 02:04:31 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA12646 for ; Fri, 21 Nov 1997 02:04:27 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Nov 1997 10:05:19 +0000 Message-ID: <34755C2E.4219D908@cs.ucl.ac.uk> Date: Fri, 21 Nov 1997 10:02:22 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: IETF OpenPGP Subject: CMR Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Several people have made the point that, while companies may wish to be able to recover some stored e-mail, they most definitely do NOT want other items to be recoverable in the case of court demands that material be handed over. Microsoft is providing a prime example of this right now. The Department of Justice is using, to great effect, internal Microsoft e-mail to show that they did not originally intend to integrate Internet Explorer with Windows. >From today's news.com dispatches (http://www.news.com/News/Item/0%2C4%2C16676%2C00.html?ndh.idirect): > Through a number of > internal Microsoft communications, the government > attempted to counter the company's contention that > it long intended to integrate the two technologies > and that it clearly conveyed that intention to the > government. > > "The sequence of documents demonstrates not only > that the United States was not on notice of the > alleged 'integration' of Internet Explorer, but that in > fact Internet Explorer was not designed or > 'developed' to be an integrated product with > Windows 95," the government argued. > > The most dramatic piece of evidence submitted was > email sent by [Jim] Allchin, who now heads Microsoft's > personal and business systems group. > > "I don't understand how IE is going to win," Allchin > wrote in an email to Paul Maritz, now group vice > president for Microsoft's platforms and applications > group. "The current path is simply to copy > everything that Netscape does, packaging and > product wise...My conclusion is that we must > leverage Windows more. Treating IE as just an > add-on to Windows [is] losing our biggest > advantage--Windows market share." Your company may take great steps to securely delete such sensitive mail. If it has already travelled over an insecure network, it could be intercepted and stored by a competitor. Encryption will prevent them reading it then. But what if they get a court order demanding you hand over your Corporate Message Recovery Key? If all your mail is also encrypted to this CMRK, you're in trouble. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA12635 for ietf-open-pgp-bks; Fri, 21 Nov 1997 02:04:06 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA12627 for ; Fri, 21 Nov 1997 02:04:01 -0800 (PST) Message-Id: <199711211004.CAA12627@mail.proper.com> Received: (qmail 2439 invoked from network); 21 Nov 1997 10:04:50 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 21 Nov 1997 10:04:50 -0000 Date: 21 Nov 1997 10:55:22 GMT From: Lindsay Mathieson Subject: Re: The Case Against MIME To: "William H. Geiger III" , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >For the majority of e-mail messages that are currently generated >there is >no reason to use MIME formatting including PGP formated messages! There most certainly is. • Any form of rich text and/or attachments must be sent via MIME. • It is extremely useful to be able to separate the signature from the message (aka RFC 1847). • It co-exists comfortably with other encryption standards that use RFC 1847 • It allows for automatic handling of PGP messages with out scanning every message body. OpenPGP is going to be used mainly for email messages, and MIME is the future of email. Lack of support for MIME is not an option for email clients. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 21, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA11040 for ietf-open-pgp-bks; Fri, 21 Nov 1997 01:30:10 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id BAA11036 for ; Fri, 21 Nov 1997 01:30:04 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 21 Nov 1997 09:30:47 +0000 Message-ID: <34755419.D5FF4A96@cs.ucl.ac.uk> Date: Fri, 21 Nov 1997 09:27:53 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jon Callas CC: IETF OpenPGP Subject: Re: Armour References: <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> <3.0.3.32.19971120173237.00b93640@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas wrote: > I mean safely holding an object in any system that can't handle raw binary. > PGP objects (messages, keys, files, etc.) are constructed so as to not have > a lot of known plaintext in them. Whatever your opinion is about this, it's > the way PGP was designed. Phil has explained this to me in detail. This is > also the rationale behind such things as that a V3 private key encrypts the > body of the MPIs but not their length -- the length is known plaintext. I cannot see the relevance of this to the Armour debate. All that armour does is take some binary PGP data and put it in a format which can be used in 7-bit systems. Anyone can trivially reverse the process. It certainly has nothing to do with the security of the underlying data. The binary data is fully secure before it ever sees armour. I'm surprised you seem to be arguing otherwise. Also, as much as I admire Phil, I thought we had agreed that "Phil has spoken - it must be so" was not the attitude this group should take. > There are a number of places where having an armored binary object is > useful. Mail is one. Network transport is another. Where MIME is also available, and does exactly the same job. > Any place where the > receiving program is a C program is a third (anyone who is careless enough > to call strfoo intead of memfoo can hurt themselves, and this is a hard bug > to find -- I know, I've done it). So you're suggesting that programmers can't cope with handling binary data, so we should convert everything to armour format first? > Most of the present key servers, from the HTTP ones to the LDAP ones > transport their keys in armored form. The idea that the key server has to > have a MIME handler in it seems silly. Why is it any sillier than having an armour handler, apart from the fact that you've already implemented one? > PGP objects are not just mail messages. Any data-thingie that you want to > encrypt can be put into PGP format, and if you don't trust raw binary, > armor works. What do you mean by 'trust'? The security of the underlying data? Armouring it doesn't increase that. Or 'trust' the encrypted object will be safely transported across a 7-bit system? Are you saying MIME won't do that? > P is *NOT* an email-encryption > standard, it is a data-object encryption standard (I'm quoting our esteemed > area director here). Of course, the most obvious use of a data-object > encryption standard is to send secure mail, but that is among the uses of > OP, not the sole one. Why are we arguing here? This is precisely the point several people have made. Armour is only relevant to sending binary PGP objects across 7-bit systems, of which mail is vastly the most common. Of course OP is not just an e-mail standard. This is exactly why we shouldn't be making systems largely used for mail transport an integral part of the standard. > There are people who want to put PGP, especially OP, especially a > minimalistic OP into a number of limited environments -- pagers, PDAs, > smart cards (which are still a few years off, as they are *really* > limited). These people need to have a minimal set of things to implement. Again, precisely the argument several people have made. > I think that it is wrong to make MIME a MUST feature. I agree! Did anyone ever say this? I said in my "draft comments" post that I liked the armour description in the draft, which is: > 2.4 Conversion to Radix-64 > > OP's underlying native representation for encrypted messages, signature > certificates, and keys is a stream of arbitrary octets. Some systems > only permit the use of blocks consisting of seven-bit, printable text. > For transporting OP's native raw binary octets through email channels, > a printable encoding of these binary octets is needed. OP provides the > service of converting the raw 8-bit binary octet stream to a stream of > printable ASCII characters, called Radix-64 encoding or ASCII Armor. > > In principle, any printable encoding scheme that met the requirements > of the email channel would suffice, since it would not change the > underlying binary bit streams of the native OP data structures. The OP > standard specifies one such printable encoding scheme to ensure > interoperability. > it is wrong to cut out small developers by > adding complexity and code size Absolutely! This is why armor shouldn't be a MUST! > I'll add as a related note that making MIME a requirement actually helps > PGP Inc. Our toolkit does all the MIME/armor/compression handling > transparently for the caller. We'll just shrug. I feel compelled myself, > though, as editor of this spec to argue for a simple format spec, and then > layer MIME handling on top of it for the benefit of the small developer. I couldn't agree more! I'm delighted it helps PGP Inc.! Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA08414 for ietf-open-pgp-bks; Thu, 20 Nov 1997 22:16:41 -0800 (PST) Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA08410 for ; Thu, 20 Nov 1997 22:16:36 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with UUCP id HAA24270 for ietf-open-pgp@imc.org; Fri, 21 Nov 1997 07:12:44 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id SAA23601 ; Thu, 20 Nov 1997 18:48:31 +0100 Message-ID: <19971120184831.17558@sobolev.rhein.de> Date: Thu, 20 Nov 1997 18:48:31 +0100 From: Thomas Roessler To: ietf-open-pgp@imc.org Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-md5; boundary=X1bOJ3K7DJ5YkBrT X-Mailer: Mutt 0.88.1 In-Reply-To: <199711192313.PAA01421@einstein.bluemoney.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable On November 19 1997, Jeremey Barrett wrote: > With ASCII armored messages, it is immediately obvious to > the recipient that the message was signed or encrypted, > whether or not they have a MIME-capable mail reader. It is > also trivial, with few exceptions, to invoke pgp and > decrypt or verify the message, or to use an sdk and do it > internally. With MIME, it is immediately obvious to the recipient that the message was signed or encrypted, whether or not they may have a PGP-capable mail reader. It is also trivial to use this non-PGP-aware software to handle PGP/MIME signed messages correctly when replying. =20 > I want to be able to send secure email to people who don't > use MIME, that is a very useful feature of PGP in the > context of email, and I don't see any reason at all to not > include ASCII armoring in the draft. I want to be able to send PGP-signed email to mailing lists where not everybody has PGP at hand. Nevertheless, everybody should be able to properly handle my messages (which might quite well include diff(1) output and similar things). Separating the cryptographic signature from the message's content proper is one of the most useful features of multipart/signed messages. > There is an awful lot of utility in ASCII armoring, and it > would be unfortunate to "standardize" it out of future PGP > implementations. Especially considering how bloody easy it > is to implement, relative to PGP/MIME. Oh, a minimal PGP/MIME implementation just hands off the second part of a multipart/encrypted attachment (which is itself application/octet-stream) to pgp ands feeds it output to the MIME parser once again. This could even be done with something like Metamail. multipart/signed isn't a problem at all for MIME implementations - if it doesn't support PGP/MIME, the signature will be handled as an unknown attachment which is absolutely correct. Seeing this from the implementor's side, doing PGP/MIME inside of a MIME-capable MUA is more or less trivial, while hadling application/pgp (aka ASCII armor) attachments properly requires quite a bit of work. > Yes, PGP is about security, and requiring PGP users to use > MIME mail readers does not result in an increase in > security. Quite the opposite. ^^^^^^^^^^^^^^^^^^^ How do you come to this conclusion? I'm actually quite glad to use a MIME and PGP capable Mail User Agent. And yes, I'm using it from my Unix shell. And yes, it's freely available. > IMO ASCII-armored PGP is not a competing standard on encoding > techniques, rather it is an integral part of PGP and security. I beg your pardon - PGP just works fine with binaryly transmitted packet files. tlr --=20 Thomas Roessler =B7 74a353cc0b19 =B7 dg1ktr =B7 http://home.pages.de/~roess= ler/ 1280/593238E1 =B7 AE 24 38 88 1B 45 E4 C6 03 F5 15 6E 9C CA FD DB --X1bOJ3K7DJ5YkBrT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQC1AwUBNHR37j4lAO9ZMjjhAQEshQT+PeQir5a48YUm+vFBLF9jOaGv5O+2Lu4G d9XdG01Gy1MiWXJvzGRxsUb2jZrmUS5yrtLt1NddqLx1s36f2Nbs6/lT1OmiDYKc 8Xpaf8bwsxaq+w041BGB21CLOG3/bZO7d4t1GYKO0GqKcp7SUmP9RDauVn5hplo2 14+QMutPfEZNhONxlOve39amfbeTEWjdWXo0eu5tgfHJHQRdDvac7Q== =Szx9 -----END PGP SIGNATURE----- --X1bOJ3K7DJ5YkBrT-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA04352 for ietf-open-pgp-bks; Thu, 20 Nov 1997 17:36:56 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA04347 for ; Thu, 20 Nov 1997 17:36:51 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id RAA05798; Thu, 20 Nov 1997 17:32:39 -0800 (PST) Message-Id: <3.0.3.32.19971120173237.00b93640@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 20 Nov 1997 17:32:37 -0800 To: Ian Brown , Jon Callas From: Jon Callas Subject: Re: Armour Cc: Bill Stewart , Adam Back , ietf-open-pgp@imc.org In-Reply-To: <346DB3C5.55F6BF9C@cs.ucl.ac.uk> References: <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:37 PM 11/15/97 +0000, Ian Brown wrote: Jon Callas wrote: > From PRZ's first documents, he labeled > armoring as an integral piece of PGP. It's too useful as a generalized > mechanism for holding an object (data, keys, etc.) without having to worry > about what odd thing something will do to your binary. I'm not sure what you mean. Do you mean safely holding an object while it is transmitted by mail? Armour was a very necessary part of PGP. But now we have MIME, which is meant for the same purpose - safely transmitting binary data across 7-bit or less mail systems. I mean safely holding an object in any system that can't handle raw binary. PGP objects (messages, keys, files, etc.) are constructed so as to not have a lot of known plaintext in them. Whatever your opinion is about this, it's the way PGP was designed. Phil has explained this to me in detail. This is also the rationale behind such things as that a V3 private key encrypts the body of the MPIs but not their length -- the length is known plaintext. But I digress. There are a number of places where having an armored binary object is useful. Mail is one. Network transport is another. Any place where the receiving program is a C program is a third (anyone who is careless enough to call strfoo intead of memfoo can hurt themselves, and this is a hard bug to find -- I know, I've done it). Most of the present key servers, from the HTTP ones to the LDAP ones transport their keys in armored form. The idea that the key server has to have a MIME handler in it seems silly. PGP objects are not just mail messages. Any data-thingie that you want to encrypt can be put into PGP format, and if you don't trust raw binary, armor works. Let me say this again, OP is *NOT* an email-encryption standard, it is a data-object encryption standard (I'm quoting our esteemed area director here). Of course, the most obvious use of a data-object encryption standard is to send secure mail, but that is among the uses of OP, not the sole one. There are people who want to put PGP, especially OP, especially a minimalistic OP into a number of limited environments -- pagers, PDAs, smart cards (which are still a few years off, as they are *really* limited). These people need to have a minimal set of things to implement. These are, of course, all the MUST features. This is also why other features like the hash preference are there -- there's no other way an encrypted pager system can advertise that it has only implemented SHA-1. I think that it is wrong to make MIME a MUST feature. It is obvious to me that it is a SHOULD feature, but it is wrong to cut out small developers by adding complexity and code size. I'll add as a related note that making MIME a requirement actually helps PGP Inc. Our toolkit does all the MIME/armor/compression handling transparently for the caller. We'll just shrug. I feel compelled myself, though, as editor of this spec to argue for a simple format spec, and then layer MIME handling on top of it for the benefit of the small developer. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA00669 for ietf-open-pgp-bks; Thu, 20 Nov 1997 13:36:26 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA00665 for ; Thu, 20 Nov 1997 13:36:22 -0800 (PST) Received: from omni.imc.org ([207.94.139.169]) by proper.com (8.8.7/8.7.3) with SMTP id NAA15277; Thu, 20 Nov 1997 13:34:22 -0800 (PST) Message-Id: <199711202134.NAA15277@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Beta 7 (build 224) Date: Thu, 20 Nov 1997 13:37:04 -0800 To: "A. Padgett Peterson P.E. Information Security" From: Dave Crocker / IMC Subject: Re: The case against redundancy and isolation Cc: jeremey@bluemoney.com, ietf-open-pgp@imc.org In-Reply-To: <971120084347.20e0fc99@hobbes.orl.lmco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:43 AM 11/20/97 -0500, A. Padgett Peterson P.E. Information Security wrote: >Perhaps I am missing something but why not a MIME module type for >AsciiArmouring ? >However I also suspect that recognition of the type and provision for >reduction to binary as a single pass would take so little code as to be >negligible (easy for me to say since have not tried to do it 8*). >However I do not understand what the controversy is about since it >seems to be a simple matter of yet another code form. There are two reason for the controversy, which I tried to cover in my previous note and will try to state a bit differently: 1. The incremental effect of more code seems to have exponential, not linear, effects on reducing reliability while increasing deployment time and effort. 2. The features that are in armouring are the same as for MIME. I believe that any features which armouring has which MIME does not either should be discarded or should be added to MIME. The botton line is that one should not propagate multiple ways of doing the same thing. Contrary to your assessment, I'd say that MIME can be used for exactly the same purposes as armouring, as well as some other, possibly more general goals. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA28676 for ietf-open-pgp-bks; Thu, 20 Nov 1997 11:52:38 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA28668 for ; Thu, 20 Nov 1997 11:52:34 -0800 (PST) Received: from server.test.net ([194.168.72.119]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAD4328; Thu, 20 Nov 1997 19:53:26 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id TAA01904; Thu, 20 Nov 1997 19:52:53 GMT Date: Thu, 20 Nov 1997 19:52:53 GMT Message-Id: <199711201952.TAA01904@server.test.net> From: Adam Back To: I.Brown@cs.ucl.ac.uk CC: ietf-open-pgp@imc.org In-reply-to: <3472C7D4.F1097051@cs.ucl.ac.uk> (message from Ian Brown on Wed, 19 Nov 1997 11:04:52 +0000) Subject: CMR & ROT-13 (Re: Draft comments) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Brown writes: > "Additional request recipients" - as this is still such a controversial > topic, I don't think it should be included in this first version of the > standard. Seconded. Please let's concentrate on the core functionality without dragging in controversial "message recovery" features. > 6.2 - I know the inclusion of ROT-n started as a joke - but it's in > there! Eeeek! I thought Jon was joking about these! Remove at once please! Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA23343 for ietf-open-pgp-bks; Thu, 20 Nov 1997 05:43:15 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA23339 for ; Thu, 20 Nov 1997 05:43:11 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EJY0000G659FS@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Thu, 20 Nov 1997 08:43:57 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EJY00C2Y654OR@lmco.com> for ietf-open-pgp@imc.org; Thu, 20 Nov 1997 08:43:52 -0500 (EST) Date: Thu, 20 Nov 1997 08:43:47 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: The case against redundancy and isolation To: jeremey@bluemoney.com Cc: ietf-open-pgp@imc.org Message-id: <971120084347.20e0fc99@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >IMO ASCII-armored PGP is not a competing standard on encoding >techniques, rather it is an integral part of PGP and security. Sorry, I may be a bit dense but do not understand this statement. A PGP-encrypted message may be transmitted in binary or may be converted to an RFC 821/22 compliant form via ASCII Armoring. This may also be done with UUENCODE, XXENCODE, or any of a number of different mechanisms from TekHex to YAAA - all of which were designed to avoid filtering. Now in my worldview, a mailreader or universal decryptor needs to be recursive, that is it needs to examine a file for a format that it recognizes, perform a conversion if necessary, and then examine the result to determine if another conversion needs to be invokes. Further, it should be modular so that new mechanisms may be added or old one removed as desired. My though is that an IETF standard should be flexible in permitting addition of new mechanisms with as little fuss as possible. The main difference I see between AsciiArmouring and MIME is that the former is desinged to enclose a single PGP module while the latter can contain multiple elements which different charactoristics. This IMNSHO is a Good Thing. Perhaps I am missing something but why not a MIME module type for AsciiArmouring ? Personally, I agree that it is something that was added at a time when there were no real standards (though UUENCODE could have been used) and PGP was a command-line standalone. However I also suspect that recognition of the type and provision for reduction to binary as a single pass would take so little code as to be negligible (easy for me to say since have not tried to do it 8*). However I do not understand what the controversy is about since it seems to be a simple matter of yet another code form. Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA20814 for ietf-open-pgp-bks; Thu, 20 Nov 1997 02:29:00 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id CAA20809; Thu, 20 Nov 1997 02:28:55 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 20 Nov 1997 10:29:30 +0000 Message-ID: <34741070.3FA083F9@cs.ucl.ac.uk> Date: Thu, 20 Nov 1997 10:26:56 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jeremey Barrett CC: Dave Crocker / IMC , ietf-open-pgp@imc.org Subject: Re: The case against redundancy and isolation References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> <199711192313.PAA01421@einstein.bluemoney.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jeremey Barrett wrote: > Let me clarify my position a bit. I think MIME is great, and PGP/MIME > is great. Both are necessary and I even use them from time to time. > However, I _don't_ use them for most email, by choice, because it > simply isn't useful. I think several people have already given good reasons why they are useful to *them*. Their utility will improve in time, as Dave Crocker has already said. We *certainly* don't want to have to keep developing armour in parallel to MIME every time a new feature (e.g. Unicode) is needed. > There is an awful lot of utility in ASCII armoring, and it would be > unfortunate to "standardize" it out of future PGP implementations. > Especially considering how bloody easy it is to implement, relative > to PGP/MIME. Really, you shouldn't have to do much work at all to implement MIME. The mailer should be able to handle 99% of the encoding. You should be able to say "Here is some binary data; its MIME type is x" - and that's all there would be to it. As Dave said: > One argument for retaining the separate, PGP-specific mechanisms is that > they aren't very expensive. This shows a misunderstanding of the cost of > having multiple solutions to the same problem. Each can be incrementally > cheap, but the combination is a pain and, more importantly, is frequently > the source of software errors. Besides that, a single-implementation cost > that is small is made considerable more expensive when replicated across > many products. I occasionally send GIF files to people by e-mail. The only way to do this is to use a MIME attachment. There aren't specifications for "GIF armour" anywhere. > I want to be able to send secure email to people who don't use MIME, > that is a very useful feature of PGP in the context of email, and I > don't see any reason at all to not include ASCII armoring in the draft. I agree. In the appendix is fine. > Yes, PGP is about security, and requiring PGP users to use MIME mail > readers does not result in an increase in security. Quite the > opposite. Could you please describe to us the security holes in MIME, and why they are not present in Armour? Ian Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA19340 for ietf-open-pgp-bks; Thu, 20 Nov 1997 02:00:08 -0800 (PST) Received: from aun.uninett.no (aun.uninett.no [129.241.1.99]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA19335 for ; Thu, 20 Nov 1997 02:00:01 -0800 (PST) Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Thu, 20 Nov 1997 10:59:49 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id GAA25747; Thu, 20 Nov 1997 06:10:26 +0100 From: Harald.T.Alvestrand@uninett.no To: "William H. Geiger III" cc: Ian Brown , Thomas Roessler , IETF OpenPGP Subject: Re: The Case Against MIME In-reply-to: Your message of "Wed, 19 Nov 1997 11:40:49 CST." <199711191742.MAA06086@users.invweb.net> Date: Thu, 20 Nov 1997 06:10:25 +0100 Message-ID: <25745.880002625@dale.uninett.no> MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: quoted-printable Content-ID: <25742.880002624.1@dale.uninett.no> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >For the majority of e-mail messages that are currently generated there is >no reason to use MIME formatting including PGP formated messages! For the majority of e-mail messages generated in English, failing to use any text formatting function apart from CR LF, failing to have the characters "From " at the start of a line, and failing to include any attachment whatsoever, your statement is true, but irrelevant. Come on!!!!! THINK!!!!!!!! Harald T. Alvestrand the guy with a son named Torbj=F8rn Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA16802 for ietf-open-pgp-bks; Wed, 19 Nov 1997 21:57:52 -0800 (PST) Received: from mail.the-wire.com (mail.the-wire.com [198.53.192.5]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA16798 for ; Wed, 19 Nov 1997 21:57:47 -0800 (PST) Received: from [205.206.36.71] (rguerra.the-wire.com [205.206.36.71]) by mail.the-wire.com (8.8.8/8.8.8) with ESMTP id AAA14957; Thu, 20 Nov 1997 00:57:34 -0500 (EST) X-Sender: az096@freenet.toronto.on.ca (Unverified) Message-Id: In-Reply-To: <346BACCD.7E364E8B@systemics.com> Mime-Version: 1.0 X-PGP-RSAkey: http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0x89619BC5 X-PGP-DSSkey: http://keys.pgp.com:11371/pks/lookup?op=index&search=0x4B408E7B Date: Thu, 20 Nov 1997 00:58:15 -0500 To: ietf-open-pgp@imc.org From: Robert Guerra Subject: CTC-PGP5 - Interoperability Cc: webmaster@bifroest.demon.co.uk Content-Type: multipart/signed; boundary="=-=---=-====--==----=-==---=-====--=-==-===--==="; protocol="application/pgp-signature"; micalg=pgp-sha1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --=-=---=-====--==----=-==---=-====--=-==-===--=== Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I'm not sure if this is the right place for this....but as it is related to pgp and a non-pgp.com implementation of PGP perhaps it is... regards robert CTC-PGP5 - Interoperability If you have PGP5 working and can send me so specimen output please e-mail. When we embarked on this, we had no documentation of the formats, and have been working largely on our own analysis of samples and the released source. However there are now a number of documents available from the OpenPGP Working Group in the IETF. These include:- PGP Inc.'s initial documentation of PGP Message Exchange Formats RFC 1991, PGP Message Exchange Formats RFC 2015, MIME Security with Pretty Good Privacy (PGP) We view achieving maximum interoperability with all other PGP-format encryption software very important. PGP5.0 is currently very important. CTC Approach This out-lines how we intend to handle these changes and the facilities we intend including:- General We are far more concerned with inter-site interoperatibility than with individuals being able to use more than one program on the same files on a single machine. In the short term at least, we will be primarily interested in formats routinely transmitted between sites (normally encrypted files, public keys and signatures) than formats that normally stay on the site of origin (conventional encrypted files and secret keys). We are also far more interested in reading all formats than writing all formats. All PGP-compatible variants in use will read Version 3 (PGP2.6) formats. However in some cases, notably storing new format keys in key-rings, writing packets is also necessary for effective interoperability. Progress We now have all the basic operations necessary for inter-operability coded and to at least some extent working. We cannot claim that any of these are really "tested". The main problem is a lack of software to test it against. CTB format We have implemented:- the correct reading of new-style CTB. We ultimately intend to implement:- the writing of new-style CTBs for record types greater than 15 only. Version 4 packets We have implemented:- Reading version 4 public key certificates Reading sub-key certificates Reading version 4 signature (SKE) packets Writing all of the above packets There are no immediate plans to provide for generating, reading, writing or using DSA/D-H secret keys. Operations We have implemented the following operations:- 3-DES encryption/decryption DSA signature verification D-H encryption New style (SHA-1 fingerprint based) calculation of key Id.s. Difficulties We don't have a CAST implementation. We need people with working version of PGP5 to help us with testing. webmaster@bifroest.demon.co.uk "They say that we are yesterday's men. They say that we represent yesterday's ideas and values. All I can say is that perhaps it is better than today's men, who have no ideas, and no values." -- Pierre E. Trudeau. Robert Guerra - PGP public key available on PGP key servers Email-> mailto:az096@freenet.toronto.on.ca Home Page-> http://www.geocities.com/CapitolHill/3378 --=-=---=-====--==----=-==---=-====--=-==-===--=== Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: PGP for Personal Privacy 5.5 iQA/AwUBNHPRi4PIpEZLQI57EQKPYgCaAsbk2Vz0SV2T9uhu06V/L1eHZOEAni85 jENLGnXiotNyugSBpeWTvbVn =TIyB -----END PGP MESSAGE----- --=-=---=-====--==----=-==---=-====--=-==-===--===-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13232 for ietf-open-pgp-bks; Wed, 19 Nov 1997 15:10:46 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13227; Wed, 19 Nov 1997 15:10:41 -0800 (PST) Received: from server.test.net ([194.168.67.217]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA5819; Wed, 19 Nov 1997 23:11:22 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id XAA06209; Wed, 19 Nov 1997 23:02:04 GMT Date: Wed, 19 Nov 1997 23:02:04 GMT Message-Id: <199711192302.XAA06209@server.test.net> From: Adam Back To: dcrocker@imc.org CC: ietf-open-pgp@imc.org In-reply-to: <4.0.32.19971119135513.00e95d80@imc.org> (message from Dave Crocker / IMC on Wed, 19 Nov 1997 14:11:31 -0800) Subject: Re: The case against redundancy and isolation Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Dave Crocker / IMC writes: > PGP is about security. All of the wrapping and encoding mechanisms in PGP > were developed because none were available at the time it was first > developed. Things have changed. There are now standards to cover these > requirements. This means that PGP can focus on doing what it needs to do, > namely security, and it need no longer be burdened with assorted baggage > for segmenting and labeling the data or for protecting it against the > vagaries of transport. > > MIME does all that. The only remaining problem is cut and paste situations... encrypt to clipboard, etc. I guess you could MIME those too. Thinking about clear text signatures (pgp -sat) does MIME have a way to do text without putting = on the end of each line, and similarly breaking other symbols? (I found that most irksome, and generally skip MIME munged articles to majordomo lists.) > Why would you want to perpetuate unique, non-standard ways of doing > something that is both already covered in existing standards which are in > real use and getting more used? I agree. People are focussing on backwards compatibility with ascii armor. Backwards compatibility is already broken in the MUST section. So armor can be another SHOULD or MAY, or simply an appendix as suggested. This does not mean that vendors won't implement armor; just that they won't _have_ to implement it. Doesn't sound that controversial to me. William Geiger is free to implement it. Systemics implements it already. PGP will probably keep it too. > ps. I have the same line of argument against S/MIME's use of ASN.1, > and am intrigued to see whether this group is similarly > uncooperative towards true integration with Internet mail and web > standards... Ugh, please not! ASN.1 truly does suck. Let's keep things away from ASN.1. I would have thought one of the main advantages OpenPGP has over S/MIME is that it doesn't currently go overboard on ASN.1. Faced with implementing one of the two -- I know I would plump for the one which avoids ASN.1 other things being equal. Any ASN.1 crapola should be in an appendix. Include the hex for magic strings which go inside PKE packets. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA13219 for ietf-open-pgp-bks; Wed, 19 Nov 1997 15:10:15 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA13213; Wed, 19 Nov 1997 15:10:10 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id PAA01421; Wed, 19 Nov 1997 15:13:47 -0800 Date: Wed, 19 Nov 1997 15:13:47 -0800 Message-Id: <199711192313.PAA01421@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Dave Crocker / IMC Cc: ietf-open-pgp@imc.org Subject: Re: The case against redundancy and isolation In-Reply-To: <4.0.32.19971119135513.00e95d80@imc.org> References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> <34735568.EC8E12D1@cs.ucl.ac.uk> <4.0.32.19971119135513.00e95d80@imc.org> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Let me clarify my position a bit. I think MIME is great, and PGP/MIME is great. Both are necessary and I even use them from time to time. However, I _don't_ use them for most email, by choice, because it simply isn't useful. Instead, I clearsign everything (and occasionally encrypt). With ASCII armored messages, it is immediately obvious to the recipient that the message was signed or encrypted, whether or not they have a MIME-capable mail reader. It is also trivial, with few exceptions, to invoke pgp and decrypt or verify the message, or to use an sdk and do it internally. Futher, ASCII armored messages can be shipped off to things that don't understand MIME at all. I want to be able to send secure email to people who don't use MIME, that is a very useful feature of PGP in the context of email, and I don't see any reason at all to not include ASCII armoring in the draft. There is an awful lot of utility in ASCII armoring, and it would be unfortunate to "standardize" it out of future PGP implementations. Especially considering how bloody easy it is to implement, relative to PGP/MIME. Dave Crocker / IMC writes: > > PGP is about security. All of the wrapping and encoding mechanisms in PGP > were developed because none were available at the time it was first > developed. Things have changed. There are now standards to cover these > requirements. This means that PGP can focus on doing what it needs to do, > namely security, and it need no longer be burdened with assorted baggage > for segmenting and labeling the data or for protecting it against the > vagaries of transport. Yes, PGP is about security, and requiring PGP users to use MIME mail readers does not result in an increase in security. Quite the opposite. > > MIME does all that. > > Why would you want to perpetuate unique, non-standard ways of doing > something that is both already covered in existing standards which are in > real use and getting more used? IMO ASCII-armored PGP is not a competing standard on encoding techniques, rather it is an integral part of PGP and security. Regards, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHNypy/fy+vkqMxNAQHJRgQAshf3peCjaP5rccFvSfA/zndKUo2d1YAW FfLL+tyTSExY0hFY3ji6v0tT2E8/3dE3bGVJBv2ZTxM45RAh7laNhfAz61NH+7OB jAEpcuHaagN+qL9Q6t9AhlHVpxzDTvuyVGgcgGMBGWuTrFdvW02oo+AyEOtYA0ah 5uPGCFOFCQY= =1lW5 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA12568 for ietf-open-pgp-bks; Wed, 19 Nov 1997 14:19:34 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA12560 for ; Wed, 19 Nov 1997 14:19:30 -0800 (PST) Received: from omni.imc.org (d65.netgate.net [205.214.160.101]) by proper.com (8.8.7/8.7.3) with SMTP id OAA12753; Wed, 19 Nov 1997 14:15:21 -0800 (PST) Message-Id: <199711192215.OAA12753@proper.com> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Beta 7 (build 224) Date: Wed, 19 Nov 1997 14:16:55 -0800 To: "John W. Noerenberg" From: Dave Crocker / IMC Subject: Re: Armour Cc: Ian Brown , Jon Callas , Bill Stewart , Adam Back , ietf-open-pgp@imc.org In-Reply-To: References: <346DB3C5.55F6BF9C@cs.ucl.ac.uk> <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:29 PM 11/15/97 -0800, John W. Noerenberg wrote: >>I'm not arguing that we should totally do away with armour - just that I >>don't think it should be a MUST, so that people who want to use OpenPGP ... >This is probably closest to my own point of view, Ian. The ability to >generate and accept ascii armor must be preserved for backwards >compatibility. However, successfully encoding and decoding a message >should not mandate translation through ascii armor. Let me suggest that the cleanest way to handle this is by including its specification in an appendix, with a note explaining that is has been used in the past and that the capabilities defined in the appendix are needed for processing data from these earlier (pre-standards) systems. This puts the old armouring mechanism outside of the formal standard but keeps people informed about its existance and details, and the reason it might be useful. d/ -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA12531 for ietf-open-pgp-bks; Wed, 19 Nov 1997 14:17:19 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA12527 for ; Wed, 19 Nov 1997 14:17:14 -0800 (PST) Received: from omni.imc.org (d65.netgate.net [205.214.160.101]) by proper.com (8.8.7/8.7.3) with SMTP id OAA12750 for ; Wed, 19 Nov 1997 14:15:19 -0800 (PST) Message-Id: <4.0.32.19971119135513.00e95d80@imc.org> Message-Id: <4.0.32.19971119135513.00e95d80@imc.org> X-Sender: dhcmail@imc.org X-Mailer: QUALCOMM Windows Eudora Pro 4.0 Beta 7 (build 224) Date: Wed, 19 Nov 1997 14:11:31 -0800 To: ietf-open-pgp@imc.org From: Dave Crocker / IMC Subject: The case against redundancy and isolation In-Reply-To: <34735568.EC8E12D1@cs.ucl.ac.uk> References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Folks, All of this discussion about MIME and amouring is facinating. The fundamental question about MIME vs. non-MIME and, in general, about behaving like an independent activity, versus integrating with existing Internet standards, is the question of participation. Does this group want to participate in the suite of Internet technology standards or does it want to act in isolation and require that it provide all its own tools? One comment was that MIME sucks. While not the most professional language, it is and entirely accurate technical assessment, in my opinion. What that assessment lacks is an understanding that MIME mostly sucks due to very careful (and, I believe, necessary) engineering. More importantly, sucky little MIME has become the lingua franca for object labeling and aggregation on the Internet. It is used by email and it is used by the Web. There ain't much else. Observations that you don't "need" MIME in various circumstances or that MIME is not used all the time are entirely true, but they again miss the point. MIME is a relatively new standard and it is being adopted. "Being adopted" means that its use in not total but that it is increasing. Arguing that some people don't use it now is no argument against having it as a basis for a new standards effort. Paying attention to the installed based is very important. (It's even one of the reasons that MIME sucks.) But "paying attention" does not mean doggedly shooting oneself in the foot. As noted by others, you already have other incompatibilities. This is either a problem or an opportunity. PGP is about security. All of the wrapping and encoding mechanisms in PGP were developed because none were available at the time it was first developed. Things have changed. There are now standards to cover these requirements. This means that PGP can focus on doing what it needs to do, namely security, and it need no longer be burdened with assorted baggage for segmenting and labeling the data or for protecting it against the vagaries of transport. MIME does all that. Why would you want to perpetuate unique, non-standard ways of doing something that is both already covered in existing standards which are in real use and getting more used? One argument for retaining the separate, PGP-specific mechanisms is that they aren't very expensive. This shows a misunderstanding of the cost of having multiple solutions to the same problem. Each can be incrementally cheap, but the combination is a pain and, more importantly, is frequently the source of software errors. Besides that, a single-implementation cost that is small is made considerable more expensive when replicated across many products. Why not, instead, use the standards-based mechanisms for doing the ancillary work, and then enjoy the opportunity to focus on the real requirement, namely security? d/ ps. I have the same line of argument against S/MIME's use of ASN.1, and am intrigued to see whether this group is similarly uncooperative towards true integration with Internet mail and web standards... -------------------- Dave Crocker dcrocker@imc.org Internet Mail Consortium +1 408 246 8253 675 Spruce Dr. fax: +1 408 249 6205 Sunnyvale, CA 94086 USA info@imc.org , http://www.imc.org Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA11524 for ietf-open-pgp-bks; Wed, 19 Nov 1997 13:11:16 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA11517 for ; Wed, 19 Nov 1997 13:11:11 -0800 (PST) Received: from thames.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Nov 1997 21:11:32 +0000 Received: from cs.ucl.ac.uk (actually dopey.cs.ucl.ac.uk) by thames.cs.ucl.ac.uk with SMTP (PP); Wed, 19 Nov 1997 21:11:27 +0000 Message-ID: <34735568.EC8E12D1@cs.ucl.ac.uk> Date: Wed, 19 Nov 1997 21:08:56 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jeremey Barrett CC: "William H. Geiger III" , ietf-open-pgp@imc.org Subject: Re: The Case Against MIME References: <199711191514.KAA04597@users.invweb.net> <199711191815.KAA00834@einstein.bluemoney.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jeremey Barret wrote: > Plain old non-MIME ASCII-armored PGP is one of the most > useful crypto tools out there, not to mention the sole basis of PGP > integration into most mail readers that support it. This actually misses one of the main benefits of MIME. In almost all cases, a MIME-compliant mailer will do the decoding for you. If PGP/MIME had a specific pgp-data type bodypart, *any* MIME-compliant mailer would be configurable, upon receiving such a bodypart, to: a) Remove the base64 (or whatever) encoding and b) present the resulting binary data to any OP/PGP program William Geiger wrote: > As far as KISS what can be more simpler than rfc822 with a PGP Ascii > Armor Block? Binary data handed straight to your program? This has further benefits: Greg Vaudreuil wrote: > One of the strongest reasons to use MIME encoding, even for plain text > messages is MIME's ability to support multiple languages and character > sets. While I am new to PGP, I do not believe that multi-lingual > support is part of PGP 2.6.X. There is some support for using different codepages for text. But Greg points to the main problem with continued use of armour - we have to continue solving exactly the same problems as the MIME people. Different character sets (Unicode would be very useful, for instance), multi-part messages, and so on are issues armour and MIME both have to deal with. Why not just leverage the work the MIME people are doing? > Multilingual support is an IESG requirement for all IETF protocols > going forward. At a minimum this requires identification of the > selected character set, and in the mail context, a way to encooding > these 8 or 16 bit characters into a 7 bit transfer format such as > Quoted Printable. I don't think PGP has an easy method of encoding 16-bit systems such as Unicode. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA09154 for ietf-open-pgp-bks; Wed, 19 Nov 1997 10:25:20 -0800 (PST) Received: from gw3.octel.com (gw3.octel.com [148.147.1.15]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA09148 for ; Wed, 19 Nov 1997 10:25:16 -0800 (PST) From: greg.vaudreuil@octel.com Received: (from daemon@localhost) by gw3.octel.com (8.6.10/8.6.12) id KAA00299; Wed, 19 Nov 1997 10:24:56 -0800 Received: from curly.eng.octel.com(148.147.200.26) by gw3.octel.com via smap (V1.3) id sma029949; Wed Nov 19 10:24:30 1997 Received: from elroy.corp.octel.com (elroy.corp.octel.com [148.147.20.25]) by curly.eng.octel.com (8.6.12/8.6.12) with ESMTP id KAA14393; Wed, 19 Nov 1997 10:24:29 -0800 Received: from nt-ima2.corp.octel.com by elroy.corp.octel.com with SMTP (1.40.112.4/16.2) id AA258343868; Wed, 19 Nov 1997 10:24:28 -0800 Received: from ccMail by nt-ima2.corp.octel.com (IMA Internet Exchange 2.1 Enterprise) id 002544CD; Wed, 19 Nov 97 10:22:26 -0800 Mime-Version: 1.0 Date: Wed, 19 Nov 1997 11:39:50 -0800 Message-Id: <002544CD.3389@corp.octel.com> To: Thomas Roessler , Ian Brown Cc: IETF OpenPGP Subject: Re[2]: The Case Against MIME Content-Type: multipart/mixed; boundary="IMA.Boundary.647369978" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --IMA.Boundary.647369978 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part One of the strongest reasons to use MIME encoding, even for plain text messages is MIME's ability to support multiple languages and character sets. While I am new to PGP, I do not believe that multi-lingual support is part of PGP 2.6.X. Plain text email which makes up most domestic US email is not MIME encoded and uses the defined default USASCII character set and the English language. This probably is not a valid assumption for the Internet as a whole. Multilingual support is an IESG requirement for all IETF protocols going forward. At a minimum this requires identification of the selected character set, and in the mail context, a way to encooding these 8 or 16 bit characters into a 7 bit transfer format such as Quoted Printable. Greg V. --IMA.Boundary.647369978 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: inline; filename="RFC822 message headers" Received: from curly.eng.octel.com (148.147.200.26) by m-internet.corp.octel.com with SMTP (IMA Internet Exchange 2.1 Enterprise) id 00305335; Wed, 19 Nov 97 09:05:20 -0800 Received: from gw3.octel.com (gw3.octel.com [148.147.1.15]) by curly.eng.octel.com (8.6.12/8.6.12) with ESMTP id JAA09676 for ; Wed, 19 Nov 1997 09:18:25 -0800 Received: (from daemon@localhost) by gw3.octel.com (8.6.10/8.6.12) id JAA19152 for ; Wed, 19 Nov 1997 09:17:53 -0800 Received: from mail.proper.com(206.86.127.224) by gw3.octel.com via smap (V1.3) id sma018907; Wed Nov 19 09:17:35 1997 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA07210 for ietf-open-pgp-bks; Wed, 19 Nov 1997 08:22:00 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA07202 for ; Wed, 19 Nov 1997 08:21:39 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Nov 1997 16:22:18 +0000 Message-ID: <347311A5.2883320@cs.ucl.ac.uk> Date: Wed, 19 Nov 1997 16:19:49 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Thomas Roessler CC: IETF OpenPGP Subject: Re: The Case Against MIME References: <199711191514.KAA04597@users.invweb.net> <34730B77.61958AD9@cs.ucl.ac.uk> <19971119170320.58254@sobolev.rhein.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --IMA.Boundary.647369978-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA09125 for ietf-open-pgp-bks; Wed, 19 Nov 1997 10:24:28 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA09108 for ; Wed, 19 Nov 1997 10:24:23 -0800 (PST) Received: from users.invweb.net (ppp30.dotstar.net [208.143.93.49]) by users.invweb.net (8.8.7/8.8.7) with SMTP id NAA06572; Wed, 19 Nov 1997 13:24:25 -0500 Message-Id: <199711191824.NAA06572@users.invweb.net> From: "William H. Geiger III" Date: Wed, 19 Nov 97 12:08:58 -0600 To: lutz@taranis.iks-jena.de (Lutz Donnerhacke) In-Reply-To: Cc: ietf-open-pgp@imc.org Subject: Re: Ascii Armor solution? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 11/19/97 at 05:50 PM, lutz@taranis.iks-jena.de (Lutz Donnerhacke) said: >* William H. Geiger III wrote: >>I will release my subroutines w/source for ascii-armor encoding/decoding >>into the public domain. That way everyone will have them available to use >>as they wish free of charge. >> >>Will this be an acceptable solution to the "problem"?? >No. The problem is not programming efforts (which is quite simple to >handle), the problem is the KISS principle. Ascii Armor is simply >outdated. Well I don't believe that the case has been made that Ascii Armor is outdated. As far as KISS what can be more simpler than rfc822 with a PGP Ascii Armor Block? Not to mention the fact that everyone currently using PGP can read it. Sorry but those wishing to drop Ascii-Armor have not made a cost/benefit case (ie the cost of droping ascii armor out weigh the benefits of doing so). - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNHMugI9Co1n+aLhhAQGW8gP+IAo6oCNcQ/MTA529GnxyhQasvD9a0+F8 ZL6d6uiM7YLTQgxClUW04eMfQxI8uLGvEyhSZvLMKLx5IuuooIDSs8lv4TysrH4w qhhHu81FfYCqrSUqEA5ZkQQpHBhWwr5f3MrTLRwcA4UHKyMOYJP1CUbZ6VsfnKof RDiU4n4GQR4= =8ScT -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA08908 for ietf-open-pgp-bks; Wed, 19 Nov 1997 10:11:44 -0800 (PST) Received: from einstein.bluemoney.com (einstein.bluemoney.com [204.162.247.69]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA08903 for ; Wed, 19 Nov 1997 10:11:39 -0800 (PST) Received: (from jeremey@localhost) by einstein.bluemoney.com (8.8.5/8.6.9) id KAA00834; Wed, 19 Nov 1997 10:15:05 -0800 Date: Wed, 19 Nov 1997 10:15:05 -0800 Message-Id: <199711191815.KAA00834@einstein.bluemoney.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "William H. Geiger III" Cc: ietf-open-pgp@imc.org Subject: Re: The Case Against MIME In-Reply-To: <199711191514.KAA04597@users.invweb.net> References: <199711191514.KAA04597@users.invweb.net> X-Mailer: VM 6.22 under 19.15 XEmacs Lucid From: Jeremey Barrett Organization: BlueMoney Software Corp. Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- William H. Geiger III writes: > > There seems to be several members that are in favor of dropping Ascii > Armour, and MIME formatting all PGP messages. > > I would like to present the case that this is not necessary nor even > recommended! > > The majority of PGP users are using 2.6.x and will be for a long time to > come. This is fact regardless of wether one likes it or not. Switching > formats for the sake of some MIME "purity" at the expense of compatibility > is a foolhardy gesture. Absolutely. Plain old non-MIME ASCII-armored PGP is one of the most useful crypto tools out there, not to mention the sole basis of PGP integration into most mail readers that support it. Frankly, MIME sucks. PGP/MIME is needed for those (very) rare occasions when one needs to encrypt MIME attachments, etc, but it is not useful in 90% of email. Making it the only way to send PGP email is just plain dumb IMHO. Regards, Jeremey. - -- Jeremey Barrett BlueMoney Software Corp. Crypto, Ecash, Commerce Systems http://www.bluemoney.com/ PGP key fingerprint = 3B 42 1E D4 4B 17 0D 80 DC 59 6F 59 04 C3 83 64 -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBNHMsny/fy+vkqMxNAQEotwP/QI3nK3HTSRrBiBbFJtymp5tZJD1UFfeF mQuUISxUCneyskwmzjrcTIdVa94k4AMql6hzSadxTI+Bm+JrKz4ePQ6v+SpWsSm6 k1z2duTAszjNVpK0POm6uFzFpj0A8L3E0zueNA6lCyJezTyEuvc6CNmtwml7egB6 LAi39dNJRkE= =x1o6 -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08742 for ietf-open-pgp-bks; Wed, 19 Nov 1997 09:58:27 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08738 for ; Wed, 19 Nov 1997 09:58:20 -0800 (PST) Received: from users.invweb.net (ppp30.dotstar.net [208.143.93.49]) by users.invweb.net (8.8.7/8.8.7) with SMTP id MAA06261; Wed, 19 Nov 1997 12:58:49 -0500 Message-Id: <199711191758.MAA06261@users.invweb.net> From: "William H. Geiger III" Date: Wed, 19 Nov 97 11:50:17 -0600 To: Ian Brown In-Reply-To: <347323FB.B99EC09D@cs.ucl.ac.uk> Cc: "William H. Geiger III" , ietf-open-pgp@imc.org Subject: Re: Ascii Armor solution? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <347323FB.B99EC09D@cs.ucl.ac.uk>, on 11/19/97 at 12:38 PM, Ian Brown said: >> I have a proposal for the group in a effort to put the Ascii-Armor >> question to rest. >> >> I will release my subroutines w/source for ascii-armor encoding/decoding >> into the public domain. That way everyone will have them available to use >> as they wish free of charge. >> >> Will this be an acceptable solution to the "problem"?? >Such freely available toolkits already exist (see, for example, >http://www.systemics.com/software/cryptix-java/) >This does not alter the fact that implementors would need to download, >understand, and adapt such code to work in their subsequently bloated >application. This has to be the silliest of excuses for not incorporating Ascii-Armour. Exactly how many extra lines of code do you think it will take to implement?? Compare that to the size of any Open-PGP implementation and anyone can see this is a non-issue. BTW: I did get a chuckle of you using a Java lib as an example. Anyone writting a Java based app has bigger bloat problems than a couple of ascii-armour routines to worry about. :) - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNHMogY9Co1n+aLhhAQFrZQQAkrYWAVhPTFRFyrs7sl82NJJ31yKUTrd/ ke9kJjKKLOwYEXuWwKLJljGozSjUn8q8kvNgN/ZTSBJQTcTxR1KnZfZAvhMKIrBc wDZsDHpISnkmBT+l3K65kEE1l/cNnSMCdslWMBy/GEls825JnJyeXW8Xtjlu4b4k gpzPAPVNXt4= =WvaI -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08610 for ietf-open-pgp-bks; Wed, 19 Nov 1997 09:49:35 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08605 for ; Wed, 19 Nov 1997 09:49:28 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id SAA14552; Wed, 19 Nov 1997 18:50:12 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Ascii Armor solution? Date: 19 Nov 1997 17:50:12 GMT Organization: IKS GmbH Jena Lines: 9 Message-ID: References: <199711191722.MAA05864@users.invweb.net> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * William H. Geiger III wrote: >I will release my subroutines w/source for ascii-armor encoding/decoding >into the public domain. That way everyone will have them available to use >as they wish free of charge. > >Will this be an acceptable solution to the "problem"?? No. The problem is not programming efforts (which is quite simple to handle), the problem is the KISS principle. Ascii Armor is simply outdated. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08496 for ietf-open-pgp-bks; Wed, 19 Nov 1997 09:42:54 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08491 for ; Wed, 19 Nov 1997 09:42:49 -0800 (PST) Received: from users.invweb.net (ppp30.dotstar.net [208.143.93.49]) by users.invweb.net (8.8.7/8.8.7) with SMTP id MAA06086; Wed, 19 Nov 1997 12:42:24 -0500 Message-Id: <199711191742.MAA06086@users.invweb.net> From: "William H. Geiger III" Date: Wed, 19 Nov 97 11:40:49 -0600 To: Ian Brown In-Reply-To: <347311A5.2883320@cs.ucl.ac.uk> Cc: Thomas Roessler , IETF OpenPGP Subject: Re: The Case Against MIME X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <347311A5.2883320@cs.ucl.ac.uk>, on 11/19/97 at 11:19 AM, Ian Brown said: >> > It isn't for "purity"; it is to make it easier for new >> > implementors to create compatible versions without >> > unnecessary impediments. They can obtain MIME toolkits >> > more easily than Armour ones. Or even just let mail >> > programs handle the encoding of the binary data. >> >> Partdon me, this is not true. The only difference between >> ASCII Armor and MIME's base64 are the armor header and the >> CRC. >I do know this. So a MIME toolkit writes armour headers and CRCs? >> To make 2.6 understand MIME encoded PGP messages, >> just use mmencode -u -b | pgp -f - it will work on unix >> systems; porting mmencode to other OS'es will be quite >> trivial. >An excellent reason for saying we *don't* need armour. >The difficulty is not in reading it but in *writing* it. We don't want >new implementations to have to mess around with armour headers and CRCs. >mmencode shows a way that even PGP 2.6 could be made to work with MIME >rather than armour. What you are assuming is that all Open-PGP implementations will be using MIME. Not only do I think that this will not be the case more improtantly it SHOULD NOT be the case. For the majority of e-mail messages that are currently generated there is no reason to use MIME formatting including PGP formated messages! - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNHMkqI9Co1n+aLhhAQGImgQAtf2qXxrf4D8iuNtKG5NRnjwBb9Sx2p+g zGWlpKVrn6sAYBceut06x44JygFdeq6bxSCHwYra+tIOhJXRgV8TcQTzt5RAEzl0 +UO1LSYLmD0T0bTE6mSsHr32m1vPHFRmBoF7CQE6hOVAzqdp+UGWFPV99P+q65JR E/Pxt6+L0w8= =79vU -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08473 for ietf-open-pgp-bks; Wed, 19 Nov 1997 09:41:12 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA08468 for ; Wed, 19 Nov 1997 09:41:08 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Nov 1997 17:40:33 +0000 Message-ID: <347323FB.B99EC09D@cs.ucl.ac.uk> Date: Wed, 19 Nov 1997 17:38:03 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: "William H. Geiger III" CC: ietf-open-pgp@imc.org Subject: Re: Ascii Armor solution? References: <199711191722.MAA05864@users.invweb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > I have a proposal for the group in a effort to put the Ascii-Armor > question to rest. > > I will release my subroutines w/source for ascii-armor encoding/decoding > into the public domain. That way everyone will have them available to use > as they wish free of charge. > > Will this be an acceptable solution to the "problem"?? Such freely available toolkits already exist (see, for example, http://www.systemics.com/software/cryptix-java/) This does not alter the fact that implementors would need to download, understand, and adapt such code to work in their subsequently bloated application. Paul Hoffman wrote, quoting you: > >This is silly, I really can't see anyone saying "I'm not going to support > >PGP because it uses ASCII armor encoding". > > By itself, no. But if we require lots of other things that make it that > much harder for people to implement (such as requiring them being able to > handle all the earlier packet formats), they will probably have the same > attitude as they have had up to now: "I won't bother". That hurts all of > us, and is one of the driving forces for us to make a simple and useful spec. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA08069 for ietf-open-pgp-bks; Wed, 19 Nov 1997 09:21:52 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA08061 for ; Wed, 19 Nov 1997 09:21:47 -0800 (PST) Received: from users.invweb.net (ppp30.dotstar.net [208.143.93.49]) by users.invweb.net (8.8.7/8.8.7) with SMTP id MAA05864 for ; Wed, 19 Nov 1997 12:22:13 -0500 Message-Id: <199711191722.MAA05864@users.invweb.net> From: "William H. Geiger III" Date: Wed, 19 Nov 97 11:16:11 -0600 To: ietf-open-pgp@imc.org Subject: Ascii Armor solution? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I have a proposal for the group in a effort to put the Ascii-Armor question to rest. I will release my subroutines w/source for ascii-armor encoding/decoding into the public domain. That way everyone will have them available to use as they wish free of charge. Will this be an acceptable solution to the "problem"?? - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNHMf7I9Co1n+aLhhAQHIJAQAha/MTBwqCZiuPM2oJ6MiCO9dlAPnVj3L JnmKTSxU/vfTluj1+fEdB4UTIERtSSRl60tyJZydLvjGCexLe+J4mWT9fxcUvX8z 5W8uWBhSEPcM8awll1aSSHXA8Z+OCACslVogM7TIbye18rcu4ujV2pYyFEDALsKI NbtewZGGLUU= =Z/9f -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA07210 for ietf-open-pgp-bks; Wed, 19 Nov 1997 08:22:00 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA07202 for ; Wed, 19 Nov 1997 08:21:39 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Nov 1997 16:22:18 +0000 Message-ID: <347311A5.2883320@cs.ucl.ac.uk> Date: Wed, 19 Nov 1997 16:19:49 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Thomas Roessler CC: IETF OpenPGP Subject: Re: The Case Against MIME References: <199711191514.KAA04597@users.invweb.net> <34730B77.61958AD9@cs.ucl.ac.uk> <19971119170320.58254@sobolev.rhein.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > It isn't for "purity"; it is to make it easier for new > > implementors to create compatible versions without > > unnecessary impediments. They can obtain MIME toolkits > > more easily than Armour ones. Or even just let mail > > programs handle the encoding of the binary data. > > Partdon me, this is not true. The only difference between > ASCII Armor and MIME's base64 are the armor header and the > CRC. I do know this. So a MIME toolkit writes armour headers and CRCs? > To make 2.6 understand MIME encoded PGP messages, > just use mmencode -u -b | pgp -f - it will work on unix > systems; porting mmencode to other OS'es will be quite > trivial. An excellent reason for saying we *don't* need armour. The difficulty is not in reading it but in *writing* it. We don't want new implementations to have to mess around with armour headers and CRCs. mmencode shows a way that even PGP 2.6 could be made to work with MIME rather than armour. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA06909 for ietf-open-pgp-bks; Wed, 19 Nov 1997 08:04:46 -0800 (PST) Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA06903 for ; Wed, 19 Nov 1997 08:04:39 -0800 (PST) Received: from sobolev.rhein.de (roessler@sobolev.iam.uni-bonn.de [131.220.223.85]) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with ESMTP id RAA25405 for ; Wed, 19 Nov 1997 17:05:12 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id RAA21560 ; Wed, 19 Nov 1997 17:03:20 +0100 Message-ID: <19971119170320.58254@sobolev.rhein.de> Date: Wed, 19 Nov 1997 17:03:20 +0100 From: Thomas Roessler To: ietf-open-pgp@imc.org Subject: Re: The Case Against MIME References: <199711191514.KAA04597@users.invweb.net> <34730B77.61958AD9@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 In-Reply-To: <34730B77.61958AD9@cs.ucl.ac.uk> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Brown wrote: > It isn't for "purity"; it is to make it easier for new > implementors to create compatible versions without > unnecessary impediments. They can obtain MIME toolkits > more easily than Armour ones. Or even just let mail > programs handle the encoding of the binary data. Partdon me, this is not true. The only difference between ASCII Armor and MIME's base64 are the armor header and the CRC. To make 2.6 understand MIME encoded PGP messages, just use mmencode -u -b | pgp -f - it will work on unix systems; porting mmencode to other OS'es will be quite trivial. tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 1280/593238E1 · AE 24 38 88 1B 45 E4 C6 03 F5 15 6E 9C CA FD DB Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA06713 for ietf-open-pgp-bks; Wed, 19 Nov 1997 07:56:08 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA06709 for ; Wed, 19 Nov 1997 07:56:02 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Nov 1997 15:55:54 +0000 Message-ID: <34730B77.61958AD9@cs.ucl.ac.uk> Date: Wed, 19 Nov 1997 15:53:27 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: "William H. Geiger III" CC: ietf-open-pgp@imc.org Subject: Re: The Case Against MIME References: <199711191514.KAA04597@users.invweb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > The majority of PGP users are using 2.6.x and will be for a long time to > come. This is fact regardless of wether one likes it or not. There is a lot of stuff in OP which just will not work with PGP 2.6.x. Strictly speaking, a MUST-only implementation would be totally incompatible with PGP 2.6 as it won't do IDEA or RSA. Armour is the least of our worries there. > Switching formats for the sake of some MIME "purity" at the expense of > compatibility is a foolhardy gesture. It isn't for "purity"; it is to make it easier for new implementors to create compatible versions without unnecessary impediments. They can obtain MIME toolkits more easily than Armour ones. Or even just let mail programs handle the encoding of the binary data. > > BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the > > armor is split amongst Y parts, and this is the Xth part out of Y. > > > BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is > > the Xth part of an unspecified number of parts. Requires the MESSAGE-ID > > Armor Header to be used. > > These formats for multi-part messages are not re-inventing the wheel, they > are the wheels that all current versions of PGP ride on. The second, PART X, is a new invention in PGP 5 and thus not relevant to "the majority of PGP users [that] are using 2.6.x". > I highly doubt that the MIME Message/Partial subtype is widely implemented > among the current crop of MIME "compliant" Mua's (considering that Mua's > like Netscape & Eudora do not make use of multipart/alternative it is > doubtful that few if any make use of Message/Partial). So they're even less likely to implement yet another multipart message scheme. > I am also STRONGLY against using Base64 encoding of PGP packets. IMNSHO it > should be allowed for special case implementations but SHOULD NOT be used > in general e-mail applications. All this servers to do is break all > existsing PGP implementations without any added benefit. I'm not sure what you mean by this. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA06125 for ietf-open-pgp-bks; Wed, 19 Nov 1997 07:13:57 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA06121 for ; Wed, 19 Nov 1997 07:13:51 -0800 (PST) Received: from users.invweb.net (ppp30.dotstar.net [208.143.93.49]) by users.invweb.net (8.8.7/8.8.7) with SMTP id KAA04597 for ; Wed, 19 Nov 1997 10:14:13 -0500 Message-Id: <199711191514.KAA04597@users.invweb.net> From: "William H. Geiger III" Date: Wed, 19 Nov 97 08:26:47 -0600 To: ietf-open-pgp@imc.org Subject: The Case Against MIME X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hi, There seems to be several members that are in favor of dropping Ascii Armour, and MIME formatting all PGP messages. I would like to present the case that this is not necessary nor even recommended! The majority of PGP users are using 2.6.x and will be for a long time to come. This is fact regardless of wether one likes it or not. Switching formats for the sake of some MIME "purity" at the expense of compatibility is a foolhardy gesture. > BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the > armor is split amongst Y parts, and this is the Xth part out of Y. > BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is > the Xth part of an unspecified number of parts. Requires the MESSAGE-ID > Armor Header to be used. These formats for multi-part messages are not re-inventing the wheel, they are the wheels that all current versions of PGP ride on. I highly doubt that the MIME Message/Partial subtype is widely implemented among the current crop of MIME "compliant" Mua's (considering that Mua's like Netscape & Eudora do not make use of multipart/alternative it is doubtful that few if any make use of Message/Partial). There are still a large number of users who do not use MIME Mua's at all. In all reality MIME is quite over-rated and is not needed for the majority of e-mail messages! Why jump through the hoops of MIME formatting if it's not needed?? (I still get a laugh when I see a plain text message MIME formatted). This is not to say that there is not a place for MIME just that one should use the right tool for the right job. If a particular situation calls for MIME formatting of a PGP message then RFC 2015 should be followed but I do not think that the Open-PGP specs should push the developer in the direction that ALL messages should be in that format. In my current 2015 implementation the default action is to only MIME format PGP messages if the message before signing/encrypting is in MIME format (the user has 3 settings options Never use MIME, MIME on MIME messages [default], always use MIME). I am also STRONGLY against using Base64 encoding of PGP packets. IMNSHO it should be allowed for special case implementations but SHOULD NOT be used in general e-mail applications. All this servers to do is break all existsing PGP implementations without any added benefit. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNHMB7I9Co1n+aLhhAQF1EwQAycv9p2Slvn/CwIPGwxfgXBdp+K2Z8+hO s9hWnU5DqspbKgJoLOvg3aW38m5lyQUsYpUU/FMHiDu62XgIzu47u8OkofyPle+Z Cy97eR3sCSagH14f7scdsaUyDR3f4oBwdhpr6zbY17X6sDL2jGeKjqRVMefFjQsu n3fScp5LfdY= =7cVF -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA04364 for ietf-open-pgp-bks; Wed, 19 Nov 1997 04:54:26 -0800 (PST) Received: from riemann.iam.uni-bonn.de (root@riemann.iam.uni-bonn.de [131.220.223.83]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA04360 for ; Wed, 19 Nov 1997 04:54:15 -0800 (PST) Received: (from uucp@localhost) by riemann.iam.uni-bonn.de (8.8.5/8.8.5) with UUCP id NAA11329 for ietf-open-pgp@imc.org; Wed, 19 Nov 1997 13:38:59 +0100 Received: (from roessler@localhost) by sobolev.rhein.de (8.8.8/8.8.8) id NAA14060 ; Wed, 19 Nov 1997 13:32:32 +0100 Message-ID: <19971119133212.45264@sobolev.rhein.de> Date: Wed, 19 Nov 1997 13:32:12 +0100 From: Thomas Roessler To: ietf-open-pgp@imc.org Subject: A first set of comments Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.88 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I'm currently working my way through the draft. Yesterday night's results follow: > BEGIN PGP MESSAGE, PART X/Y used for multi-part messages, where the > armor is split amongst Y parts, and this is the Xth part out of Y. > BEGIN PGP MESSAGE, PART X used for multi-part messages, where this is > the Xth part of an unspecified number of parts. Requires the MESSAGE-ID > Armor Header to be used. I don't see any need for this in the specification: In virtually all situations I can imagine there are more appropriate ways to accomplish the same result: · If OP is used for local data storage, splitting stored data will be handled by the traditional methods (split(1) ;-) which will work for encrypted data the same way they are working for unencrypted data. · When using OP for data transmission, this will almost always be in some kind of PGP/MIME context, thus MIME's partial message methods can be used. No need to reinvent the wheel. > The Armor Headers are pairs of strings that can give the user or the > receiving OP message block some information about how to decode or use > the message. The Armor Headers are a part of the armor, not a part of > the message, and hence are not protected by any signatures applied to > the message. > The format of an Armor Header is that of a key-value pair. A colon > (':' 0x38) and a single space (0x20) separate the key and value. OP > should consider improperly formatted Armor Headers to be corruption of > the ASCII Armor. Unknown keys should be reported to the user, but OP > should continue to process the message. Currently defined Armor Header > Keys include "Version" and "Comment", which define the OP Version used > to encode the message and a user-defined comment. One could refer to the e-mail standards' definition of headers for this part. It's describing almost the same format, and it's widely used. > The MessageID should not appear unless it is in a > multi-part message. If it appears at all, it should be > computed from the message in a deterministic fashion, > rather than contain a purely random value. This is to > allow anyone to determine that the MessageID cannot serve > as a covert means of leaking cryptographic key > information. Phrase this as follows: "The MessageID header should not appear except in multi-part messages. It MUST be computed as a deterministic function of the armored message data. Implementors SHOULD use an SHA1 value of the armored message data concatenated with a string indicating the time of the message generation." Rationale: We should prescribe a method to get things clear; SHA1(armor + time) gives us the necessary amount of "randomness". Anyway, the MessageID header is actually not needed. For extensibility, we should permit X-something armor headers which MAY be used by specific implementations for their own purposes. The precise specification of the radix64 format is not needed in the present text - the reader can be referred to RFC2045. > Sometimes it is necessary to sign a textual octet stream without ASCII > armoring the stream itself, so the signed text is still readable > without special software. In order to bind a signature to such a > cleartext, this framework is used. (Note that RFC 2015 defines another > way to clear sign messages for environments that support MIME.) "Whenever possible and applicable, RFC 2015's method should be preferred over clear signing material." > If the "Hash" armor header is given, the specified message digest > algorithm is used for the signature. If this header is missing, SHA-1 > is assumed. If more than one message digest is used in the signature, You mean MD5 here, as that's used in PGP 2 which doesn't add the Hash header. > Dash escaped cleartext is the ordinary cleartext where every line > starting with a dash '-' (0x2D) is prepended by the sequence dash '-' > (0x2D) and space ' ' (0x20). This prevents the parser from recognizing > armor headers of the cleartext itself. The message digest is computed > using the cleartext itself, not the dash escaped form. In 2.6, the same is valid for lines beginning with the five characters "From ". I think we should stick with this convention since clear signing messages will mostly be used in legacy environments which don't support MIME (and will mangle From_ lines). > {{Editor's note: This is very complex, with bizarre things > like an 8-bit floating point format. Should we just drop > it? --jdcc}} Nope, it may be of some use at some point in the future. See also /etc/shadow. ;) tlr -- Thomas Roessler · 74a353cc0b19 · dg1ktr · http://home.pages.de/~roessler/ 1280/593238E1 · AE 24 38 88 1B 45 E4 C6 03 F5 15 6E 9C CA FD DB Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA04056 for ietf-open-pgp-bks; Wed, 19 Nov 1997 04:22:55 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA04052 for ; Wed, 19 Nov 1997 04:22:49 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id NAA06223; Wed, 19 Nov 1997 13:23:31 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Draft comments Date: 19 Nov 1997 12:23:31 GMT Organization: IKS GmbH Jena Lines: 84 Message-ID: References: <3472C7D4.F1097051@cs.ucl.ac.uk> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Ian Brown wrote: >2.4.1 - Just one quibble. Since Armour is largely for backward >compatibility with the 4 million users of PGP 2.6, do we *really* need >to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could >Message-ID also go? It does say in PGP/MIME that "When the amount of >data to be transmitted requires that it be sent in many parts, the MIME >message/partial mechanism should be used rather than the multipart ASCII >armor PGP format." Good Idea. >2.6 - I'm not sure what jdcc means by "Should the armor header line stay >or go... I think anything that reduces parsing complexity is a Good >Thing." I agree, but by this do you mean it saves implementations >parsing the algorithm fields in the actual signature itself? No. The new line is completely sensless IMHO, because directly after this header line the armor header follows. There the Hash codes are already present. >5.1 - "An implementation should accept, but not generate a version of 2, >which is equivalent to V3 in all other respects." Is this purely for >legal (RSAREF) reasons? The international version of PGP 2.6 can >generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is >there any *technical* reason why OP implementations should not generate >version 2 packets? Public key encrypted session keys are stored in a completely other padding format. Same goes for hash paddings in signatures. So there es a major difference between v2 and v3. For backward compatibility you may refer to 1991 or describe it. >5.2. - Ditto, "Implementations SHOULD generate V4 signatures, unless >there is a need to generate a signature that can be verified by PGP >2.6.x.". Could this not be "Implementations SHOULD generate V3/2 >signatures if possible, for backwards compatibility. Only packets that >would not be understood by PGP 2.6.x should have a version number of 4"? Keeping the technical difference above in mind, you have to use exactly the same format version the public key of the recipient is stored in. >"Preferred hash algorithms" - you mention "If this subpacket is not >included, ZIP is preferred." Would it be useful to put a sentence of >this type in the preferred symmetric and hash algorithms also? We have >3DES and SHA-1 as MUSTs, so they could be used... ZIP is not MUST, so: 'If this subpacket is not included, uncompressed is preferred." Only use MUST values as defaults. >> {{Editor's note: While there is a scale of identification signatures >> in the range 0x10 to 0x13, most of them have never been implemented or >> used. Current implementations only use 0x10, the "generic >> certification." Should the others be removed? RFC 1991 went to some >> trouble to explain which ones were defined but not implemented, or read >> but not generated. I think we should not do that. If we define them, >> they should be MAY features at the very least. If we're not going to >> use them, they shouldn't be in the spec. --jdcc}} > >They were a good idea, but seem to be obseleted by the trust subpackets. >In which case, you're right - get rid of them. Trust packets are not transferable. There are several implementations known to use these signatures heavily. >> {{Editor's note: There is presently no way for a key-signer (a.k.a. >> certifier) to sign a main key along with a subkey. There are a number >> of useful situations for a set of keys (main plus subkeys) to all be >> signed together... --jdcc}} > >Could you give a few examples? If you try to exchange a whole packet on a keyserver, you must sign all key material incl. subkeys at once. >5.4 - Is the one-pass signature packet *really* necessary? Yes, software knows in advance which hashs are used in the signature below. This is necessary for one pass implementations. I choosed to calculate all hashs in my one pass implementation. But this can be messy. >8.1 - Why not use the BNF-like notation from section 7.2 to describe >keyring structure also? Not enough time ;-) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA03376 for ietf-open-pgp-bks; Wed, 19 Nov 1997 03:07:40 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id DAA03372 for ; Wed, 19 Nov 1997 03:07:21 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 19 Nov 1997 11:07:14 +0000 Message-ID: <3472C7D4.F1097051@cs.ucl.ac.uk> Date: Wed, 19 Nov 1997 11:04:52 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: IETF OpenPGP Subject: Draft comments Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Took a while to plough through! It's a pretty good document overall - please don't take the following comments as quibbling in any way, I'm just trying to contribute ;-) Sec Comments 2.4 - Like the description of armour - If ithe checksum is remaining, I think jdcc's idea to put a sample implementation in C in the appendix is good - we don't want people to have to dig out (possibly out of print) books. 2.4.1 - Just one quibble. Since Armour is largely for backward compatibility with the 4 million users of PGP 2.6, do we *really* need to add a new header (BEGIN PGP MESSAGE, PART X)? If this went, could Message-ID also go? It does say in PGP/MIME that "When the amount of data to be transmitted requires that it be sent in many parts, the MIME message/partial mechanism should be used rather than the multipart ASCII armor PGP format." 2.6 - I'm not sure what jdcc means by "Should the armor header line stay or go... I think anything that reduces parsing complexity is a Good Thing." I agree, but by this do you mean it saves implementations parsing the algorithm fields in the actual signature itself? 3.5 - Are the S2K functions really necessary? Are dictionary attacks on passphrases in an (at least) 128-bit keyspace likely to be successful? If so, I still agree with jdcc that the Iterated-Salted algorithm should be dropped. 5.1 - "An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects." Is this purely for legal (RSAREF) reasons? The international version of PGP 2.6 can generate V2 packets for backwards compatibility (LEGAL_KLUDGE=off). Is there any *technical* reason why OP implementations should not generate version 2 packets? 5.2. - Ditto, "Implementations SHOULD generate V4 signatures, unless there is a need to generate a signature that can be verified by PGP 2.6.x.". Could this not be "Implementations SHOULD generate V3/2 signatures if possible, for backwards compatibility. Only packets that would not be understood by PGP 2.6.x should have a version number of 4"? 5.1 + 5.2.1 - You mention ASN.1 and PKCS-1. While it's good to have everything properly attributed, do we need to get simple implementations involved in these horrors ;-) 5.2.2.2 "Preferred hash algorithms" - you mention "If this subpacket is not included, ZIP is preferred." Would it be useful to put a sentence of this type in the preferred symmetric and hash algorithms also? We have 3DES and SHA-1 as MUSTs, so they could be used... "Additional request recipients" - as this is still such a controversial topic, I don't think it should be included in this first version of the standard. 5.2.3 - Signature types > {{Editor's note: While there is a scale of identification signatures > in the range 0x10 to 0x13, most of them have never been implemented or > used. Current implementations only use 0x10, the "generic > certification." Should the others be removed? RFC 1991 went to some > trouble to explain which ones were defined but not implemented, or read > but not generated. I think we should not do that. If we define them, > they should be MAY features at the very least. If we're not going to > use them, they shouldn't be in the spec. --jdcc}} They were a good idea, but seem to be obseleted by the trust subpackets. In which case, you're right - get rid of them. > {{Editor's note: It would be nice to have a signature that applied to > the key alone, rather than a key plus a user name... --jdcc}} What would it mean to have just key material signed by someone else? > {{Editor's note: There is presently no way for a key-signer (a.k.a. > certifier) to sign a main key along with a subkey. There are a number > of useful situations for a set of keys (main plus subkeys) to all be > signed together... --jdcc}} Could you give a few examples? 5.4 - Is the one-pass signature packet *really* necessary? 5.10 - I think you're right about there being so many problems with Trust packets, we should forget them. Your idea about them being implementation dependent is good, except that different OP implementations may want to use the same keyring. For example, I use PGP 2.6.3i and my mail encrypting program with the same keyring. If they implement trust packets differently, it would be very confusing. I think we should just specify that they should be ignored. 6.2 - I know the inclusion of ROT-n started as a joke - but it's in there! Eeeek! Also, excuse my ignorance, but what is DES/SK? 8.1 - Why not use the BNF-like notation from section 7.2 to describe keyring structure also? Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA21858 for ietf-open-pgp-bks; Tue, 18 Nov 1997 12:44:01 -0800 (PST) Received: from att.com (kcgw2.att.com [192.128.133.152]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA21854 for ; Tue, 18 Nov 1997 12:43:57 -0800 (PST) From: stewarts@ix.netcom.com Received: by kcgw2.att.com; Tue Nov 18 14:29 CST 1997 Received: from attrh1.attrh.att.com (attrh1.attrh.att.com [135.71.27.39]) by kcig2.att.att.com (AT&T/GW-1.0) with SMTP id OAA18030; Tue, 18 Nov 1997 14:33:59 -0600 (CST) Received: from ca07b8bl.bns.att.com by attrh1.attrh.att.com (SMI-8.6/EMS-1.2 sol2) id PAA24490 for ; Tue, 18 Nov 1997 15:43:39 -0500 Message-Id: <3.0.3.32.19971118094016.006d70e8@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Tue, 18 Nov 1997 09:40:16 -0800 To: cypherpunks@toad.com Original-From: Bill Stewart Subject: I-D ACTION:draft-ietf-openpgp-formats-00.txt Cc: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Forwarded from IETF-Announce@ietf.org and ietf-open-pgp@imc.org --------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OP Formats - OpenPGP Message Format Author(s) : R. Thayer, J. Callas, L. Donnerhacke, H. Finney Filename : draft-ietf-openpgp-formats-00.txt Pages : 40 Date : 17-Nov-97 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OP format. It is not a step-by-step cookbook for writing an application, it describes only the format and methods needed to read, check, generate and write conforming packets crossing any network. It does not deal with storing and implementation questions albeit it is necessary to avoid security flaws. OP (Open-PGP) software uses a combination of strong public-key and conventional cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication and digital signatures. This document specifies the message formats used in OP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-formats-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-openpgp-formats-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <19971117171828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA18082 for ietf-open-pgp-bks; Tue, 18 Nov 1997 08:05:40 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA18074 for ; Tue, 18 Nov 1997 08:05:36 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id IAA09347 for ; Tue, 18 Nov 1997 08:03:40 -0800 (PST) Message-Id: <3.0.5.32.19971118080624.009f49b0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 18 Nov 1997 08:06:24 -0800 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-openpgp-formats-00.txt In-Reply-To: <199711181445.JAA06340@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:45 AM 11/18/97 -0500, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. > > Title : OP Formats - OpenPGP Message Format > Author(s) : R. Thayer, J. Callas, L. Donnerhacke, H. Finney > Filename : draft-ietf-openpgp-formats-00.txt > Pages : 40 > Date : 17-Nov-97 > This is also available as . As the draft gets revised in the future, this URL will always point to the latest version. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA16883 for ietf-open-pgp-bks; Tue, 18 Nov 1997 06:44:27 -0800 (PST) Received: from ietf.org (ietf.org [132.151.1.19]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA16879 for ; Tue, 18 Nov 1997 06:44:23 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id JAA06340; Tue, 18 Nov 1997 09:45:05 -0500 (EST) Message-Id: <199711181445.JAA06340@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: ietf-open-pgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-formats-00.txt Date: Tue, 18 Nov 1997 09:45:05 -0500 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OP Formats - OpenPGP Message Format Author(s) : R. Thayer, J. Callas, L. Donnerhacke, H. Finney Filename : draft-ietf-openpgp-formats-00.txt Pages : 40 Date : 17-Nov-97 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OP format. It is not a step-by-step cookbook for writing an application, it describes only the format and methods needed to read, check, generate and write conforming packets crossing any network. It does not deal with storing and implementation questions albeit it is necessary to avoid security flaws. OP (Open-PGP) software uses a combination of strong public-key and conventional cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication and digital signatures. This document specifies the message formats used in OP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-formats-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-openpgp-formats-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971117171828.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-formats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-formats-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971117171828.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA10719 for ietf-open-pgp-bks; Mon, 17 Nov 1997 23:33:11 -0800 (PST) Received: from dfw-ix6.ix.netcom.com (dfw-ix6.ix.netcom.com [206.214.98.6]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA10715 for ; Mon, 17 Nov 1997 23:33:07 -0800 (PST) Received: (from smap@localhost) by dfw-ix6.ix.netcom.com (8.8.4/8.8.4) id BAA10461; Tue, 18 Nov 1997 01:28:49 -0600 (CST) Received: from pax-ca27-19.ix.netcom.com(207.93.145.51) by dfw-ix6.ix.netcom.com via smap (V1.3) id rma010446; Tue Nov 18 01:28:34 1997 Message-Id: <3.0.3.32.19971117192528.00688de4@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Mon, 17 Nov 1997 19:25:28 -0800 To: Ian Brown , Jon Callas From: Bill Stewart Subject: Re: Armour Cc: Adam Back , ietf-open-pgp@imc.org In-Reply-To: <346DB3C5.55F6BF9C@cs.ucl.ac.uk> References: <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:37 PM 11/15/1997 +0000, Ian Brown wrote: >I'm not sure what you mean. Do you mean safely holding an object while >it is transmitted by mail? >Armour was a very necessary part of PGP. But now we have MIME, which is >meant for the same purpose - safely transmitting binary data across >7-bit or less mail systems. Same primary purpose, and it we were starting from scratch there'd be no need for two similar but different systems. But we're not - all the existing versions of PGP generate and read PGP-armor, some parts of even PGP 5.0 don't have a mechanism for inputting MIME or binary, like the Encrypt/Decrypt/Sign/Verify-From-Clipboard mechanisms, and you'll lose compatibility with all of them if you drop armor. MIME, on the other hand, tries to do far more than just armor, with lots of complexity, registered object types, unregistered object types, interaction with mail systems that should maybe leave the encrypted part alone, and a whole lot of other ballast that may not belong in a pocket organizer. And mail user agents aren't the only places people use PGP. >I'm not arguing that we should totally do away with armour - just that I >don't think it should be a MUST, so that people who want to use OpenPGP >in their program or standard minimally, with no need for backwards >compatibility, can do it with as little problem as possible. Losing compatibility may be worthwhile for avoiding patent encumbrances, but it's a serious mistake for an "OpenPGP" to do so just for aesthetic purity. If you want S/MIME, use S/MIME. If you want PGP, you need to interact with PGP. I agree that there were other choices of armor that PRZ should have used, like uuencode or maybe btoa, but this is what we've got. Meanwhile, while ASCII armor may mean adding another MIME type, the amount of code involved is a small part of the total, and it's easy for an OpenPGP program to tell which input it's getting. Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA01326 for ietf-open-pgp-bks; Mon, 17 Nov 1997 09:57:07 -0800 (PST) Received: from splat.premenos.com (splat.premenos.com [150.105.250.245]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA01320; Mon, 17 Nov 1997 09:56:25 -0800 (PST) Received: from premenos.com (steadyeddy.premenos.com [150.105.100.16]) by splat.premenos.com (8.8.5/8.8.5) with ESMTP id JAA02745; Mon, 17 Nov 1997 09:56:50 -0800 (PST) Message-ID: <34708567.F99608A@premenos.com> Date: Mon, 17 Nov 1997 09:56:56 -0800 From: Karen Rosenthal Organization: Premenos X-Mailer: Mozilla 4.03 [en] (WinNT; U) MIME-Version: 1.0 To: chucks@actracorp.com CC: ietf-ediint@imc.org, ietf-smime@imc.org, ietf-open-pgp@imc.org Subject: Receipt mechanism(s) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Chuck, Has there ever been any thought/discussion of pulling the signed receipt section out of the MIME-based Secure EDI draft, and into a working group/draft of its own? The MDN based signed receipts address some of the issues coming up in the S/MIME receipt discussions, are really not EDI specific. Both the S/MIME and PGP groups are looking for receipt mechanisms (the former obviously more actively), and there has been talk before of trying to combine efforts between the two groups, where appropriate. Sure, we can all support Message Disposition Notifications, S/MIME receipts, some day PGP receipts, AUTACKs, etc, but is there not benefit in a well developed, centralized and higher-level receipt mechanism? Regards, -- Karen Rosenthal Email: karenr@premenos.com Premenos Tel#: 1-510-688-2928 1000 Burnett Ave Fax#: 1-510-602-2133 Concord, CA 94520 Visit: http://www.premenos.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA27498 for ietf-open-pgp-bks; Mon, 17 Nov 1997 05:24:47 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA27492 for ; Mon, 17 Nov 1997 05:24:36 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id OAA12232; Mon, 17 Nov 1997 14:24:51 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: extension mechanism needed Date: 17 Nov 1997 13:24:51 GMT Organization: IKS GmbH Jena Lines: 5 Message-ID: References: <199711142118.VAA05408@server.test.net> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Adam Back wrote: [Two new extensions] >What more could we ask for :-) Interoperability. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01790 for ietf-open-pgp-bks; Sat, 15 Nov 1997 13:42:13 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01786 for ; Sat, 15 Nov 1997 13:42:09 -0800 (PST) Received: from [199.106.106.130] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id NAA01785; Sat, 15 Nov 1997 13:40:56 -0800 (PST) X-Sender: jwn2@127.0.0.1 Message-Id: In-Reply-To: <346DB3C5.55F6BF9C@cs.ucl.ac.uk> References: <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b40-1.98] 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: Sat, 15 Nov 1997 13:29:06 -0800 To: Ian Brown From: "John W. Noerenberg" Subject: Re: Armour Cc: Jon Callas , Bill Stewart , Adam Back , ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 2:37 PM +0000 11/15/97, Ian Brown wrote: > >I'm not arguing that we should totally do away with armour - just that I >don't think it should be a MUST, so that people who want to use OpenPGP >in their program or standard minimally, with no need for backwards >compatibility, can do it with as little problem as possible. > This is probably closest to my own point of view, Ian. The ability to generate and accept ascii armor must be preserved for backwards compatibility. However, successfully encoding and decoding a message should not mandate translation through ascii armor. john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com ----------------- --------------------------- ---------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 ----------------- --------------------------- ---------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01783 for ietf-open-pgp-bks; Sat, 15 Nov 1997 13:41:10 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01779 for ; Sat, 15 Nov 1997 13:40:56 -0800 (PST) Received: from [199.106.106.130] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id NAA01782 for ; Sat, 15 Nov 1997 13:40:46 -0800 (PST) X-Sender: jwn2@127.0.0.1 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b40-1.98] 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: Sat, 15 Nov 1997 13:19:04 -0800 To: ietf-open-pgp@imc.org From: "John W. Noerenberg" Subject: Draft on the way Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Keep an eye out for an message from Internet-Drafts that it has been posted. I've sent it off to the internet-drafts editor. john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com ----------------- --------------------------- ---------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 ----------------- --------------------------- ---------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA06571 for ietf-open-pgp-bks; Sat, 15 Nov 1997 06:40:13 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA06567 for ; Sat, 15 Nov 1997 06:40:09 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 15 Nov 1997 14:40:24 +0000 Message-ID: <346DB3C5.55F6BF9C@cs.ucl.ac.uk> Date: Sat, 15 Nov 1997 14:37:57 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Jon Callas CC: Bill Stewart , Adam Back , ietf-open-pgp@imc.org Subject: Armour References: <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> <3.0.3.32.19971114105032.00aed610@mail.pgp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas wrote: > From PRZ's first documents, he labeled > armoring as an integral piece of PGP. It's too useful as a generalized > mechanism for holding an object (data, keys, etc.) without having to worry > about what odd thing something will do to your binary. I'm not sure what you mean. Do you mean safely holding an object while it is transmitted by mail? Armour was a very necessary part of PGP. But now we have MIME, which is meant for the same purpose - safely transmitting binary data across 7-bit or less mail systems. Bill Stewart wrote: > Understanding armour _isn't_ very hard; I'd prefer MUST, > especially since it's needed for backward compatibility with PGP 5.0 > (in particular, the Encrypt Clipboard doesn't do MIME.) I agree it isn't too difficult. But as Paul Hoffman said: > The advantage is that using standard MIME is more easily specified and > implemented than using ASCII armor. That is, a developer who has a MIME > toolkit must modify that toolkit in order to use ASCII armor. Forcing ASCII > armor when it shows no noticable value over standard MIME is one more > impediment to new developers adopting OpenPGP. > ... > If the IETF Calendaring and Scheduling Working Group, > for example, wants to use OpenPGP for handing around scheduling events in > an automated environment (that is, without human intervention), there is > absolutely no reason why the must be able to process older PGP formats. If > our spec requires that they do so, it is that much harder for them to chose > it over competing specs. > > OpenPGP can be useful for many types of applications other than humans > sending email to each other. Many other IETF messaging protocols can use > the privacy and authentication offered by OpenPGP. They would have > absolutely no use for backwards compatibility with earlier versions. > > This isn't to say that we shouldn't try to get software to be able to > process and possibly even emit messages from earlier versions, but there is > no reason to *force* them to because what we specify will be complete and > secure by itself. We should make it as easy as possible for some who starts > with OpenPGP to add support for earlier versions without burdening them > with implementation issues that aren't relevant to OpenPGP. Bill again: > Generating it is a matter of taste - will PGP 5.0 always accept MIME? > Even in applications like Decrypt/Verify Clipboard? I agree it could be awkward with the current implementation (PGP 5). Most mailers these days understand MIME, so even if they don't understand PGP/MIME objects they can do the conversion from Base64 to binary data - at which point PGP could take over. If we had a standard content-type for the PGP data itself - rather than just using application/octet-stream like PGP/MIME - *any* mailer that understood MIME could be configured to launch a PGP program upon receipt of such a body part. I'm not arguing that we should totally do away with armour - just that I don't think it should be a MUST, so that people who want to use OpenPGP in their program or standard minimally, with no need for backwards compatibility, can do it with as little problem as possible. Ian >:) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id BAA03325 for ietf-open-pgp-bks; Sat, 15 Nov 1997 01:24:02 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id BAA03320 for ; Sat, 15 Nov 1997 01:23:57 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IQ0OCO2A9C9LUYEY@INNOSOFT.COM> for ietf-open-pgp@imc.org; Sat, 15 Nov 1997 01:23:28 PST Date: Sat, 15 Nov 1997 01:21:39 -0800 (PST) From: Ned Freed Subject: Re: closedPGP vs openSMIME In-reply-to: "Your message dated Fri, 14 Nov 1997 23:10:04 -0800" To: "John W. Noerenberg" Cc: Ian Grigg , ietf-open-pgp@imc.org Message-id: <01IQ0RD6ZB9C9LUYEY@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <3.0.3.32.19971114100753.039c142c@pop.pn.com> <346CEC9A.5B01F3F3@systemics.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > I'm not going to bed tonight until it is sent to the draft editor. It > should be posted to the directory early next week. John, your efforts, and the efforts of the other authors and editors, are much appreciated. I look forward to seeing the draft. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA02850 for ietf-open-pgp-bks; Fri, 14 Nov 1997 23:59:38 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA02844 for ; Fri, 14 Nov 1997 23:59:34 -0800 (PST) Received: from [199.106.106.130] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id XAA19547; Fri, 14 Nov 1997 23:58:17 -0800 (PST) X-Sender: jwn2@127.0.0.1 Message-Id: In-Reply-To: <01IQ0FBJWH3I9LV0AM@INNOSOFT.COM> References: "Your message dated Sat, 15 Nov 1997 00:28:10 +0000" <346CEC9A.5B01F3F3@systemics.com> <3.0.3.32.19971114100753.039c142c@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b40-1.98] 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: Fri, 14 Nov 1997 23:55:25 -0800 To: Ned Freed From: "John W. Noerenberg" Subject: Re: closedPGP vs openSMIME Cc: Ian Grigg , ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 7:30 PM -0800 11/14/97, Ned Freed wrote: > >> Mr Chair, >> would it be at all possible to post the draft on the mailing list in >> order to minimise delays? > >As I said before, some people may object to drafts being posted to >the list, but I don't. Thanks, Ned. I'll bear that in mind. I suspect your sentiment is shared by many. > >Please note that submitting an Internet Draft is trivially easy -- you send >mail to internet-drafts@ietf.org with the document in plain text format >attached. There are no, repeat NO, formatting requirements other than this. While this is true, the first draft of the format document is already lengthy, 30+ pages broken into 11 sections. In order to have some sensible discussion, it would be useful for people to be able to refer to specific sections of the document. So some minimal formatting is useful. > >I do object, however, to having drafts posted to the list as a substitute for >submitting them to the Internet Drafts repository. As far as I'm concerned a >draft not posted to the Internet Drafts repository doesn't exist in any formal >sense. And I can assure you that the IESG shares this view. So that's why for the first one, I'm going by the book. Before you break the rules, first prove you understand them. Later, justifying why you need to deviate is easier if you've already shown you know how the game is played. best, john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com ----------------- --------------------------- ---------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 ----------------- --------------------------- ---------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA02831 for ietf-open-pgp-bks; Fri, 14 Nov 1997 23:59:00 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA02827 for ; Fri, 14 Nov 1997 23:58:56 -0800 (PST) Received: from [199.106.106.130] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id XAA19540; Fri, 14 Nov 1997 23:58:00 -0800 (PST) X-Sender: jwn2@127.0.0.1 Message-Id: In-Reply-To: <346CEC9A.5B01F3F3@systemics.com> References: <3.0.3.32.19971114100753.039c142c@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b40-1.98] 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: Fri, 14 Nov 1997 23:10:04 -0800 To: Ian Grigg From: "John W. Noerenberg" Subject: Re: closedPGP vs openSMIME Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:28 AM +0000 11/15/97, Ian Grigg wrote: > >Mr Chair, >would it be at all possible to post the draft on the mailing list in >order to minimise delays? I've been scolded in the past for that sort of thing in APPs. Now I'm a bit skittish -- cats and stoves, and all that. Not that it hasn't crossed my mind. I might be more flexible in the future, but for the initial draft, I'm going by the book. Call me anal-compulsive if you must. I'm not going to bed tonight until it is sent to the draft editor. It should be posted to the directory early next week. I know you're all eager to see it. The authors are equally eager for you to see it, too. I expect a lot of discussion once its in your hands. My expectation at this point is we'll use the next weeks running up to the Dec meeting to read and start commenting on the document. I plan to have the authors bring a list of topics they think we can resolve at the meeting for their agenda. I'll post my agenda for the whole meeting shortly. I haven't sent my agenda in yet, so this will be an opportunity for your suggestions. Thanks! john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com ----------------- --------------------------- ---------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 ----------------- --------------------------- ---------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA01312 for ietf-open-pgp-bks; Fri, 14 Nov 1997 19:39:11 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA01308 for ; Fri, 14 Nov 1997 19:39:07 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPZXN01PSG9LV0AM@INNOSOFT.COM> for ietf-open-pgp@imc.org; Fri, 14 Nov 1997 19:38:33 PST Date: Fri, 14 Nov 1997 19:30:02 -0800 (PST) From: Ned Freed Subject: Re: closedPGP vs openSMIME In-reply-to: "Your message dated Sat, 15 Nov 1997 00:28:10 +0000" <346CEC9A.5B01F3F3@systemics.com> To: Ian Grigg Cc: ietf-open-pgp@imc.org Message-id: <01IQ0FBJWH3I9LV0AM@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <3.0.3.32.19971114100753.039c142c@pop.pn.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Meanwhile, over at IPsec, > > At the direction of the working group chairs, we're posting the IPsec > > Architecture draft directly to the mailing list to minimize delays. (It > > is also being sent to the secretariat.) The chairs ask everyone to > > please review and comment as quickly as possible. > Mr Chair, > would it be at all possible to post the draft on the mailing list in > order to minimise delays? As I said before, some people may object to drafts being posted to the list, but I don't. I do object, however, to having drafts posted to the list as a substitute for submitting them to the Internet Drafts repository. As far as I'm concerned a draft not posted to the Internet Drafts repository doesn't exist in any formal sense. And I can assure you that the IESG shares this view. So post to the list if you want to, but you _must_ submit the document as an Internet Draft. Please note that submitting an Internet Draft is trivially easy -- you send mail to internet-drafts@ietf.org with the document in plain text format attached. There are no, repeat NO, formatting requirements other than this. To say that this mechanism works well understates the case considerably. I have on occasion posted as many as three revisions to a document in a single day and gotten prompt and correct turnaround on all of them. When I've screwed up and gotten the wrong name or revision level on a document the I-D people have caught it every time. My experience has been that the draft usually makes it out in less than 24 hours. Of course this is the period just before an IETF, so there may be a bit more of a backlog than usual. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA28446 for ietf-open-pgp-bks; Fri, 14 Nov 1997 16:25:49 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA28442 for ; Fri, 14 Nov 1997 16:25:45 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id DAA11313; Sat, 15 Nov 1997 03:02:52 +0100 (MET) Message-ID: <346CEC9A.5B01F3F3@systemics.com> Date: Sat, 15 Nov 1997 00:28:10 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org Subject: Re: closedPGP vs openSMIME References: <3.0.3.32.19971114100753.039c142c@pop.pn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > draft is being physically formatted now for delivery to IETF. Meanwhile, over at IPsec, > From: Karen Seo > To: ipsec@tis.com > Subject: IPsec Architecture -- List of changes > > Folks, > > At the direction of the working group chairs, we're posting the IPsec > Architecture draft directly to the mailing list to minimize delays. (It > is also being sent to the secretariat.) The chairs ask everyone to > please review and comment as quickly as possible. Mr Chair, would it be at all possible to post the draft on the mailing list in order to minimise delays? > >On ietf-smime there 70 posts in last 3 days, this list only 3! I'd just like to make the point that whilst Adam and I have been working hard on crypto all week (yes, we hack for cash) this correlation is coincidence and not causality :-) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA26307 for ietf-open-pgp-bks; Fri, 14 Nov 1997 13:19:49 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA26303 for ; Fri, 14 Nov 1997 13:19:45 -0800 (PST) Received: from server.test.net ([194.168.63.8]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAD5657; Fri, 14 Nov 1997 21:20:14 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id VAA05388; Fri, 14 Nov 1997 21:06:12 GMT Date: Fri, 14 Nov 1997 21:06:12 GMT Message-Id: <199711142106.VAA05388@server.test.net> From: Adam Back To: stewarts@ix.netcom.com CC: ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971114101009.006e8654@popd.ix.netcom.com> (message from Bill Stewart on Fri, 14 Nov 1997 10:10:09 -0800) Subject: Re: extension mechanism needed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart writes: > At 12:15 PM 11/14/1997 GMT, Adam Back wrote: > >In ESMTP/SMTP there are extension mechanisms. Clients/Servers can use > >this mechanism where the other party has it also. This is a very > >powerful and simple to add feature. I think we need such an extension > >mechanism in OpenPGP. > > Extension mechanisms require a communication mechanism between > the ends of the connection. ESMTP is interactive, so it's easy. > In PGP, the only interaction mechanism from the recipient to the sender > is the public key record. There's already an extension mechanism > for indicating algorithm choices. There's another extension mechanism > for indicating additional recipients, but it's apparently controversial :-) CMR was not defined as an extension, it was proposed for inclusion in the standard. Perhaps it would be less controversial if it were also an extension. (Now there's an idea.) > >One example I am thinking of is transparent tunneling of SMTP headers > >inside the encrytion envelope when both sides are using an encrypting > >proxy such as Ian Brown's Enigma. > > This sounds like a problem for the application programs on the ends, > not a problem for PGP itself? It is a problem for PGP. Say I want to be able to tunnel information. If I can not determine from the recipients public key whether he has the tunneling extension, I must insert the information into the plaintext, and this could confuse the recipient, and/or the recipients software where the software does not support tunneling. If I know that the recipient does not support this extension I can avoid this risk by not using it in this case. > >Another might be opportunistic forward secrecy via sending of new EG > >keys within each message with relatively short expiry times. > > That sounds like there's a need for the sender of a key to indicate > that it should be used in preference to a previous key, e.g. > New: Adam Back, 0x22222222, expires 2/2/1998 > Old: Adam Back, 0x11111111, expires 1/1/2000 I think probably what you would do is to use the key which is nearest to it's expiry date of those marked as forward secret. (You could mark the keys as forward secret with another extension record). Also, there is already I think a "valid from" date. So another way of avoiding using a long term key which happens to expire before a short lived one would be to use the "valid from" date to avoid using relatively long lived keys where still valid shorter lived keys are available. I am happy to discuss or put together a proposal for how this might work out, but the above comment was just arguing for an extension system which allows things like this to be done as extensions. The beauty of an extension feature is that the extension implementors can hash it out in practice, and bring it back to the standards process as tried and tested technology for next time around. Also it allows us to move forward in a focussed manner to get something minimal and workable out _now_. We could be hear until next year arguing about Forward secrecy, and politically controversial CMR extensions, etc. Extensions are a useful way of focussing the discussion on what is necessary now. If anyone brings up a "I want to do X" -- we just say "fine use an extension" -- end of argument. > Supporting this automatically isn't straightforward - > what if the new encryption key expires _before_ the old one? Use it instead. You are trying to give the message you are about to send maximal forward secrecy. The way to do this is to use of the available keys marked for forward secret use the one which expires soonest. > And does the extension only apply to EG/DSA keys, or to RSA keys as > well (which has lots of complex interaction with trust models.)? There is no inherent reason why RSA sign only and RSA encrypt only keys could not be used. It would be interesting to have this functionality expressible within the standard. (Perhaps it is... I am not sure). But yes, the extension I had in mind once we had an extension mechanism, was to have forward secret EG subkeys. I wasn't thinking directly about having forward secret signature keys. But they too are interesting. To make a signature key forward secret, you publish the private key :-) (Then non-timestamped documents signed by you have lost much of their proof of authorship). If you wanted to do this it would actually argue that you had a certification only signing key, as well as a document signing key. You disclose the private document signing key when it expires. You destroy the private forward secret decryption key when it expires. Interesting stuff. (Incidentally the Norwegian? standards document that I posted excerpts from earlier makes this distinction between key uses... they see a need for separate certification keys. Also they see a need to time stamp signatures where the signature is intended to have meaning after the signature key has expired. The application they are thinking of I think is long term contracts.) > There's an obvious need to deal with the semantics of accepting keys, > and it sounds like you're proposing that this needs more options? All I was really proposing was that there be a flexible extension mechanism so that we can put it in and get on with this iteration of the standard without having people clamoring for their favourite feature to go in at this stage. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Fri, 14 Nov 1997 13:19:35 -0800 (PST) Received: from server.test.net ([194.168.63.8]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAB5657; Fri, 14 Nov 1997 21:20:05 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id VAA05408; Fri, 14 Nov 1997 21:18:26 GMT Date: Fri, 14 Nov 1997 21:18:26 GMT Message-Id: <199711142118.VAA05408@server.test.net> From: Adam Back To: jon@pgp.com CC: ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971114104807.00add8f0@mail.pgp.com> (message from Jon Callas on Fri, 14 Nov 1997 10:48:07 -0800) Subject: Re: extension mechanism needed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas writes: > There are two parts of the extension mechanism: a "notation" that is a tag > and value (16-bit length for each, no encoding assumed) that can be put in > any signature. This is so it can be used both for extensions, but also for > human-readable notes. You might, for example, put in a document signature > "read but not agreed to". Sounds cool. 16 bits is lots. > The second part is a "standalone signature" which is a signature > that hashes only over its own subpacket contents. This is so you can > have signatures that encode their own extension pieces so that they > can act like SPKI certificates (or even *hold* SPKI certificates) or > any other type of advanced use. The icing too. What more could we ask for :-) Adam -- Pentium bug program in C, cut and paste to shell: echo main=0xc8c70ff0\; > t.c; gcc t.c; a.out # boom! Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23980 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:51:23 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23973 for ; Fri, 14 Nov 1997 10:51:19 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA02532; Fri, 14 Nov 1997 10:50:49 -0800 (PST) Message-Id: <3.0.3.32.19971114105032.00aed610@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 14 Nov 1997 10:50:32 -0800 To: Bill Stewart , Ian Brown , Adam Back From: Jon Callas Subject: Re: extension mechanism needed Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971114102157.0070deb4@popd.ix.netcom.com> References: <346C6672.777C585C@cs.ucl.ac.uk> <199711141215.MAA01183@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:21 AM 11/14/97 -0800, Bill Stewart wrote: Understanding armour _isn't_ very hard; I'd prefer MUST, especially since it's needed for backward compatibility with PGP 5.0 (in particular, the Encrypt Clipboard doesn't do MIME.) Generating it is a matter of taste - will PGP 5.0 always accept MIME? Even in applications like Decrypt/Verify Clipboard? Thanks Bill. I agree completely. From PRZ's first documents, he labeled armoring as an integral piece of PGP. It's too useful as a generalized mechanism for holding an object (data, keys, etc.) without having to worry about what odd thing something will do to your binary. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23922 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:48:58 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23913 for ; Fri, 14 Nov 1997 10:48:53 -0800 (PST) Received: from users.invweb.net (cppp29.dotstar.net [208.143.93.129]) by users.invweb.net (8.8.7/8.8.7) with SMTP id NAA02274 for ; Fri, 14 Nov 1997 13:49:20 -0500 Message-Id: <199711141849.NAA02274@users.invweb.net> From: "William H. Geiger III" Date: Fri, 14 Nov 97 12:46:43 -0600 To: ietf-open-pgp@imc.org In-Reply-To: <199711141734.SAA18497@basement.replay.com> Subject: Re: closedPGP vs openSMIME X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199711141734.SAA18497@basement.replay.com>, on 11/14/97 at 12:34 PM, nobody@REPLAY.COM (Anonymous) said: >Subject: closedPGP vs openSMIME >So PGP Inc and editors are working on standard, can we participate too? >On ietf-smime there 70 posts in last 3 days, this list only 3! >Working behind closed doors not good for standard. Troll be gone! Go back to RSADSI/Netscape and find somplace else to play. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGyczo9Co1n+aLhhAQEEmgP+Lkl0nTSpTcR7ndD4ElCR+qQfoscfBK9n U8NPKr3bMdjnSAhz5Uc5Zqmdtyu8od+X73b0fW2Wj+qP3vM7qjtMd+4zpmXp0D65 cuJMygxrmRTVcsRfhJa6Ij8KK2uMn4nvLYEjm2K/mIP0smzLKduq1RTE5tm6PBTZ 75sdIwRWH10= =7VcB -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23906 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:48:08 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23902 for ; Fri, 14 Nov 1997 10:48:04 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA02481; Fri, 14 Nov 1997 10:48:24 -0800 (PST) Message-Id: <3.0.3.32.19971114104807.00add8f0@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 14 Nov 1997 10:48:07 -0800 To: Adam Back , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: extension mechanism needed In-Reply-To: <199711141215.MAA01183@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:15 PM 11/14/97 GMT, Adam Back wrote: It would seem that these extensions should be self signed and perhaps attachable to userIDs so that different userIDs could be marked for different capabilities. (Perhaps the client you use at your home email address has the FS extension, but the one at the office does not, etc). Comments? I couldn't agree more. You got it. The draft has spent this week with people not giving me comments. :-) We should have it for you in a day or so. There are two parts of the extension mechanism: a "notation" that is a tag and value (16-bit length for each, no encoding assumed) that can be put in any signature. This is so it can be used both for extensions, but also for human-readable notes. You might, for example, put in a document signature "read but not agreed to". The second part is a "standalone signature" which is a signature that hashes only over its own subpacket contents. This is so you can have signatures that encode their own extension pieces so that they can act like SPKI certificates (or even *hold* SPKI certificates) or any other type of advanced use. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23865 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:45:07 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23861 for ; Fri, 14 Nov 1997 10:45:02 -0800 (PST) Received: from users.invweb.net (cppp29.dotstar.net [208.143.93.129]) by users.invweb.net (8.8.7/8.8.7) with SMTP id NAA02162; Fri, 14 Nov 1997 13:45:04 -0500 Message-Id: <199711141845.NAA02162@users.invweb.net> From: "William H. Geiger III" Date: Fri, 14 Nov 97 12:30:21 -0600 To: Ian Brown In-Reply-To: <346C82A3.1DFC357C@cs.ucl.ac.uk> Cc: Hal Finney , ietf-open-pgp@imc.org, mark@unicorn.com Subject: Re: clearsigned sigs X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <346C82A3.1DFC357C@cs.ucl.ac.uk>, on 11/14/97 at 11:56 AM, Ian Brown said: >Hal Finney wrote: >> I am considering doing sign-and-encrypt by clearsigning and then >> encrypting the clearsigned message. This way you just decrypt and are >> left with a nice clearsigned message, which you can then verify. >>From PGP/MIME: >> 6.2 Combined method >> >> Versions 2.x of PGP also allow data to be signed and encrypted in one >> operation. This method is an acceptable shortcut, and has the >> benefit of less overhead. The resulting data should be formed as a >> "multipart/encrypted" object as described above. >> >> Messages which are encrypted and signed in this combined fashion are >> REQUIRED to follow the same canonicalization rules as for >> multipart/signed objects. >> >> It is explicitly allowed for an agent to decrypt a combined message >> and rewrite it as a multipart/signed object using the signature data >> embedded in the encrypted version. >Could your MUA could do this automatically and rewrite a >signed+encrypted message as cleartext plus a signature message part? This >even hides the PGP data in the mailer, which I like. Well what I am doing in my MUA is the following: When a signed+encrypted message comes in: - -- Decrypt the message - -- Attach a text/X-PGPDecrypt to the message - this displays relevant info about the decryption - -- Verify the signature - -- Attach a text/X-PGPVerify to the message - this displays relevent info about the verification - -- Signature Blocks are retained. So long as the original message is signed then encrypted this works well. When the origianl message is signed & encrypted (one operation) one runs into the problmes mentioned earlier. There are several reasons for the X-PGPVerify text attachment: - -- gives users sig verification info whenever the message is opened without having to re-verify the sigblock. The user has the option to re-verify of course. - -- move signature verification to the server. In a corporate enviroment it may be advantageous to have the server verify the signatures on incoming messages as opposed to the MUA's doing so. Not that the MUA's in such an enviroment should be restricted from doing so. Of course verification can not be done on the server if the message is encrypted. :) - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGybzo9Co1n+aLhhAQHmagQAuMYd7a/WPu+rbq1eDnTGTic/ZxiergGX WX+jHbme0rBWe9YRCcbCOdLuQCd0m+cEL4O1WOCKuvHpwbUcIuWvixJz7WHAYO9w I40ObVApq5ifhcDYjGCx5qcL+2ViHiZrsIZUNphfGnnFM8LVBN/iHjzgROSzHnTr P6Ux6n1qndM= =/q7g -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23583 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:25:49 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23579 for ; Fri, 14 Nov 1997 10:25:45 -0800 (PST) Received: from users.invweb.net (cppp29.dotstar.net [208.143.93.129]) by users.invweb.net (8.8.7/8.8.7) with SMTP id NAA01558; Fri, 14 Nov 1997 13:25:22 -0500 Message-Id: <199711141825.NAA01558@users.invweb.net> From: "William H. Geiger III" Date: Fri, 14 Nov 97 12:17:08 -0600 To: Hal Finney In-Reply-To: <199711141534.HAA13867@s20.term1.sb.rain.org> Cc: ietf-open-pgp@imc.org, mark@unicorn.com Subject: Re: clearsigned sigs X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199711141534.HAA13867@s20.term1.sb.rain.org>, on 11/14/97 at 10:34 AM, Hal Finney said: >I am considering doing sign-and-encrypt by clearsigning and then >encrypting the clearsigned message. This way you just decrypt and are >left with a nice clearsigned message, which you can then verify. This is the default behavior for my PGP implementations. In addition to the sig block being retained for future reference after decryption you have the implementation of sign and forward systems where you would wish to retain multiple signatures. Take the following example: Message X needs to be distributed and signed off by several people: Originator of X signs the message and encrypts it to user 1. User 1 decrypts the messages and then parallel signs the message. He then encrypts it to user 2. This process continues until the originator receives the message with all the signatures from the distribution list. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGyXMI9Co1n+aLhhAQHaWwP8CRA6Dd0ZUvga1Nvr3iqqyKcWsZde9XiH xcBHkaILw2wNVK9mJXeMcHxeNZ1SmAc/yoQLJQyRnNGGeFnTn0G2W13qAC94r1Mt r53duppFkcWOZmYiO8STMpO255tte/stEyhgcHUEyC68XDQXafWyGdQ4PBbN76/C ywIfa2Q0m0g= =7aQJ -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23566 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:25:02 -0800 (PST) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23554 for ; Fri, 14 Nov 1997 10:24:51 -0800 (PST) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id MAA29669; Fri, 14 Nov 1997 12:24:15 -0600 (CST) Received: from pax-ca33-16.ix.netcom.com(204.30.66.240) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma029571; Fri Nov 14 12:22:05 1997 Message-Id: <3.0.3.32.19971114101009.006e8654@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 14 Nov 1997 10:10:09 -0800 To: Adam Back , ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: extension mechanism needed In-Reply-To: <199711141215.MAA01183@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:15 PM 11/14/1997 GMT, Adam Back wrote: >In ESMTP/SMTP there are extension mechanisms. Clients/Servers can use >this mechanism where the other party has it also. This is a very >powerful and simple to add feature. I think we need such an extension >mechanism in OpenPGP. Extension mechanisms require a communication mechanism between the ends of the connection. ESMTP is interactive, so it's easy. In PGP, the only interaction mechanism from the recipient to the sender is the public key record. There's already an extension mechanism for indicating algorithm choices. There's another extension mechanism for indicating additional recipients, but it's apparently controversial :-) >One example I am thinking of is transparent tunneling of SMTP headers >inside the encrytion envelope when both sides are using an encrypting >proxy such as Ian Brown's Enigma. This sounds like a problem for the application programs on the ends, not a problem for PGP itself? >Another might be opportunistic forward secrecy via sending of new EG >keys within each message with relatively short expiry times. That sounds like there's a need for the sender of a key to indicate that it should be used in preference to a previous key, e.g. New: Adam Back, 0x22222222, expires 2/2/1998 Old: Adam Back, 0x11111111, expires 1/1/2000 Supporting this automatically isn't straightforward - what if the new encryption key expires _before_ the old one? And does the extension only apply to EG/DSA keys, or to RSA keys as well (which has lots of complex interaction with trust models.)? There's an obvious need to deal with the semantics of accepting keys, and it sounds like you're proposing that this needs more options? Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23562 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:24:57 -0800 (PST) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA23555 for ; Fri, 14 Nov 1997 10:24:52 -0800 (PST) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id MAA29672; Fri, 14 Nov 1997 12:24:16 -0600 (CST) Received: from pax-ca33-16.ix.netcom.com(204.30.66.240) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma029571; Fri Nov 14 12:22:09 1997 Message-Id: <3.0.3.32.19971114102157.0070deb4@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Fri, 14 Nov 1997 10:21:57 -0800 To: Ian Brown , Adam Back From: Bill Stewart Subject: Re: extension mechanism needed Cc: ietf-open-pgp@imc.org In-Reply-To: <346C6672.777C585C@cs.ucl.ac.uk> References: <199711141215.MAA01183@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 02:55 PM 11/14/1997 +0000, Ian Brown wrote: >Adam Back wrote: >"Implementations MAY understand Armour (see RFC 1991/corrected) for >backward compatibility. They SHOULD use PGP/MIME2 for transport of >OpenPGP messages using mail." > >This allows all other mention of armour to be excised. Understanding armour _isn't_ very hard; I'd prefer MUST, especially since it's needed for backward compatibility with PGP 5.0 (in particular, the Encrypt Clipboard doesn't do MIME.) Generating it is a matter of taste - will PGP 5.0 always accept MIME? Even in applications like Decrypt/Verify Clipboard? Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA23399 for ietf-open-pgp-bks; Fri, 14 Nov 1997 10:10:31 -0800 (PST) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id KAA23390 for ; Fri, 14 Nov 1997 10:10:25 -0800 (PST) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.184.129.129]) with SMTP; 14 Nov 1997 18:10:57 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.8.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id NAA18992 for ; Fri, 14 Nov 1997 13:13:08 -0500 (EST) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 14 Nov 1997 18:10:44 UT Received: from ferguson.vpnet.com (vpnet172.vpnet.com [207.82.103.172]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id NAA27959 for ; Fri, 14 Nov 1997 13:10:39 -0500 (EST) Message-Id: <3.0.3.32.19971114100753.039c142c@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 14 Nov 1997 10:07:53 -0500 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: closedPGP vs openSMIME Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk draft is being physically formatted now for delivery to IETF. If you don't like the process, please leave. >Date: Fri, 14 Nov 1997 18:34:57 +0100 (MET) >Subject: closedPGP vs openSMIME >To: ietf-open-pgp@imc.org >From: nobody@REPLAY.COM (Anonymous) >Organization: Replay and Company UnLimited >X-001: Replay may or may not approve of the content of this posting >X-002: Report misuse of this automated service to >X-URL: http://www.replay.com/remailer/ >Sender: owner-ietf-open-pgp@imc.org > > >Subject: closedPGP vs openSMIME > >So PGP Inc and editors are working on standard, can we participate >too? > >On ietf-smime there 70 posts in last 3 days, this list only 3! > >Working behind closed doors not good for standard. > >-someone > > Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA22959 for ietf-open-pgp-bks; Fri, 14 Nov 1997 09:40:57 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA22955 for ; Fri, 14 Nov 1997 09:40:53 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id UAA10070; Fri, 14 Nov 1997 20:17:46 +0100 (MET) Message-ID: <346C8DAB.C8E82D6@systemics.com> Date: Fri, 14 Nov 1997 17:43:07 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org CC: Hal Finney Subject: Re: clearsigned sigs References: <199711141534.HAA13867@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney wrote: > Unfortunately the text mode signature is done slightly differently than > the cleartext signature. The difference is that cleartext signatures > remove trailing whitespace on each line when calculating the hash. > I believe this was added because some mailers and gateways munged mail > which had trailing whitespace. This is not a problem with signed/encrypted > messages since the cleartext is protected from munging. Aha, I always wondered about this. I had much the same problem with the e$pam mailing lists (an ecommerce thing run by Bob Hettinga). In this case, there is leading spaces rather than trailing spaces, and the sigs don't get picked up. Worse, the spaces start at line 2, so we have one space inserted in every line after the '-----BEGIN' so there is no simple algorithm like "ignore the same spaces before the '-----BEGIN.' Generally, you would have to ignore all the spaces... This is also not the first time that I have seen this munge feature break PGP-style messages. When we send SOX payments around the place, we generally mail them. The user knows to C&P them from the MUA to the SOX agent. However, the leading spaces tend to creep in from either the original C&P or the extraction C&P. This can be very difficult to track down and rectify, and it is much more of a pain when you are dealing with money. A sig that doesn't work can be ignored, broken cash means the loss of a customer. So I would have thought that these packets, when in text-signed or ascii armoured mode, should be readable with both leading or trailing whitespace. I don't know whether I'd make it a SHOULD, but a gentle MAY would at least indicate to programmers of the potential problems. Problem is of course, what happens when I send my signed balance sheet: -----BEGIN MUNGE------ Credits Debits 100 100 -----BEGIN MUNGE SIG----- I promise to pay the bearer the Credits minus the Debits... -----END MUNGE SIG------ > If the message you are signing has no trailing whitespace, you could convert > a signed-and-encrypted message into a clearsigned one by decrypting, > wrapping it in the appropriate headers, and appending the signature in > ascii armor form. The sender could remove any trailing whitespace before > sending it to allow this to happen. A gentle suggestion in the text then. I suppose there will be some software (Hollerith conversions?) that insists on blank padding, so it should not be a SHOULD. > I am considering doing sign-and-encrypt by clearsigning and then > encrypting the clearsigned message. This way you just decrypt and are > left with a nice clearsigned message, which you can then verify. That should be there, yes. One doesn't want to preserve the ascii armouring, but one does want to preserve the sig, and (I would have thought that) one should preserve the clear sig because it is visible, and won't get lost. This makes more sense when you are talking about serious contracts, as people only want to see text and signatures. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA22843 for ietf-open-pgp-bks; Fri, 14 Nov 1997 09:34:32 -0800 (PST) Received: from basement.replay.com (basement.replay.com [194.109.9.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA22839 for ; Fri, 14 Nov 1997 09:34:28 -0800 (PST) Received: (from replay@localhost) by basement.replay.com (8.8.5/RePlay, Inc.) id SAA18497 for ietf-open-pgp@imc.org; Fri, 14 Nov 1997 18:34:57 +0100 (MET) Date: Fri, 14 Nov 1997 18:34:57 +0100 (MET) Message-Id: <199711141734.SAA18497@basement.replay.com> Subject: closedPGP vs openSMIME To: ietf-open-pgp@imc.org From: nobody@REPLAY.COM (Anonymous) Organization: Replay and Company UnLimited X-001: Replay may or may not approve of the content of this posting X-002: Report misuse of this automated service to X-URL: http://www.replay.com/remailer/ Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Subject: closedPGP vs openSMIME So PGP Inc and editors are working on standard, can we participate too? On ietf-smime there 70 posts in last 3 days, this list only 3! Working behind closed doors not good for standard. -someone Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA22338 for ietf-open-pgp-bks; Fri, 14 Nov 1997 08:59:52 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA22327 for ; Fri, 14 Nov 1997 08:59:25 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Nov 1997 16:59:11 +0000 Message-ID: <346C82A3.1DFC357C@cs.ucl.ac.uk> Date: Fri, 14 Nov 1997 16:56:03 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Hal Finney CC: ietf-open-pgp@imc.org, mark@unicorn.com Subject: Re: clearsigned sigs References: <199711141534.HAA13867@s20.term1.sb.rain.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Hal Finney wrote: > I am considering doing sign-and-encrypt by clearsigning and then > encrypting the clearsigned message. This way you just decrypt and are > left with a nice clearsigned message, which you can then verify. >From PGP/MIME: > 6.2 Combined method > > Versions 2.x of PGP also allow data to be signed and encrypted in one > operation. This method is an acceptable shortcut, and has the > benefit of less overhead. The resulting data should be formed as a > "multipart/encrypted" object as described above. > > Messages which are encrypted and signed in this combined fashion are > REQUIRED to follow the same canonicalization rules as for > multipart/signed objects. > > It is explicitly allowed for an agent to decrypt a combined message > and rewrite it as a multipart/signed object using the signature data > embedded in the encrypted version. Could your MUA could do this automatically and rewrite a signed+encrypted message as cleartext plus a signature message part? This even hides the PGP data in the mailer, which I like. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA21374 for ietf-open-pgp-bks; Fri, 14 Nov 1997 07:59:03 -0800 (PST) Received: from coyote.rain.org (root@coyote.rain.org [198.68.144.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA21368 for ; Fri, 14 Nov 1997 07:58:59 -0800 (PST) Received: from s20.term1.sb.rain.org (s23.term2.sb.rain.org [198.68.144.183]) by coyote.rain.org (8.8.5/8.8.5) with ESMTP id IAA13828; Fri, 14 Nov 1997 08:00:51 -0800 (PST) Received: (from hal@localhost) by s20.term1.sb.rain.org (8.7.4/8.7.3) id HAA13867; Fri, 14 Nov 1997 07:34:37 -0800 Date: Fri, 14 Nov 1997 07:34:37 -0800 From: Hal Finney Message-Id: <199711141534.HAA13867@s20.term1.sb.rain.org> To: ietf-open-pgp@imc.org, mark@unicorn.com Subject: Re: clearsigned sigs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk mark@unicorn.com writes: > Ian Grigg [iang@systemics.com] wrote: > >I suggest we clarify this in the standard by saying that clearsigned > >messages SHOULD be signed with sig type of 01, and that readers MAY > >assume that cleartext messages are so signed. > > It's a long time since I implemented the clearsigning code so I don't > remember the details very well, but one feature that I would have liked > to put into my PGP-aware email program was to take the signature from a > signed, encrypted message and use it to create a clearsigned message for archiving. Presumably if normal encrypted messages have binary sigs and clearsigned messages have text sigs, this will be impossible? I think > this was the situation with the PGP version (2.3a?) I was testing for > compatibility. Signed-and-encrypted messages can sign in either text mode or binary mode. If they are done in text mode then it will often work to convert to a cleartext signature. Unfortunately the text mode signature is done slightly differently than the cleartext signature. The difference is that cleartext signatures remove trailing whitespace on each line when calculating the hash. I believe this was added because some mailers and gateways munged mail which had trailing whitespace. This is not a problem with signed/encrypted messages since the cleartext is protected from munging. If the message you are signing has no trailing whitespace, you could convert a signed-and-encrypted message into a clearsigned one by decrypting, wrapping it in the appropriate headers, and appending the signature in ascii armor form. The sender could remove any trailing whitespace before sending it to allow this to happen. I am considering doing sign-and-encrypt by clearsigning and then encrypting the clearsigned message. This way you just decrypt and are left with a nice clearsigned message, which you can then verify. Hal Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA21211 for ietf-open-pgp-bks; Fri, 14 Nov 1997 07:49:13 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA21202 for ; Fri, 14 Nov 1997 07:49:01 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Nov 1997 15:49:24 +0000 Message-ID: <346C7249.422BB5A0@cs.ucl.ac.uk> Date: Fri, 14 Nov 1997 15:46:17 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Adam Back CC: ietf-open-pgp@imc.org Subject: Re: extension mechanism needed References: <199711141215.MAA01183@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk It would actually be *very* simple to do opportunistic forward secrecy with the protocols we have *now*. PGP/MIME defines an application/pgp-keys type. If you sent an FS encryption key with a short expiry time in every n messages, signed with your long term signature key, compatible clients would simply add the key to the user's keyring. Others would ignore it. PGP 2.6 uses the last-added key for any user to encrypt messages, so we could just codify that behaviour in the standard. You wouldn't even need to send out key revocations as the expiry date would be set. You could then securely wipe/archive/whatever the corresponding private key some time after that date. Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA20453 for ietf-open-pgp-bks; Fri, 14 Nov 1997 06:59:51 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA20436 for ; Fri, 14 Nov 1997 06:58:33 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 14 Nov 1997 14:58:50 +0000 Message-ID: <346C6672.777C585C@cs.ucl.ac.uk> Date: Fri, 14 Nov 1997 14:55:46 +0000 From: Ian Brown X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Adam Back CC: ietf-open-pgp@imc.org Subject: Re: extension mechanism needed References: <199711141215.MAA01183@server.test.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Adam Back wrote: > In ESMTP/SMTP there are extension mechanisms. Clients/Servers can use > this mechanism where the other party has it also. This is a very > powerful and simple to add feature. I think we need such an extension > mechanism in OpenPGP. Exactly what I've been thinking of over the last few days, although from a different angle. I agree with Paul Hoffman (IMC) that OpenPGP MUSTs should be absolutely as simple as possible, to allow other standards/programs to incorporate it with minimal effort. We have already abandoned MUST backwards-capability with PGP 2.6 (RSA and IDEA can't be MUSTs) so we could have some paring down of MUSTs to a minimum. PGP backward compatibility could then be just an option for implementations. At a first glance, ALL that would seem to be needed in a minimal implementation would be (using the first draft at the IMC): > PGP provides four services related to the format of messages > and data files: > -digital signature > -encryption > -compression > -radix-64 conversion Only the first two are MUSTs. The second two are specified in RFCs elsewhere, {c/sh}ould be optional, and could even be largely absent from the document - just refer to Zip and MIME RFCs. I've also been looking at PGP/MIME. It REQUIRES Armour use, which was appropriate for backward compatibility but is now not as important. ietf-open-pgp is chartered to replace RFC1991 AND RFC2015 (PGP/MIME) so we could define a version 2 of PGP/MIME which simply encodes binary OpenPGP data like all other MIME data. "Implementations MAY understand Armour (see RFC 1991/corrected) for backward compatibility. They SHOULD use PGP/MIME2 for transport of OpenPGP messages using mail." This allows all other mention of armour to be excised. The current packet types are as follows: > 0 -- Reserved. A packet must not have a tag with this value. > 1 -- Encrypted Session Key Packet > 2 -- Signature Packet > 3 -- Conventionally Encrypted Session Key Packet > 4 -- One-Pass Signature Packet > 5 -- Secret Key Packet > 6 -- Public Key Packet > 7 -- Secret Subkey Packet > 8 -- Compressed Data Packet > 9 -- Symmetrically Encrypted Data Packet > 10 -- Obsolete Literal Packet > 11 -- Literal Data Packet > 12 -- Trust Packet > 13 -- Name Packet > > 14 -- Subkey Packet > 15 -- Reserved > 16 -- Comment Packet Packet headers contain a length, so it is simple for us to specify that packets that are not understood by an implementation should simply be ignored. All vital packets which an implementation MUST understand will be specified in openPGP. At first glance, these would be 1, 2, 5, 6, 9 and 11 (and maybe 3). Keyring management programs would also need to understand 12 and 13. As Peter Gutmann suggested, this need not be part of the base specification. Applications may wish to use a public key without needing to know anything about a userID/email address for it. Public keys should also be securely obtainable from Secure DNS (when it finally rolls out) without an absolute need for signatures. Someone like the IANA could then act as a registry for other, optional packet types. Something Raif Naffah wrote on another list recently: > Assuming you already have the classes to > handle each specific PGP packet, it's easy to process a public or secret > keyring or even a PGP message as a structured sequence of packets. In the > mentioned cases, the structure is well defined by current implementations > of PGP and by proposed standards. > > The tool/bean I'm thinking of would allow the user to define and process > other types of PGP packet sequence(s). Ultimately it can also allow users > to define their own packets. With such a tool, communities can agree and > use their own PGP-based 'structures.' An additional layer of code or data > may allow the encoding of the structure and its elements totally > dissociating the data (the packets contents) from their structure (sequence > of a public keyring, secret keyring, etc...). Finally, the only MUST symmetric encryption algorithm would be 3DES; the only MUST asymmetric encryption algorithm Elgamal; the only MUST signature algorithm DSA. This would allow a very minimal implementation indeed of OpenPGP. All other features would be MAYs. Ian :D Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA19757 for ietf-open-pgp-bks; Fri, 14 Nov 1997 06:22:36 -0800 (PST) Received: from sirius.infonex.com (sirius.infonex.com [206.170.114.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA19745 for ; Fri, 14 Nov 1997 06:22:31 -0800 (PST) Received: (from nobody@localhost) by sirius.infonex.com (8.8.8/8.7.3) id GAA23588; Fri, 14 Nov 1997 06:22:55 -0800 (PST) Date: Fri, 14 Nov 1997 06:22:55 -0800 (PST) From: mark@unicorn.com To: ietf-open-pgp@imc.org Message-Id: <879517374.23587.193.133.230.33@unicorn.com> Subject: Re: clearsigned sigs Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Grigg [iang@systemics.com] wrote: >I suggest we clarify this in the standard by saying that clearsigned >messages SHOULD be signed with sig type of 01, and that readers MAY >assume that cleartext messages are so signed. It's a long time since I implemented the clearsigning code so I don't remember the details very well, but one feature that I would have liked to put into my PGP-aware email program was to take the signature from a signed, encrypted message and use it to create a clearsigned message for archiving. Presumably if normal encrypted messages have binary sigs and clearsigned messages have text sigs, this will be impossible? I think this was the situation with the PGP version (2.3a?) I was testing for compatibility. Mark Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA18585 for ietf-open-pgp-bks; Fri, 14 Nov 1997 04:24:12 -0800 (PST) Received: from www11-gui.server.virgin.net (www11-gui.server.virgin.net [194.168.54.17]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA18581 for ; Fri, 14 Nov 1997 04:24:07 -0800 (PST) Received: from server.test.net ([194.168.59.219]) by www11-gui.server.virgin.net (Post.Office MTA v3.1.2 release (PO203-101c) ID# 0-0U10L2S100) with ESMTP id AAA2005 for ; Fri, 14 Nov 1997 12:24:32 +0000 Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id MAA01183; Fri, 14 Nov 1997 12:15:10 GMT Date: Fri, 14 Nov 1997 12:15:10 GMT Message-Id: <199711141215.MAA01183@server.test.net> From: Adam Back To: ietf-open-pgp@imc.org Subject: extension mechanism needed Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In ESMTP/SMTP there are extension mechanisms. Clients/Servers can use this mechanism where the other party has it also. This is a very powerful and simple to add feature. I think we need such an extension mechanism in OpenPGP. One example I am thinking of is transparent tunneling of SMTP headers inside the encrytion envelope when both sides are using an encrypting proxy such as Ian Brown's Enigma. (This allows mutliple recipients to be broken up into separately delivered single recipient messages and the Cc fields reconstructed by the decryption agent for the MUA. Useful also for mixmaster delivery, which such a proxy agent can automatically manage.) Another might be opportunistic forward secrecy via sending of new EG keys within each message with relatively short expiry times. Both of these would be hacky if one had no formal way to determine the extensions the recipient's software could handle, as one would be forced to hack or tweak various values in the existing spec in ways which would hopefully not break other implementations. I want to be able to encode: Extension: Forward-secrecy, SMTP-header-tunneling In such a way that implementations without these extensions will know to ignore those it does not understand. It would seem that these extensions should be self signed and perhaps attachable to userIDs so that different userIDs could be marked for different capabilities. (Perhaps the client you use at your home email address has the FS extension, but the one at the office does not, etc). Comments? (btw I am now manually using the FS extension... use key below for Nov, on 2nd Dec the private key gets burnt). Adam Type Bits/KeyID Date User ID pub 2048/CA2A006D 1997/11/06 Adam Back (FS key, Nov 97) -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i mQENAzRiPnQAAAEIAMQqkuRbiy3sofhHVTTGp2UCYQL9VY91CGMXqKW5Y0IgR0qS SLlq6xmdI1OkLuyxPNClLs9Qkie6LXJK7oFuNhEOmoNkLATgAHs3R2Jr24O6jmUf F+ohoII6iUyE8RNO1iv2L94fi6IR6bZTvcIPb6gcqEtFNjg07oc2d0O419dJfCud Z95/Hh91b/J6GesbKd66rqnyhrszmBQ6cbLKGtTj8BWSg04KLDcZRxxzfcFWltF3 qFV36/cUIbK+ev10ZJw/z1iV8t/pzQ8kOvVlNbyOOZ3+/HpIrC2BEdhpGFDQSQlA duWxNAmiorSxhmGfWBDa0ZCGj2sKW7W/OcoqAG0ABRO0LUFkYW0gQmFjayA8YWJh QGRjcy5leC5hYy51az4gKEZTIGtleSwgTm92IDk3KYkBFQMFEDRiP8I+e8qoKLJF UQEB3O8H/2nW1Ng2A0gkk7ueCt/o2tnWFiK8p1V4RPtZ/SpU9xSolJIYs8evYFTg VFyZEKR1YZ/a1gp0pr1/3b6vRHidJgzZpRpx21jDXMPx8VLS32NQRTJkN7+OMiAo ls5Oj8LRRlWroXfGnb7YxV+O8J7r11YaCMB/eMObrg7VMFg9Q8V0ct8gYQvCu9hZ jwYn/Ldi1A5HQdCce7n9EzHoChjjGFGIH5IlPquSbfMLJP7VASimwoBhe7dq3rLz u9Y1oOAq4xQ3K9Op7ieR28Ad+OBmv+qQP22BJ3u2OtwnabIOgjJ4uH6Ulr+r6qwo oEVT2p9hCKBTW1uZk/19TZSX04VfCHyJARUDBRA0Yj7wW7W/OcoqAG0BAc4GB/9r EHKIVCD+XPDPVKCuiovhHb61BHQKc+fT+xfemR/fg2FHdTz1Arrsubqr/IdYHsNK OwWf9J2/IOcKPqhMKh3i42cIMaJ4VM5T5CFGlVEfr7GUDjFzljz4oGfAwfY6IWnL ozpfqe2bzt72uWvAvPkxx+Ue8qQqDlU57udihP8dtA0qgH+JAMJ5bjvg1krdbIg9 T3989mbmBg+6tlxq3Vfp/Zb9D1rD/XC2+JyoGIdaLej2tIXxisq7uixwDSX6jEJX 4wW0qEnONNwlIukJLEu69WqUeOEJhCV1jRNvY3m8rmyKSHr5p037LRX3GmdrNwsW RPRFkNaBTo/OFhUtH1Nx =9Cl1 -----END PGP PUBLIC KEY BLOCK----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA11957 for ietf-open-pgp-bks; Thu, 13 Nov 1997 21:44:42 -0800 (PST) Received: from dfw-ix15.ix.netcom.com (dfw-ix15.ix.netcom.com [206.214.98.15]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA11952 for ; Thu, 13 Nov 1997 21:44:37 -0800 (PST) Received: (from smap@localhost) by dfw-ix15.ix.netcom.com (8.8.4/8.8.4) id XAA08012; Thu, 13 Nov 1997 23:44:01 -0600 (CST) Received: from sjc-ca1-07.ix.netcom.com(207.94.249.39) by dfw-ix15.ix.netcom.com via smap (V1.3) id rma007984; Thu Nov 13 23:43:53 1997 X-Sender: frantz@netcom6.netcom.com Message-Id: In-Reply-To: <346BACCD.7E364E8B@systemics.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Nov 1997 21:29:12 -0800 To: Ian Grigg , ietf-open-pgp@imc.org From: Bill Frantz Subject: Re: clearsigned sigs Cc: colin@nyx.net, hal@rain.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 5:43 PM -0800 11/13/97, Ian Grigg wrote: >I suggest we clarify this in the standard by saying that clearsigned >messages SHOULD be signed with sig type of 01, and that readers MAY >assume that cleartext messages are so signed. > >Or some such language. The intent should be clear: there is validity in >assuming that clear-signed is sig type of text. Detached signatures for clearsigned binary executables are still useful. It seems reasonable for this use to jump thru special hoops while the more common text use is the default. ------------------------------------------------------------------------- Bill Frantz | Internal surveillance | Periwinkle -- Consulting (408)356-8506 | helped make the USSR the | 16345 Englewood Ave. frantz@netcom.com | nation it is today. | Los Gatos, CA 95032, USA Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA08636 for ietf-open-pgp-bks; Thu, 13 Nov 1997 17:41:35 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id RAA08630 for ; Thu, 13 Nov 1997 17:41:27 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id EAA07984; Fri, 14 Nov 1997 04:18:13 +0100 (MET) Message-ID: <346BACCD.7E364E8B@systemics.com> Date: Fri, 14 Nov 1997 01:43:41 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org CC: colin@nyx.net, hal@rain.org Subject: clearsigned sigs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk A week or two ago I was trying to debug messages that were encrypted by Cryptix and undecryptable by pgp5.x. The problem turned out to be a confusion surrounding how pgp2.6 treated clearsigned messages. In the signature packet there is a signature type byte with values 00 and 01. This refers to the way in which the has is calculated over the preceding text: 00 data is binary 01 data is text, treat as ISO Latin-1 with endings (adding those characters if necessary. pgp 2.6 didn't mind if you did a 00 sig over a clear signed message. Cryptix produced a binary sig over clear text (for some reason), and everyone was happy until pgp5.x came along and assumed that clear signed messages must be text. I suggest we clarify this in the standard by saying that clearsigned messages SHOULD be signed with sig type of 01, and that readers MAY assume that cleartext messages are so signed. Or some such language. The intent should be clear: there is validity in assuming that clear-signed is sig type of text. My thanks to Hal Finney and Colin Plumb for assisting in this. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA08418 for ietf-open-pgp-bks; Mon, 10 Nov 1997 22:48:52 -0800 (PST) Received: from dfw-ix2.ix.netcom.com (dfw-ix2.ix.netcom.com [206.214.98.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA08409 for ; Mon, 10 Nov 1997 22:48:47 -0800 (PST) Received: (from smap@localhost) by dfw-ix2.ix.netcom.com (8.8.4/8.8.4) id AAA10313; Tue, 11 Nov 1997 00:47:45 -0600 (CST) Received: from sjc-ca5-13.ix.netcom.com(207.94.249.173) by dfw-ix2.ix.netcom.com via smap (V1.3) id rma010137; Tue Nov 11 00:46:34 1997 X-Sender: frantz@netcom6.netcom.com Message-Id: In-Reply-To: <199711101930.OAA09425@users.invweb.net> References: <199711101804.TAA15784@sema.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 10 Nov 1997 20:45:55 -0800 To: "William H. Geiger III" , "Alain Zahm" From: Bill Frantz Subject: Re: IETF process Cc: "David P. Kemp" , Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:28 AM -0800 11/10/97, William H. Geiger III wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >In <199711101804.TAA15784@sema.fr>, on 11/10/97 > at 12:42 PM, "Alain Zahm" said: > >>One (more) silly question: what about MOSS? Isn(t it THE INTERNET >>standard for secured email? > >Heh, Is anyone useing it?? :) Since IETF standards must achieve market acceptance, this answer is more relevant than it appears at first. As far as I can tell: (1) There is no such thing as THE internet standard. There are usually several to chose from. Although those who wish to communicate tend to use IP. :-) (2) Even when there are well established standards, people are free to start a working group to make a new standard. SPKI is an example. ------------------------------------------------------------------------- Bill Frantz | Internal surveillance | Periwinkle -- Consulting (408)356-8506 | helped make the USSR the | 16345 Englewood Ave. frantz@netcom.com | nation it is today. | Los Gatos, CA 95032, USA Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA01321 for ietf-open-pgp-bks; Mon, 10 Nov 1997 12:08:56 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA01317 for ; Mon, 10 Nov 1997 12:08:52 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPUE6BG6XC9JEIBJ@INNOSOFT.COM> for ietf-open-pgp@imc.org; Mon, 10 Nov 1997 12:08:07 PST Date: Mon, 10 Nov 1997 12:05:00 -0800 (PST) From: Ned Freed Subject: Re: IETF process In-reply-to: "Your message dated Mon, 10 Nov 1997 18:42:47 +0100" <199711101804.TAA15784@sema.fr> To: Alain Zahm Cc: "David P. Kemp" , ietf-open-pgp@imc.org Message-id: <01IPUEFOZ18G9JEIBJ@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > One (more) silly question: what about MOSS? Isn(t it THE INTERNET standard > for secured email? Nope. MOSS is currently a proposed standard. Due to lack of implementation (something the IETF process requires) it is unlikely to ever move to draft standard. My expectation is that it will be moved to historic once one or more other protocols are on the standards track that replace it and are clearly seeing widespread deployment and interoperable use. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA00771 for ietf-open-pgp-bks; Mon, 10 Nov 1997 11:31:25 -0800 (PST) Received: from users.invweb.net (users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA00762 for ; Mon, 10 Nov 1997 11:31:17 -0800 (PST) Received: from users.invweb.net (cppp28.dotstar.net [208.143.93.128]) by users.invweb.net (8.8.7/8.8.7) with SMTP id OAA09425; Mon, 10 Nov 1997 14:30:49 -0500 Message-Id: <199711101930.OAA09425@users.invweb.net> From: "William H. Geiger III" Date: Mon, 10 Nov 97 13:28:39 -0600 To: "Alain Zahm" In-Reply-To: <199711101804.TAA15784@sema.fr> Cc: "David P. Kemp" , Subject: Re: IETF process X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199711101804.TAA15784@sema.fr>, on 11/10/97 at 12:42 PM, "Alain Zahm" said: >One (more) silly question: what about MOSS? Isn(t it THE INTERNET >standard for secured email? Heh, Is anyone useing it?? :) - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGdgf49Co1n+aLhhAQHkTAQArZcscK96Z5+T9adRUE9dRTcP6dumtjwG SiuoNKFRiL5QfYRG8dMqczeFtcrBCLym4A6pTyTnOdR0OpzwCF9u5CD8H0Q2LqdW 5XVVIDKiYYErEMgEqAmgei+/rcOU8BrVbHt86P7thGcKA1C+wSuFICoXxLNe6ENE qdvDzCwYEPA= =8zVU -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA00307 for ietf-open-pgp-bks; Mon, 10 Nov 1997 10:58:56 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA00303 for ; Mon, 10 Nov 1997 10:58:52 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA21812; Mon, 10 Nov 1997 10:56:55 -0800 (PST) Message-Id: <3.0.3.32.19971110105732.00b7e930@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 10 Nov 1997 10:57:32 -0800 To: Ian Grigg , Bill Stewart From: Jon Callas Subject: Re: CART before the HORSE Cc: ietf-open-pgp@imc.org In-Reply-To: <3466E3FC.31D2DE92@systemics.com> References: <199710311342.IAA18637@argon.ncsc.mil> <3.0.3.32.19971109172842.006f1050@popd.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 10:37 AM 11/10/97 +0000, Ian Grigg wrote: I thought that actually pgp5.x does use ElGamal, Jon posted that the reason it was called Diffie Hellman was the name recognition. I would hope that the Open PGP standard does not incorporate this confusion and uses the appropriate technical name for the algorithm. Yes, in the draft, Elgamal is called Elgamal. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA00297 for ietf-open-pgp-bks; Mon, 10 Nov 1997 10:58:07 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA00289 for ; Mon, 10 Nov 1997 10:58:03 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id KAA21855; Mon, 10 Nov 1997 10:58:17 -0800 (PST) Message-Id: <3.0.3.32.19971110105854.00b85410@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 10 Nov 1997 10:58:54 -0800 To: Robert Guerra , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: specifying In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:20 PM 11/8/97 -0500, Robert Guerra wrote: I'd like to know if the new draft includes a provision that which allows the creator of a key to specify which algorythym he prefers senders to use. For example, will there be a way to specify that the users using (public) key A encrypt messages using algo. X? Perhaps this might be included in the self-signature section? Yes, that is there, and in the self-signature, just like you suggest. There are also preferences for other things, too, like what your preferred compression is (particularly if you want things uncompressed). Some of the preferences are controversial, and I have some notes describing the controversy. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA00190 for ietf-open-pgp-bks; Mon, 10 Nov 1997 10:53:23 -0800 (PST) Received: from sema.fr (mailrelay.sema.fr [193.106.58.161]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA00182 for ; Mon, 10 Nov 1997 10:53:15 -0800 (PST) Received: from jeanlain.sophia.sema.fr (sophia.sema.fr [10.1.1.1]) by sema.fr (8.8.4/8.8.4) with SMTP id TAA15784; Mon, 10 Nov 1997 19:04:49 +0100 (MET) Message-Id: <199711101804.TAA15784@sema.fr> Received: from BACON [10.1.1.34] by jeanlain.sophia.sema.fr (AltaVista Mail V2.0/2.0 BL23 listener) id 0000_0061_3467_486a_019c; Mon, 10 Nov 1997 18:46:18 +0100 From: "Alain Zahm" To: "David P. Kemp" , Subject: Re: IETF process Date: Mon, 10 Nov 1997 18:42:47 +0100 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk One (more) silly question: what about MOSS? Isn(t it THE INTERNET standard for secured email? ---------- > De : David P. Kemp > A : ietf-open-pgp@imc.org > Objet : Re: IETF process > Date : lundi 10 novembre 1997 16:27 > > > From: Ned Freed > > > > This then means that there will be no less than four S/MIMEs: > > > > (1) The original RSADSI S/MIME. > > (2) The one that's coming out as a set of informational RFCs. > > (3) The one the WG will standardize. > > (4) The one that will result from the PKCS rewrite that RSADSI is supposedly > > doing. > > > > Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of > > compatibility between all of them -- I wouldn't know about that. But let's hope > > that we don't have quite so many PGPs... > > > Wow, that would be a lot of S/MIMEs, if they were truly different. But... > (1) and (2) are supposed to describe the identical (not just compatible) > protocol - it's just a matter of writing down S/MIME v2 as Informational > RFCs, perhaps making technical corrections, clarifications, and collecting > dispersed information into a single document. This would be analogous to > publishing an Informational RFC on PGP 2.6. > > There is discussion regarding (3) and (4); IETF S/MIME was originally > supposed to be based on the PKCS#7 v2 message syntax, but the Internet > Drafts for IETF S/MIME are now based on PKCS#7 v1.5, with the minimum > changes required to accommodate algorithm flexibility, signed receipts, > and a couple of other flaws. This syntax might have been called PKCS#7 > v1.7 (v1.6 included mods to accommodate the SET credit card > protocol), but it is not - the PKCS#7 name will no longer be used - it > is now called the S/MIME Cryptographic Message Syntax (CMS). > > The evolution of CMS will be determined entirely by the IETF S/MIME > working group - it may incorporate features from the independently-evolving > PKCS#7 v2 or it may not. But in no case will there be two IETF (Standard) > S/MIMEs; there will be only one, and it will be based on CMS. > > To summarize, there will be only two S/MIMEs: v2 described by original > RSA documents and Informational RFCs, and v3 described by whatever > Standard RFCs are produced by the working group. There is the intent > that v3 will *allow* backwards interoperability with v2, but there is > no MUST requirement for implementations to support backwards-compatible > algorithms and message formats. > > Sorry to burden the PGP list with this level of detail on the competition, > but accurate information is in everyone's best interest. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA26585 for ietf-open-pgp-bks; Mon, 10 Nov 1997 07:28:55 -0800 (PST) Received: from guardian.guard.ncsc.mil (guardian.guard.ncsc.mil [144.51.52.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA26580 for ; Mon, 10 Nov 1997 07:28:51 -0800 (PST) Received: (from uucp@localhost) by guardian.guard.ncsc.mil (8.6.12/8.6.9) id KAA03584 for ; Mon, 10 Nov 1997 10:28:41 -0500 Received: from depot(144.51.53.1) by guardian via smap (V1.3) id sma003582; Mon Nov 10 10:28:27 1997 Received: from argon.ncsc.mil (argon.missi.ncsc.mil [144.51.56.1]) by depot.missi.ncsc.mil (8.6.12/8.6.9) with ESMTP id KAA04005 for ; Mon, 10 Nov 1997 10:25:44 -0500 Received: by argon.ncsc.mil (SMI-8.6/SMI-SVR4) id KAA00428; Mon, 10 Nov 1997 10:27:15 -0500 Date: Mon, 10 Nov 1997 10:27:15 -0500 From: dpkemp@missi.ncsc.mil (David P. Kemp) Message-Id: <199711101527.KAA00428@argon.ncsc.mil> To: ietf-open-pgp@imc.org Subject: Re: IETF process X-Sun-Charset: US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > From: Ned Freed > > This then means that there will be no less than four S/MIMEs: > > (1) The original RSADSI S/MIME. > (2) The one that's coming out as a set of informational RFCs. > (3) The one the WG will standardize. > (4) The one that will result from the PKCS rewrite that RSADSI is supposedly > doing. > > Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of > compatibility between all of them -- I wouldn't know about that. But let's hope > that we don't have quite so many PGPs... Wow, that would be a lot of S/MIMEs, if they were truly different. But... (1) and (2) are supposed to describe the identical (not just compatible) protocol - it's just a matter of writing down S/MIME v2 as Informational RFCs, perhaps making technical corrections, clarifications, and collecting dispersed information into a single document. This would be analogous to publishing an Informational RFC on PGP 2.6. There is discussion regarding (3) and (4); IETF S/MIME was originally supposed to be based on the PKCS#7 v2 message syntax, but the Internet Drafts for IETF S/MIME are now based on PKCS#7 v1.5, with the minimum changes required to accommodate algorithm flexibility, signed receipts, and a couple of other flaws. This syntax might have been called PKCS#7 v1.7 (v1.6 included mods to accommodate the SET credit card protocol), but it is not - the PKCS#7 name will no longer be used - it is now called the S/MIME Cryptographic Message Syntax (CMS). The evolution of CMS will be determined entirely by the IETF S/MIME working group - it may incorporate features from the independently-evolving PKCS#7 v2 or it may not. But in no case will there be two IETF (Standard) S/MIMEs; there will be only one, and it will be based on CMS. To summarize, there will be only two S/MIMEs: v2 described by original RSA documents and Informational RFCs, and v3 described by whatever Standard RFCs are produced by the working group. There is the intent that v3 will *allow* backwards interoperability with v2, but there is no MUST requirement for implementations to support backwards-compatible algorithms and message formats. Sorry to burden the PGP list with this level of detail on the competition, but accurate information is in everyone's best interest. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA22078 for ietf-open-pgp-bks; Mon, 10 Nov 1997 02:37:53 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id CAA22070 for ; Mon, 10 Nov 1997 02:37:49 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id NAA20494; Mon, 10 Nov 1997 13:11:43 +0100 (MET) Message-ID: <3466E3FC.31D2DE92@systemics.com> Date: Mon, 10 Nov 1997 10:37:48 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Bill Stewart CC: ietf-open-pgp@imc.org Subject: Re: CART before the HORSE References: <199710311342.IAA18637@argon.ncsc.mil> <3.0.3.32.19971109172842.006f1050@popd.ix.netcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart wrote: > > On the other hand, Diffie-Hellman is generally used in interactive > applications, such as SSL, not batch applications like email encryption - > it's clearly the right choice for those applications. > Open-PGP is probably better off using ElGamal, but it's not a no-brainer. I thought that actually pgp5.x does use ElGamal, Jon posted that the reason it was called Diffie Hellman was the name recognition. I would hope that the Open PGP standard does not incorporate this confusion and uses the appropriate technical name for the algorithm. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA19599 for ietf-open-pgp-bks; Mon, 10 Nov 1997 00:42:20 -0800 (PST) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA19588 for ; Mon, 10 Nov 1997 00:42:09 -0800 (PST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id CAA09131 for ; Mon, 10 Nov 1997 02:41:52 -0600 (CST) Received: from pax-ca11-19.ix.netcom.com(204.30.66.179) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma009089; Mon Nov 10 02:41:41 1997 Message-Id: <3.0.3.32.19971109214231.006f1050@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 09 Nov 1997 21:42:31 -0800 To: ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?) In-Reply-To: <199711021337.NAA09022@server.test.net> References: <199711021302.IAA30916@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >> Anyway, I agree with the people who are arguing for MUST for 3DES, >> DSA, Elgamal; and SHOULD for RSA, IDEA, MD5, and MAY for the rest. Presumably SHA-1 also belongs in MUST? >A very basic reason: SHOULD is only for things that are strongly desired >by all implementations. If we have a strong algorithm for a MUST and >another strong algorithm for a SHOULD, I see no point to tossing another >SHOULD in. Many developers try to implement all SHOULD-level specs, and >this would cause needless software bloat with little definable benefit. 3DES is MUST, because everybody trusts it, but nobody really likes it :-) IDEA is fine, and fast enough to use, but encumbered. Adding CAST5 as a SHOULD sets a direction that we want a fast free algorithm to be the primary operating mode, which I think is good, and says that enough people trust CAST5 that it's the best choice - is that realistic? Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA19596 for ietf-open-pgp-bks; Mon, 10 Nov 1997 00:42:15 -0800 (PST) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA19589 for ; Mon, 10 Nov 1997 00:42:09 -0800 (PST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id CAA09127 for ; Mon, 10 Nov 1997 02:41:52 -0600 (CST) Received: from pax-ca11-19.ix.netcom.com(204.30.66.179) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma009089; Mon Nov 10 02:41:38 1997 Message-Id: <3.0.3.32.19971109175100.006f1050@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 09 Nov 1997 17:51:00 -0800 To: ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: Conflicts and Options... In-Reply-To: References: <87881584925188@cs26.cs.auckland.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >* Peter Gutmann wrote: >>running PGP on pocket calculators and the like) is that it'd be a good idea to >>finally split the key management off into a seperate program, especially with >>the extra bloat added by the new algorithms and key packets. About 99% of the PGP 5.0 mostly does that, at least on Win95 - there's a PGPkeys program that does the fancy key management, and the main PGPtray program that does encryption, decryption, signatures, and verification, though it also does "Add Key From Clipboard". Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA19587 for ietf-open-pgp-bks; Mon, 10 Nov 1997 00:42:07 -0800 (PST) Received: from dfw-ix9.ix.netcom.com (dfw-ix9.ix.netcom.com [206.214.98.9]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA19578 for ; Mon, 10 Nov 1997 00:42:02 -0800 (PST) Received: (from smap@localhost) by dfw-ix9.ix.netcom.com (8.8.4/8.8.4) id CAA09105 for ; Mon, 10 Nov 1997 02:41:46 -0600 (CST) Received: from pax-ca11-19.ix.netcom.com(204.30.66.179) by dfw-ix9.ix.netcom.com via smap (V1.3) id rma009089; Mon Nov 10 02:41:29 1997 Message-Id: <3.0.3.32.19971109172842.006f1050@popd.ix.netcom.com> X-Sender: stewarts@popd.ix.netcom.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.3 (32) Date: Sun, 09 Nov 1997 17:28:42 -0800 To: ietf-open-pgp@imc.org From: Bill Stewart Subject: Re: CART before the HORSE In-Reply-To: References: <199710311342.IAA18637@argon.ncsc.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On the other hand, Diffie-Hellman is generally used in interactive applications, such as SSL, not batch applications like email encryption - it's clearly the right choice for those applications. Open-PGP is probably better off using ElGamal, but it's not a no-brainer. >On Fri, 31 Oct 1997, David P. Kemp wrote: >> > If compatibility with pgp2.6, etc, is a MUST, then RSA is a MUST. Is >> > this acceptable? Have we already made a decision on RSA, or has the >> > IETF already pronounced (via the S/MIME group) a leaning on this? >> >> The TLS group has decided that there is only one MUST algorithm, >> DSA/DH/3DES, despite the fact that nearly 100% of the installed base >> of SSL currently uses RSA/RC4. At 04:43 PM 10/31/1997 +0200, Markku-Juhani Saarinen wrote: > We have chosen the exactly same MUST algorithms in IETF-SecSh work > (see draft-ietf-secsh-transport-02.txt). Thanks! Bill Bill Stewart, stewarts@ix.netcom.com Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA19426 for ietf-open-pgp-bks; Mon, 10 Nov 1997 00:28:15 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA19422 for ; Mon, 10 Nov 1997 00:28:11 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id JAA29028; Mon, 10 Nov 1997 09:28:21 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: specifying Date: 10 Nov 1997 08:28:21 GMT Organization: IKS GmbH Jena Lines: 10 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Robert Guerra wrote: >I'd like to know if the new draft includes a provision that which allows >the creator of a key to specify which algorythym he prefers senders to use. > >For example, will there be a way to specify that the users using (public) >key A encrypt messages using algo. X? > >Perhaps this might be included in the self-signature section? It is included. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA16795 for ietf-open-pgp-bks; Sun, 9 Nov 1997 20:20:23 -0800 (PST) Received: from bi-node.foebud.org (root@bi-node.foebud.org [194.77.23.10]) by mail.proper.com (8.8.7/8.7.3) with SMTP id UAA16791 for ; Sun, 9 Nov 1997 20:20:17 -0800 (PST) Received: from bionic.zerberus.de with zconnect by bi-node.foebud.org with zconnect (/\oo/\ Smail3.1.29.1 #29.1 #1) id m0xUjZ6-0023woC; Mon, 10 Nov 97 03:27 MET Received: from localhost by nescio.zerberus.de with smtp (Smail3.1.29.1 #7) id m0xUWir-000FSVC; Sun, 9 Nov 97 13:44 MET To: ietf-open-pgp@imc.org Message-Id: From: christopher@nescio.foebud.org (Christopher Creutzig) Path: bionic.zerberus.de!nescio.foebud.org!christopher Subject: Re: Symmetric Algorithm Date: Sun, 9 Nov 1997 13:44:12 +0100 (MET) References: <3.0.3.32.19971028175455.00b43490@mail.pgp.com> X-Gateway: ZCONNECT bi-node.foebud.org [UNIX/Connect v0.75b4], RFC1036/822 nescio.zerberus.de [UNIX/Connect v0.75b4/19970818] Lines: 22 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 28 Oct 1997, Jon Callas wrote: -> (4) What other algorithm(s) do you want to see as MAY algorithms? I'd like something similar to the ssh-specs, where you can introduce new ciphers "on the fly", if you wish to, by just giving them a string as a name which needs to be unique, so they suggest "ciphername@my.do.main" for that purpose, e.g. "distorted-blowfish@foebud.org" or something like that. I think introducing a magic number which says "there's a packet with a string following which specifies the algorithm" shouldn't be too hard. The same applies for the public key algorithm, btw, there's at least RSA, McEliece, ElGamal and Chor-Rivest and variants of these (especially elliptic curves come to mind) for encryption and a whole bunch of others for signatures. I think an "open" standard should allow implementing new algorithms easily. -- Christopher Creutzig # Im Samtfelde 19 # D-33098 Paderborn # V+49-5251-71873 # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # "Das kann doch nicht so schwer sein, so ein paar Header zu erzeugen!" (Eike Rathke auf der Gatebau'97) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA16586 for ietf-open-pgp-bks; Sun, 9 Nov 1997 19:54:10 -0800 (PST) Received: from bozo.MIT.EDU (BOZO.MIT.EDU [18.72.0.198]) by mail.proper.com (8.8.7/8.7.3) with SMTP id TAA16581; Sun, 9 Nov 1997 19:54:06 -0800 (PST) Received: from rw-177.mit.edu by bozo.MIT.EDU with SMTP id DAA22227; Mon, 10 Nov 1997 03:54:01 GMT Message-Id: <3.0.3.32.19971109224918.006f73a8@e40-po.mit.edu> X-Sender: jis@e40-po.mit.edu (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 09 Nov 1997 22:49:18 -0500 To: Ian Grigg , phoffman@imc.org From: "Jeffrey I. Schiller" Subject: Re: patent freedom & compatibility Cc: ietf-open-pgp@imc.org In-Reply-To: <34623708.3D6D0E98@systemics.com> References: <3.0.3.32.19971106074236.0396e080@pop.pn.com> <3.0.3.32.19971106111827.0390aa6c@pop.pn.com> <3.0.5.32.19971106120524.00849ad0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:30 PM 11/6/97 +0000, Ian Grigg wrote: >OK, I'll ask directly, and we'll put this to bed. > >Jeff, do you accept Ned Freed's post of today to Open PGP under "Re: >IETF process" as accurately describing the "Munich doctrine" and its >effect on this WG? Its a good first approximation. Also remember Ned's comment about the IETF Process being dynamic. -Jeff Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA11164 for ietf-open-pgp-bks; Sun, 9 Nov 1997 09:24:00 -0800 (PST) Received: from f85.hotmail.com (F85.hotmail.com [207.82.250.191]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA11160 for ; Sun, 9 Nov 1997 09:23:56 -0800 (PST) Received: (from root@localhost) by f85.hotmail.com (8.8.5/8.8.5) id JAA27505; Sun, 9 Nov 1997 09:25:00 -0800 (PST) Message-Id: <199711091725.JAA27505@f85.hotmail.com> Received: from 209.86.48.23 by www.hotmail.com with HTTP; Sun, 09 Nov 1997 09:24:59 PST X-Originating-IP: [209.86.48.23] From: "Adam Hoier" To: ietf-open-pgp@imc.org, rah@shipwright.com Subject: Re: Orthogonality and Disaster Recovery Content-Type: text/plain Date: Sun, 09 Nov 1997 09:24:59 PST Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Could some1 pleez send me PGP in an Email Attachment PLEEZ ID REALLY APPRECIATE IT!!!! ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA01443 for ietf-open-pgp-bks; Sat, 8 Nov 1997 12:20:37 -0800 (PST) Received: from mail.the-wire.com (mail.the-wire.com [198.53.192.5]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA01438 for ; Sat, 8 Nov 1997 12:20:32 -0800 (PST) Received: from [205.206.36.71] (rguerra.the-wire.com [205.206.36.71]) by mail.the-wire.com (8.8.8/8.8.8) with ESMTP id PAA12815 for ; Sat, 8 Nov 1997 15:19:44 -0500 (EST) X-Sender: rguerra@mail.the-wire.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-PGP-RSAkey: http://swissnet.ai.mit.edu:11371/pks/lookup?op=get&search=0x89619BC5 X-PGP-DSSkey: http://keys.pgp.com:11371/pks/lookup?op=index&search=0x4B408E7B Date: Sat, 8 Nov 1997 15:20:19 -0500 To: ietf-open-pgp@imc.org From: Robert Guerra Subject: specifying Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I'd like to know if the new draft includes a provision that which allows the creator of a key to specify which algorythym he prefers senders to use. For example, will there be a way to specify that the users using (public) key A encrypt messages using algo. X? Perhaps this might be included in the self-signature section? regards robert Robert Guerra - PGP public key available on PGP key servers Email-> mailto:az096@freenet.toronto.on.ca Home Page-> http://www.geocities.com/CapitolHill/3378 Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA00825 for ietf-open-pgp-bks; Sat, 8 Nov 1997 11:20:21 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA00819 for ; Sat, 8 Nov 1997 11:20:16 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id LAA10619; Sat, 8 Nov 1997 11:17:57 -0800 (PST) Message-Id: <3.0.5.32.19971108112024.00835bc0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 08 Nov 1997 11:20:24 -0800 To: Ned Freed , ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: IETF process In-Reply-To: <01IPRJDDO78A9JE0S5@INNOSOFT.COM> References: <"Your message dated Thu, 06 Nov 1997 20:04:36 +0000" <346222D4.7E7CDD5F@systemics.com> <01IPOR2HIYII9JE0S5@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk The ietf-open-pgp mailing list isn't the most appropriate place for discussing S/MIME, is it? :-) I'd like to point people over to the mailing list for the just-formed S/MIME Working Group at ietf-smime@imc.org. However, since there is a bit of confusion still here, I'd like to clear it up so it doesn't get in the way of the decisions being made here about OpenPGP. At 10:26 AM 11/8/97 -0800, Ned Freed wrote: >This then means that there will be no less than four S/MIMEs: > >(1) The original RSADSI S/MIME. >(2) The one that's coming out as a set of informational RFCs. >(3) The one the WG will standardize. >(4) The one that will result from the PKCS rewrite that RSADSI is supposedly > doing. Nope, sorry. The number will be two. - It's not clear that anyone ever implemented (1) - (2) is what is out there today - (3) is what will be out there if the S/MIME WG does its job - (4) will not be created For (4), there are no plans for the S/MIME spec to use the revised PKCS #7 format if it ever comes out. All desired changes for S/MIME that might be made in PKCS #7 should be made to the CMS that will be used in S/MIME v3. At the last S/MIME developer's meeting, there was a very definite choice to support (3) and not to try to do (4). Further, (4) is *not* on the charter for the S/MIME WG. There's a good chance the S/MIME WG will have dissolved before the PKCS revision is even finished. Thus, we'll be left with two versions of S/MIME (v2 and v3), just like there will be two versions of PGP/MIME (RFC 1991/2015 and OpenPGP). The reasons for having two versions of each protocol are almost identical: earlier use of encumbered algorithms, later use of unencumbered algorithms plus fixes and extensions. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA00657 for ietf-open-pgp-bks; Sat, 8 Nov 1997 10:58:32 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA00652 for ; Sat, 8 Nov 1997 10:58:28 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPRG6EUDF49JE0S5@INNOSOFT.COM> for ietf-open-pgp@imc.org; Sat, 8 Nov 1997 10:57:26 PST Date: Sat, 08 Nov 1997 10:26:02 -0800 (PST) From: Ned Freed Subject: Re: IETF process In-reply-to: "Your message dated Thu, 06 Nov 1997 20:04:36 +0000" <346222D4.7E7CDD5F@systemics.com> To: Ian Grigg Cc: Ned Freed , Rodney Thayer , ietf-open-pgp@imc.org Message-id: <01IPRJDDO78A9JE0S5@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <01IPOR2HIYII9JE0S5@INNOSOFT.COM> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > I now call this the "Munich doctrine". It joins the "Danvers doctrine", which > > was the decision to refuse to cater to export requirements in regards to > > security issues in IETF protocols. Neither of these are written down in an RFC > > as far as I know, but both are very real nevertheless. > OK. A slight point of clarification: encumbered algorithms as a MUST > should not be permitted if there are alternatives, presumably. MAY or > SHOULD is ok? I don't think there's any problem with SHOULD and I cannot see how there would be any problem with MAY. > > The DNSsec people have taken this to heart, that's for sure. They have made > > arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately > > I doubt this is a possibility with RSA.) > Ah. I don't understand your last "possibility with RSA" unless you mean > "possibility with Open PGP." My mistake. I meant to say "Open PGP", just as you interpreted it. > Yes, RSADSI are most unlikely to give this forum that license, given the > opposing standard. I wonder if IETF would take that to heart and insist > that if RSADSI were to give royalty-free license to S/MIME, they should > also give it to competitors? Probably, if the algorithm is to be useful > in an unencumbered way, then this must be the case! Actually what seems to be happening is that S/MIME will be changed to use unemcumbered algorithms and only those algorithms will be MUSTs in the standard. (If I were in RSADSI's shoes I wouldn't do this, but then again your point about there being an issue if they did a special deal for S/MIME and not for PGP is well taken.) This then means that there will be no less than four S/MIMEs: (1) The original RSADSI S/MIME. (2) The one that's coming out as a set of informational RFCs. (3) The one the WG will standardize. (4) The one that will result from the PKCS rewrite that RSADSI is supposedly doing. Wow! That's a lot of S/MIMEs! Mind you, there may be a high degree of compatibility between all of them -- I wouldn't know about that. But let's hope that we don't have quite so many PGPs... > But, yes, I see this as unlikely. Mind you, I'm not especially happy about any of this. I'm describing the situation as I see it, not endorsing it. I understand the reasons the IESG and the IETF have taken this course of action, but I sure wish it could have been handled differently. In case anyone cares, I trace all this back to the last iteration of the POISED process (this is where the IETF develops its procedural and process requirements). The IETF used to have a rule that basically said you had to make a good case for using encumbered technologies, especially if unencumbered alternatives were available. However, this rule caused some trouble in cases where there encumbered technology existed that was believed by some to be clearly superior to unemcumbered alternatives. The long and short of it is that the rule was changed so that use of encumbered technology couldn't be an issue. (I objected at the time but was overruled.) But this, if anything, proved to be a worse situation, and now the pendulum has swung to the opposite extreme. I think it would be better all around to avoid these extremes, even if that meant not reaching closure on some of the things that caused the initial swing, but that's just my personal opinion on the matter. > > I now take it as a given that requiring encumbered technologies when > > alternatives exist is a nonstarter in the IETF. > That leaves me with the sad feeling that the Open PGP standard will > suffer from slow takeup outside the US. I guess that's the lookout that > this forum has accepted from the start. Pretty much. I think the problem exists in part because of the encumbered technology situation and in part because of the export restriction situation, but picking apart the causal relationships doesn't change the situation any. > ( It would appear that the IESG assumes that encumbered within the US is > equivalent to encumbered within the IESG, whereas encumbered within > France is not. I also agree with these Internet politics :-) I think the view is that given that the situation in France (and elsewhere) won't admit any reasonable solution, it might as well be ignored. > On a related issue, that of an unencumbered reference implementation. I > have heard it said that this was required. Is this the case, as it > would seem to be in your careful use of the word "technologies" above? There is no such requirement as far as I know. However, as a practical matter protocols for which unencumbered implementations are available tend to do better in the long run. Back in the days when MIME was developed we took steps to make very sure that two unemcumbered implementations were available almost immediately. I think this helped immensely in winning acceptance for MIME. By contrast, unemcumbered implementations of PEM and MOSS weren't possible, and speaking as someone who would have cheerfully shipped product including such things if they were available (and for that matter would have been willing to accept reasonable licensing terms), I think this contributed significantly to the failure of these protocols. > And if so, was pgp5.0 proposed and accepted as the reference > implementation at the Munich BOF? Not that I'm aware of. In fact I know of no formal process for designating a "reference implementation", other than possibly citing the existance of such a thing in an RFC. Again, on the practical front I'm a strong supporter of unencumbered reference implementations regardless of what the process says (or doesn't say) about them. In fact in the SASL API work that Innosoft is contributing to we've gone so far as to include unencumbered source code for a reference implementation in the specification itself. (Of course this isn't practical for Open PGP given its size and complexity.) Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA02065 for ietf-open-pgp-bks; Sat, 8 Nov 1997 05:11:03 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA02060 for ; Sat, 8 Nov 1997 05:10:59 -0800 (PST) Received: from users.invweb.net (ppp27.dotstar.net [208.143.93.46]) by users.invweb.net (8.8.7/8.8.7) with SMTP id IAA08924; Sat, 8 Nov 1997 08:10:42 -0500 Message-Id: <199711081310.IAA08924@users.invweb.net> From: "William H. Geiger III" Date: Sat, 08 Nov 97 07:08:10 -0600 To: Ben Escoto In-Reply-To: <199711080315.TAA01125@folly.stanford.edu> Cc: ietf-open-pgp@imc.org Subject: Re: base64 signature test X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <199711080315.TAA01125@folly.stanford.edu>, on 11/07/97 at 10:15 PM, Ben Escoto said: > The draft seemed relatively clear, but I thought I would post this >message just to make sure I was implementing things correctly. I would >also like some input from people whose software doesn't support base64 >encoding, so I know how badly messages like these are handled. Thanks. Well my system craped out on it. :( - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCUAwUBNGRkY49Co1n+aLhhAQHpEQP4vQ2c74rwIz4a0F/JX4juhE25hG4XnOWZ WOteSmurAiU9LZg9tI5v6bLu6315e4yA2iYtw69okZOD/KBEuXOIEbBN3MGZ55AD zRv2SrQujh78xKJ1alxnDC3FvkS5AuXchAfNtVCW7BOzr1heWEAuS47V4fMdKB6G 9yiq/Nni1w== =DZHe -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id UAA26286 for ietf-open-pgp-bks; Fri, 7 Nov 1997 20:17:24 -0800 (PST) Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id UAA26282 for ; Fri, 7 Nov 1997 20:17:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mine.aist-nara.ac.jp (8.8.5/8.8.5) with ESMTP id NAA24470; Sat, 8 Nov 1997 13:16:20 +0900 (JST) To: bescoto@stanford.edu Cc: ietf-open-pgp@imc.org Subject: Re: base64 signature test From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: Your message of "Fri, 07 Nov 1997 19:15:36 -0800" <199711080315.TAA01125@folly.stanford.edu> References: <199711080315.TAA01125@folly.stanford.edu> X-Mailer: Mew version 1.93b1 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg="pgp-md5"; boundary="--Security_Multipart(Sat_Nov__8_13:15:59_1997_945)--" Message-Id: <19971108131619B.kazu@Mew.org> Date: Sat, 08 Nov 1997 13:16:19 +0900 X-Dispatcher: imput version 971106 Lines: 37 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk ----Security_Multipart(Sat_Nov__8_13:15:59_1997_945)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Just for your information, From: Ben Escoto Subject: base64 signature test Date: Fri, 07 Nov 1997 19:15:36 -0800 > The draft seemed relatively clear, but I thought I would post > this message just to make sure I was implementing things correctly. I > would also like some input from people whose software doesn't support > base64 encoding, so I know how badly messages like these are handled. > Thanks. Your message was correctly verified by my mail reader, Mew. X-Mew: Good PGP sign "Ben Escoto " COMPLETE --Kazu ----Security_Multipart(Sat_Nov__8_13:15:59_1997_945)-- Content-Type: Application/Pgp-Signature Content-Transfer-Encoding: 7bit -----BEGIN PGP MESSAGE----- Version: 2.6.3i iQCVAwUANGPngw9kihyeT3RNAQHJ6QP/WG++FpOSxr2kCWYWptdFQZwY5RvPyVIX RVWhsCW6E3kccoTVnU2zIpDUtmsDn6JI8g0Zb7iQJ75SQcXUOY4+QXLGA1stazbb Fw24nqp1aIGdRU8VM2c2vI++yNBccBN3N68t0bVvMMl/ZUMimpl/sGUsky2bMMbV lloURiXN6kA= =EV/f -----END PGP MESSAGE----- ----Security_Multipart(Sat_Nov__8_13:15:59_1997_945)---- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA25817 for ietf-open-pgp-bks; Fri, 7 Nov 1997 19:15:20 -0800 (PST) Received: from folly.stanford.edu (folly.Stanford.EDU [171.64.206.21]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA25813 for ; Fri, 7 Nov 1997 19:15:16 -0800 (PST) Received: from folly.stanford.edu (loopback [127.0.0.1]) by folly.stanford.edu (8.7.5/8.6.12) with ESMTP id TAA01125; Fri, 7 Nov 1997 19:15:36 -0800 Message-Id: <199711080315.TAA01125@folly.stanford.edu> X-Url: http://www-leland.stanford.edu/~bescoto/ X-Files: The Truth Is Out There X-Mailer: exmh version 2.0g with XEmacs 19.14 From: Ben Escoto To: ietf-open-pgp@imc.org Subject: base64 signature test Content-Type: multipart/signed; boundary="=_Mapil-0.2a_848824537"; micalg="pgp-sha1"; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Date: Fri, 07 Nov 1997 19:15:36 -0800 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk --=_Mapil-0.2a_848824537 The draft seemed relatively clear, but I thought I would post this message just to make sure I was implementing things correctly. I would also like some input from people whose software doesn't support base64 encoding, so I know how badly messages like these are handled. Thanks. -- Ben Escoto PGP/MIME mail welcome - finger bescoto@leland.stanford.edu for key --=_Mapil-0.2a_848824537 Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 iQCVAwUBNGPZR1PyP+bsWtNdAQGsdQP/QLxwCZkI3IX+js8llrrzZSST65b+9ATtUxkP5QI2Bjw+ mntLxrOBL3qoAhFPnRWNVqTRVfeqmiJeWliMzpRiXb5BSMO3pe+QdjHPxL7VdjTAE+Xho3nzN7uD 41o1C7TO67XZtRYtPyyC+woMuxA2sj1rEvhyhwCcadIVxEUFgbg= --=_Mapil-0.2a_848824537-- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA21278 for ietf-open-pgp-bks; Fri, 7 Nov 1997 11:26:54 -0800 (PST) Received: from sspe.mcit.com (pgpkeys2.mcit.com [166.35.157.154]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA21272 for ; Fri, 7 Nov 1997 11:26:50 -0800 (PST) Received: from pop4200.switcheng.mci.com by sspe.mcit.com with smtp (Smail3.1.29.1 #1) id m0xTtzU-0008tKC; Fri, 7 Nov 97 13:22 CST Message-Id: <3.0.2.32.19971107125208.006b5420@postoffice.switcheng.mci.com> X-Sender: dhayes@postoffice.switcheng.mci.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Fri, 07 Nov 1997 12:52:08 -0600 To: Jon Callas , "darrylr@iglou.com" , "ietf-open-pgp@imc.org" From: David Hayes Subject: Re: Management by Committee ... In-Reply-To: <3.0.3.32.19971105184011.009fd240@mail.pgp.com> References: <01BCE9CF.8FC53760.darrylr@iglou.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Thank you for your effort, and the generous gift that PGP is to the world. I know you get lots of heat here on this list, with some of it from me. :-) We disagree over the issue of defining CMR in the standard. We'll probably continue to disagree. But I don't want to let that get it the way of expressing my gratitude for the large body of work you have contributed. So, a time-out from the CMR debate, while I just say "thank you." -- David Hayes David.Hayes@MCI.Com Switch Systems Engineering voice: 972-918-7236 MCI Communications, Inc. VNET: 777-7236 --If these thoughts were MCI's official opinions, the line above would --read "MCI - Law & Public Policy Department". Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA15633 for ietf-open-pgp-bks; Fri, 7 Nov 1997 05:53:40 -0800 (PST) Received: from enterprise.powerup.com.au (enterprise.powerup.com.au [203.32.8.37]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA15629 for ; Fri, 7 Nov 1997 05:53:30 -0800 (PST) Message-Id: <199711071353.FAA15629@mail.proper.com> Received: (qmail 23254 invoked from network); 7 Nov 1997 13:53:29 -0000 Received: from unknown (HELO lindsay) (unknown) by unknown with SMTP; 7 Nov 1997 13:53:29 -0000 Date: 7 Nov 1997 13:45:15 GMT From: Lindsay Mathieson Subject: Re: patent freedom & compatibility To: Paul Hoffman / IMC , IETF OpenPGP X-Mailer: Black Paw Communications's MailCat for Win32 Beta Vs 2.6.1.2 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Just replying to the subject, rather than the specific message. With regards to pgp 2.6 compatibility, I believe that only a MAY reference in the spec (with appendices/references for formats), is required for it to be widely implemented, user demand and market pressure will take care of that. If there are really 4 million pgp 2.6 users out there, then most email developers will be eager to service that market niche. If we leave it a MAY then issues of copyright & patents are upto the implementors in their various countries, as it should be. And that would leave us free to *quickly* draft a unencumbered clearly documented spec with ONE MUST and ONE SHOULD. As a developer I dream of that, at the moment implementing email security is a nightmare. Too much time is being wasted on political issues & debates, for what I thought was meant to be a purely technical spec. -- Lindsay Mathieson Black Paw Communications Using MailCat for Win32 Beta Vs 2.6.1.2, on November 7, 1997, in Win95 4.0 http://www.blackpaw.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA02588 for ietf-open-pgp-bks; Thu, 6 Nov 1997 14:33:31 -0800 (PST) Received: from lancelot.st.nepean.uws.edu.au (lancelot.st.nepean.uws.edu.au [137.154.148.30]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA02583 for ; Thu, 6 Nov 1997 14:33:24 -0800 (PST) Received: from oberon.st.nepean.uws.edu.au (oberon [137.154.148.13]) by lancelot.st.nepean.uws.edu.au (8.8.5/8.8.5) with ESMTP id JAA01062 for ; Fri, 7 Nov 1997 09:32:08 +1100 Received: from shirley (dformosa@dialin-32 [137.154.130.32]) by oberon.st.nepean.uws.edu.au (8.8.5/8.8.5) with SMTP id JAA23064 for ; Fri, 7 Nov 1997 09:32:06 +1100 (EST) Date: Fri, 7 Nov 1997 08:19:54 +1100 (EST) From: ? the Platypus {aka David Formosa} X-Sender: dformosa@shirley Reply-To: platypus@acmeonline.net To: ietf-open-pgp@imc.org Subject: Re: IETF process In-Reply-To: <3.0.5.32.19971106122037.00f73220@mail.imc.org> Message-ID: x-url: http://www.st.nepean.uws.edu.au/~dformosa/Spelling.html MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- On Thu, 6 Nov 1997, Paul Hoffman / IMC wrote: > Last we heard, MAY and SHOULD is OK. (I'm still lobbying against "MAY" > because that implies that everything not listed is "MAY NOT", and I think > that's a bad protocol.) I would suggest that wonderful phrase "including but not limmited to". We are going to need a MAY list if just for the cypher identerfires. - -- Please excuse my spelling as I suffer from agraphia see the url in my header. Never trust a country with more peaple then sheep. ex-net.scum and proud You Say To People "Throw Off Your Chains" And They Make New Chains For Themselves? --Terry Pratchett -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBNGI0g6QK0ynCmdStAQF3WAP/c1HnGNxWoCivQF7iCHDXpVK2REZDUGp2 WvReJJvNXYjsmKpKm2FQTUDDwrjbeFcuMix8W2gFCJE9DPKoPtA7RzIXzJugvjb4 jIOBpBw5gJhKhANSposoL9pkaRSnxQiaBT0f/Cu+6Wkzc2dM6FmiRe9gzWFSEFgO 1C1Xo+SM4Jg= =FOEQ -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA01582 for ietf-open-pgp-bks; Thu, 6 Nov 1997 13:29:34 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA01571; Thu, 6 Nov 1997 13:29:29 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id AAA05102; Fri, 7 Nov 1997 00:04:07 +0100 (MET) Message-ID: <34623708.3D6D0E98@systemics.com> Date: Thu, 06 Nov 1997 21:30:48 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: phoffman@imc.org, jis@mit.edu CC: ietf-open-pgp@imc.org Subject: Re: patent freedom & compatibility References: <3.0.3.32.19971106074236.0396e080@pop.pn.com> <3.0.3.32.19971106111827.0390aa6c@pop.pn.com> <3.0.5.32.19971106120524.00849ad0@mail.imc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jeff and Paul, Paul Hoffman / IMC wrote: > The announcement of the new thinking was made at the plenary session at the > last IETF meeting (the one in Munich). Many people on this mailing list > were there. Some even cheered when the announcement was made. :-) ( To be honest, I probably would have cheered and voted such too. Only on reflection of the market (which tends to ignore programmers views) did I question this. ) > > It > >would raise many questions, and given the circumstances of the > >competition for mail standards, these are questions that we'd rather the > >other standards proponents could not raise. > > I'm not sure what you mean here. To clarify, I suspect that RSADSI are not above challenging the results of this forum in court if they thought they could show it was non-rigourous. > >( I think I know what the answer to this might be: there is no > >supporting material and it should be taken up with the Area Director. > >OK, I'll start drafting a note. Not knowing the guy and how familiar he > >is with the situation, this'll keep me quite for a few days. :-) > > He's quite familiar with the situation, and he's also on this mailing list. OK, I'll ask directly, and we'll put this to bed. Jeff, do you accept Ned Freed's post of today to Open PGP under "Re: IETF process" as accurately describing the "Munich doctrine" and its effect on this WG? -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA00666 for ietf-open-pgp-bks; Thu, 6 Nov 1997 12:20:41 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA00660 for ; Thu, 6 Nov 1997 12:20:36 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id MAA05369 for ; Thu, 6 Nov 1997 12:18:14 -0800 (PST) Message-Id: <3.0.5.32.19971106122037.00f73220@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Nov 1997 12:20:37 -0800 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: IETF process In-Reply-To: <346222D4.7E7CDD5F@systemics.com> References: <01IPOR2HIYII9JE0S5@INNOSOFT.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:04 PM 11/6/97 +0000, Ian Grigg wrote: >OK. A slight point of clarification: encumbered algorithms as a MUST >should not be permitted if there are alternatives, presumably. MAY or >SHOULD is ok? Last we heard, MAY and SHOULD is OK. (I'm still lobbying against "MAY" because that implies that everything not listed is "MAY NOT", and I think that's a bad protocol.) >I wonder if IETF would take that to heart and insist >that if RSADSI were to give royalty-free license to S/MIME, they should >also give it to competitors? Just to be very clear here, in my extensive dealings with RSA over S/MIME, they have never suggested that they wanted to give a royalty-free license to S/MIME developers. The might in the future, of course, but that' not come up yet with me in private, and never in public. >On a related issue, that of an unencumbered reference implementation. I >have heard it said that this was required. Not at all. To move from Proposed to Draft standard, we must prove that there are two independent interoperable implementations of each required feature. A "reference implementation" has never been required and is certainly not available for most of the popular IETF protocols. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA00404 for ietf-open-pgp-bks; Thu, 6 Nov 1997 12:08:52 -0800 (PST) Received: from rigel.cyberpass.net (root@rigel.infonex.com [206.170.114.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA00399 for ; Thu, 6 Nov 1997 12:08:46 -0800 (PST) Received: from [206.170.114.18] (coyote.infonex.com [206.170.114.18]) by rigel.cyberpass.net (8.8.8/8.7.3) with ESMTP id MAA25288 for ; Thu, 6 Nov 1997 12:04:54 -0800 (PST) X-Sender: loki@sirius.infonex.com Message-Id: In-Reply-To: <01BCEA3D.822070C0.darrylr@iglou.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 6 Nov 1997 12:04:46 -0800 To: From: Lance Cottrell Subject: Re: Bravo! Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >Instead, let's leave message recovery up to the implementors of individual >applications, as an added feature not part of the official open-pgp >standard. Those who sell into markets where such features are desired can >add them. The rest of the world will not have to be forced to go along. * Uncloak * While imperfect, this seems like the only solution likely to result in consensus. A government willing to require a GMR key would not hesitate to outlaw PGP completely. Like the range of criminals smart enough to use crypto but dumb enough to use GAK, the range of government anti-crypto hostility which would require GMR but would stop short of outlawing non-GMR PGP is very narrow. * Cloak * -Lance ---------------------------------------------------------- Lance Cottrell loki@infonex.com PGP 2.6 key available by finger or server. http://www.infonex.com/~loki/ "Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come." --Nietzsche ---------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA00343 for ietf-open-pgp-bks; Thu, 6 Nov 1997 12:05:40 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA00338 for ; Thu, 6 Nov 1997 12:05:34 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id MAA05310 for ; Thu, 6 Nov 1997 12:03:11 -0800 (PST) Message-Id: <3.0.5.32.19971106120524.00849ad0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Nov 1997 12:05:24 -0800 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: patent freedom & compatibility In-Reply-To: <346214F2.13880403@systemics.com> References: <3.0.3.32.19971106074236.0396e080@pop.pn.com> <3.0.3.32.19971106111827.0390aa6c@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 07:05 PM 11/6/97 +0000, Ian Grigg wrote: >Is there any reference material of a non-formal nature that would >support the notion that this WG should use unencumbered crypto for its >MUST algorithms? The announcement of the new thinking was made at the plenary session at the last IETF meeting (the one in Munich). Many people on this mailing list were there. Some even cheered when the announcement was made. :-) >If there is no supporting material at all, and the policy is based on >verbal or emailed conversations, then I would be most uncomfortable. You are not alone in this! > It >would raise many questions, and given the circumstances of the >competition for mail standards, these are questions that we'd rather the >other standards proponents could not raise. I'm not sure what you mean here. The rules for OpenPGP are certainly the same rules as must be followed for all security protocols. This is one of the motivating factors for the S/MIME v3 work: to be able to produce something that can get on standards track, which S/MIME v2 probably could not (because it requires RSA signatures, like PGP 2.6 does). >( I think I know what the answer to this might be: there is no >supporting material and it should be taken up with the Area Director. >OK, I'll start drafting a note. Not knowing the guy and how familiar he >is with the situation, this'll keep me quite for a few days. :-) He's quite familiar with the situation, and he's also on this mailing list. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA00300 for ietf-open-pgp-bks; Thu, 6 Nov 1997 12:03:28 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA00296 for ; Thu, 6 Nov 1997 12:03:24 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id WAA04880; Thu, 6 Nov 1997 22:37:54 +0100 (MET) Message-ID: <346222D4.7E7CDD5F@systemics.com> Date: Thu, 06 Nov 1997 20:04:36 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Ned Freed CC: Rodney Thayer , ietf-open-pgp@imc.org Subject: Re: IETF process References: <01IPOR2HIYII9JE0S5@INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ned, this is quality information, Thanks. Ned Freed wrote: > The problem with TLS was that it didn't specify a mandatory-to-implement > ciphersuite. Without one it is impossible to meet IETF interoperability > requirements. This caused it to be bounced back to the WG for further work. In > other words, it wasn't the choice of a mandatory ciphersuite that mattered, it > was the lack of one. (I thought I'd mention this in case someone advocates > not having any mandatory-to-implement algorithms in OpenPGP.) ( Indeed, I have advocated that as a potential solution. ) > Having said that, the WG was also clearly unable to go with RC4, since RC4 is > considered to be a trade secret and IETF rules absolutely forbid standardizing > on material with confidentiality constraints. ( OK, interesting point. Not immediately applicable as RC4 does not enter into the Open PGP debate. ) > And given that backwards > compatibility was a nonstarter, the WG elected to go with the least encumbered > alternatives it could find. ( OK, so on the basis that RC4 was out *becuase* it was a trade secret, backwards compatibility was dropped. That however does not apply here. ) Here's the good bits: > However, regardless of what happened to TLS, the fact of the matter is that the > rules are now in a state of flux. We all know what RFC 2026 says. But things > have changed since it was written. > > For one thing, the IESG in general and the security AD in particular clearly > feel in light of past bad experiences with encumbered technologies that > embracing standards that require them is not a good idea. This is especially > true when perfectly viable alternatives are available. > > For another, there's the matter of the plenary session in Munich. A straw poll > was taken there and a clear consensus emerged that use of encumbered > technologies should not be allowed when alternatives are available. > > Far more than anything else, the IETF is ruled by rough consensus. So a straw > poll taken under such circumstances carries real weight, especially when it > tightens the rules rather than loosening them. > > I now call this the "Munich doctrine". It joins the "Danvers doctrine", which > was the decision to refuse to cater to export requirements in regards to > security issues in IETF protocols. Neither of these are written down in an RFC > as far as I know, but both are very real nevertheless. OK. A slight point of clarification: encumbered algorithms as a MUST should not be permitted if there are alternatives, presumably. MAY or SHOULD is ok? > Remember that all it takes is two IESG members voting "NO" and the document > goes back to the WG. (The IESG, BTW, is the one place where voting is > sanctioned in the IETF.) My read of the situation is that there are at least > three and probably more IESG members who will vote against any specification > that requires use of encumbered technology where alternatives are available. > > The DNSsec people have taken this to heart, that's for sure. They have made > arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately > I doubt this is a possibility with RSA.) Ah. I don't understand your last "possibility with RSA" unless you mean "possibility with Open PGP." Yes, RSADSI are most unlikely to give this forum that license, given the opposing standard. I wonder if IETF would take that to heart and insist that if RSADSI were to give royalty-free license to S/MIME, they should also give it to competitors? Probably, if the algorithm is to be useful in an unencumbered way, then this must be the case! But, yes, I see this as unlikely. > I now take it as a given that requiring encumbered technologies when > alternatives exist is a nonstarter in the IETF. OK, I concur. Your explanation has convinced me of that: IETF will not permit Open PGP to use unencumbered technologies because alternatives are around. That leaves me with the sad feeling that the Open PGP standard will suffer from slow takeup outside the US. I guess that's the lookout that this forum has accepted from the start. ( It would appear that the IESG assumes that encumbered within the US is equivalent to encumbered within the IESG, whereas encumbered within France is not. I also agree with these Internet politics :-) > > Analyzing the document rather than studying the context is not necessarily > > the way to look at things when dealing with the IETF standards process. > > Exactly right. This is a dynamic process. There's always more to it than what > is said on paper. So while I do recommend that people read what's on paper, it > should only be taken as a starting point. Your explanation provides the middle and ending as well. Thanks again. On a related issue, that of an unencumbered reference implementation. I have heard it said that this was required. Is this the case, as it would seem to be in your careful use of the word "technologies" above? And if so, was pgp5.0 proposed and accepted as the reference implementation at the Munich BOF? -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA28792 for ietf-open-pgp-bks; Thu, 6 Nov 1997 11:06:17 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA28785 for ; Thu, 6 Nov 1997 11:06:09 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPOP7D16KG9JE0S5@INNOSOFT.COM> for ietf-open-pgp@imc.org; Thu, 6 Nov 1997 11:05:20 PST Date: Thu, 06 Nov 1997 10:22:05 -0800 (PST) From: Ned Freed Subject: Re: IETF process In-reply-to: "Your message dated Thu, 06 Nov 1997 07:42:36 -0500" <3.0.3.32.19971106074236.0396e080@pop.pn.com> To: Rodney Thayer Cc: iang@systemics.com, ietf-open-pgp@imc.org Message-id: <01IPOR2HIYII9JE0S5@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > If you look at what has been happening in the IETF lately you'd see that > TLS, IPSec, and PKIX have all run into this issue. I'm not sure about the examples, but I think the basic idea here is pretty close to the mark. The problem with TLS was that it didn't specify a mandatory-to-implement ciphersuite. Without one it is impossible to meet IETF interoperability requirements. This caused it to be bounced back to the WG for further work. In other words, it wasn't the choice of a mandatory ciphersuite that mattered, it was the lack of one. (I thought I'd mention this in case someone advocates not having any mandatory-to-implement algorithms in OpenPGP.) Having said that, the WG was also clearly unable to go with RC4, since RC4 is considered to be a trade secret and IETF rules absolutely forbid standardizing on material with confidentiality constraints. And given that backwards compatibility was a nonstarter, the WG elected to go with the least encumbered alternatives it could find. I'm not familiar with the IPSec or PKIX situation so I cannot comment on them. However, regardless of what happened to TLS, the fact of the matter is that the rules are now in a state of flux. We all know what RFC 2026 says. But things have changed since it was written. For one thing, the IESG in general and the security AD in particular clearly feel in light of past bad experiences with encumbered technologies that embracing standards that require them is not a good idea. This is especially true when perfectly viable alternatives are available. For another, there's the matter of the plenary session in Munich. A straw poll was taken there and a clear consensus emerged that use of encumbered technologies should not be allowed when alternatives are available. Far more than anything else, the IETF is ruled by rough consensus. So a straw poll taken under such circumstances carries real weight, especially when it tightens the rules rather than loosening them. I now call this the "Munich doctrine". It joins the "Danvers doctrine", which was the decision to refuse to cater to export requirements in regards to security issues in IETF protocols. Neither of these are written down in an RFC as far as I know, but both are very real nevertheless. Remember that all it takes is two IESG members voting "NO" and the document goes back to the WG. (The IESG, BTW, is the one place where voting is sanctioned in the IETF.) My read of the situation is that there are at least three and probably more IESG members who will vote against any specification that requires use of encumbered technology where alternatives are available. The DNSsec people have taken this to heart, that's for sure. They have made arrangements with RSADSI for royalty free use of RSA in the DNS. (Unfortunately I doubt this is a possibility with RSA.) I now take it as a given that requiring encumbered technologies when alternatives exist is a nonstarter in the IETF. > Analyzing the document rather than studying the context is not necessarily > the way to look at things when dealing with the IETF standards process. Exactly right. This is a dynamic process. There's always more to it than what is said on paper. So while I do recommend that people read what's on paper, it should only be taken as a starting point. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA28713 for ietf-open-pgp-bks; Thu, 6 Nov 1997 11:04:15 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA28707 for ; Thu, 6 Nov 1997 11:04:10 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id VAA04716; Thu, 6 Nov 1997 21:38:40 +0100 (MET) Message-ID: <346214F2.13880403@systemics.com> Date: Thu, 06 Nov 1997 19:05:22 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Rodney Thayer CC: Adam Back , ietf-open-pgp@imc.org Subject: Re: patent freedom & compatibility References: <3.0.3.32.19971106074236.0396e080@pop.pn.com> <3.0.3.32.19971106111827.0390aa6c@pop.pn.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Rodney Thayer wrote: > > My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and > RC4 as the MUST. "ordered" is an interesting word. > Analyzing 2026 to death rather than finding out what the IETF really does > is why I started this comment. OK, I admit to a flaw in my research. I was assuming that the IETF documented its processes and decisions, and that such process and decision-making was robust enough to be analysed or even audited at some future time. I think the term for this might be transparency or accountability. You are suggesting, and suggesting strongly even, that this is not the case. OK, I completely accept that, as I am new to the process, and there is no reason to believe that the IETF would have adopted these viewpoints. Is there any reference material of a non-formal nature that would support the notion that this WG should use unencumbered crypto for its MUST algorithms? If there is no supporting material at all, and the policy is based on verbal or emailed conversations, then I would be most uncomfortable. It would raise many questions, and given the circumstances of the competition for mail standards, these are questions that we'd rather the other standards proponents could not raise. ( I think I know what the answer to this might be: there is no supporting material and it should be taken up with the Area Director. OK, I'll start drafting a note. Not knowing the guy and how familiar he is with the situation, this'll keep me quite for a few days. :-) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA27670 for ietf-open-pgp-bks; Thu, 6 Nov 1997 10:43:40 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA27663 for ; Thu, 6 Nov 1997 10:43:35 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id KAA05145; Thu, 6 Nov 1997 10:41:00 -0800 (PST) Message-Id: <3.0.5.32.19971106104323.009083b0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 Nov 1997 10:43:23 -0800 To: Rodney Thayer , Adam Back From: Paul Hoffman / IMC Subject: Re: patent freedom & compatibility Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971106111827.0390aa6c@pop.pn.com> References: <199711061520.PAA02452@server.test.net> <3.0.3.32.19971106074236.0396e080@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:18 AM 11/6/97 -0500, Rodney Thayer wrote: >My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and >RC4 as the MUST. Quite true. The latest (and hopefully final) version of TLS has DSS/DH a MUST and 3DES a MUST. Because there is no direct interoperability with earlier versions of SSL, there are no SHOULDs, but there is a long list of IDs so people will know the algorithm identifiers for other commonly used algorithms like RSA. >Using encumbered algorithms as non-MUST algorithms is fine. This is my understanding of the IESG's current thinking as well. >Analyzing 2026 to death rather than finding out what the IETF really does >is why I started this comment. And it's quite right. The IESG has offered verbal guidance about how they currently interpret RFC 2026, and that guidance boils down to (I think) "if there is an unencumbered alternative, you may not require an encumbered algorithm, but you may list it as a suggested one, particularly for compatibilty with earlier work." --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA24679 for ietf-open-pgp-bks; Thu, 6 Nov 1997 08:40:12 -0800 (PST) Received: from dg-webo.webo.dg.com (dg-webo.us.dg.com [128.221.131.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA24675 for ; Thu, 6 Nov 1997 08:40:04 -0800 (PST) Received: from wellspring by dg-webo.webo.dg.com (5.4R3.10/dg-webo-v1) id AA15704; Thu, 6 Nov 1997 11:39:14 -0500 Received: from barge by wellspring.us.dg.com (5.4R3.10/dg-gens08) id AA05366; Thu, 6 Nov 1997 11:39:12 -0500 Message-Id: <3.0.3.32.19971106111827.0390aa6c@pop.pn.com> X-Pgp-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 06 Nov 1997 11:18:27 -0500 To: Adam Back From: Rodney Thayer Subject: Re: patent freedom & compatibility Cc: ietf-open-pgp@imc.org In-Reply-To: <199711061520.PAA02452@server.test.net> References: <3.0.3.32.19971106074236.0396e080@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk My point is that TLS was ordered to use DSS/DH and 3DES rather than RSA and RC4 as the MUST. Using encumbered algorithms as non-MUST algorithms is fine. Analyzing 2026 to death rather than finding out what the IETF really does is why I started this comment. At 03:20 PM 11/6/97 GMT, you wrote: > >Rodney Thayer writes: >> If you look at what has been happening in the IETF lately you'd see that >> TLS, IPSec, and PKIX have all run into this issue. > >Here's SSL3.02 draft (TLS) comments on this: > >G. Patent Statement > > This version of the SSL protocol relies on the use of patented > public key encryption technology for authentication and encryption. > The Internet Standards Process as defined in RFC 1310 requires a > written statement from the Patent holder that a license will be > made available to applicants under reasonable terms and conditions > prior to approving a specification as a Proposed, Draft or Internet > Standard. The Massachusetts Institute of Technology has granted > RSA Data Security, Inc., exclusive sub-licensing rights to the > following patent issued in the United States: > > Cryptographic Communications System and Method ("RSA"), > No. 4,405,829 > > The Board of Trustees of the Leland Stanford Junior University have > granted Caro-Kann Corporation, a wholly owned subsidiary > corporation, exclusive sub-licensing rights to the following > patents issued in the United States, and all of their corresponding > foreign patents: > > Cryptographic Apparatus and Method ("Diffie-Hellman"), > No. 4,200,770 > > Public Key Cryptographic Apparatus and Method ("Hellman- > Merkle"), No. 4,218,582 > > The Internet Society, Internet Architecture Board, Internet > Engineering Steering Group and the Corporation for National > Research Initiatives take no position on the validity or scope of > the patents and patent applications, nor on the appropriateness of > the terms of the assurance. The Internet Society and other groups > mentioned above have not made any determination as to any other > intellectual property rights which may apply to the practice of > this standard. Any further consideration of these matters is the > user's own responsibility. > >> Analyzing the document rather than studying the context is not >> necessarily the way to look at things when dealing with the IETF >> standards process. > >Could you clarify that comment? > >Personally I think a patent free MUST cipher set is great, and very >desirable. > >However I can also see that it would be nice to have backwards >compatibility, and to provide a way for automatic backwards >compatibility to be implemented within the documentation. > >An analogy for what Ian is arguing for might be perhaps SSL2.0 >fallback mode for SSL3.0 to retain backwards compatibility. > >Could we not do this at the same time as having patented algorithms as >SHOULDs or even MAYs. People don't have to implement SHOULD/MAY, but >they can if they want, and presumably some vendors would to please >users. > >Having more seamless backwards compatibility than pgp5.0 currently has >might paradoxically speed the move to pgp5.x / OpenPGP algorithms and >security improvements -- people may be holding back for various >perceived compatibility reasons. (Personally my only hold up is MUA >software (unix person), I'm quite happy with being able to cope with >two key pairs and using appropriately.) > >Note that I am not saying you can't be interoperable with pgp5.0, >clearly you can, as you can add both your old RSA keys if you have >some, or generate both RSA and DSA/EG keys and manually select key >types to use. I understand pgp5.0 windows client will warn you if you >try to do things like sign with DSA key a document headed for someone >with an RSA key. This kind of thing could be made seamless, so the >user wouldn't even notice. So what is being suggested here is that >there is some value to working through the process when the draft >comes out to ensure that it would be possible to build such a system >with the message and key formats allowing software to auto-detect what >is the right thing to do. > >One trick SSL3.0 does is to diddle with some random value/value which >is ignored which would not be noticeable to a 2.0 client, but which >could be used by a 3.0 client to detect that it was talking to a 3.0 >capable client. Building in more formalised upgrade paths in OpenPGP >1.0 version such as this, will ease the way for less hassles later. >It is probably possible to do things like this with 2.x, but I'm not >sure how pretty the result would be :-( (Hide EG/DSA key in pgp2.x >comment field, or other place? Ugh. Yuck.) > >Adam >-- >Now officially an EAR violation... >Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ > >print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> >)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 > Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA23567 for ietf-open-pgp-bks; Thu, 6 Nov 1997 07:29:12 -0800 (PST) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA23532 for ; Thu, 6 Nov 1997 07:28:32 -0800 (PST) Received: from aba@p13-crane-gui.tch.virgin.net [194.168.59.73] by exub via ESMTP (PAA22932); Thu, 6 Nov 1997 15:27:52 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id PAA02452; Thu, 6 Nov 1997 15:20:03 GMT Date: Thu, 6 Nov 1997 15:20:03 GMT Message-Id: <199711061520.PAA02452@server.test.net> From: Adam Back To: rodney@sabletech.com CC: iang@systemics.com, ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971106074236.0396e080@pop.pn.com> (message from Rodney Thayer on Thu, 06 Nov 1997 07:42:36 -0500) Subject: patent freedom & compatibility Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Rodney Thayer writes: > If you look at what has been happening in the IETF lately you'd see that > TLS, IPSec, and PKIX have all run into this issue. Here's SSL3.02 draft (TLS) comments on this: G. Patent Statement This version of the SSL protocol relies on the use of patented public key encryption technology for authentication and encryption. The Internet Standards Process as defined in RFC 1310 requires a written statement from the Patent holder that a license will be made available to applicants under reasonable terms and conditions prior to approving a specification as a Proposed, Draft or Internet Standard. The Massachusetts Institute of Technology has granted RSA Data Security, Inc., exclusive sub-licensing rights to the following patent issued in the United States: Cryptographic Communications System and Method ("RSA"), No. 4,405,829 The Board of Trustees of the Leland Stanford Junior University have granted Caro-Kann Corporation, a wholly owned subsidiary corporation, exclusive sub-licensing rights to the following patents issued in the United States, and all of their corresponding foreign patents: Cryptographic Apparatus and Method ("Diffie-Hellman"), No. 4,200,770 Public Key Cryptographic Apparatus and Method ("Hellman- Merkle"), No. 4,218,582 The Internet Society, Internet Architecture Board, Internet Engineering Steering Group and the Corporation for National Research Initiatives take no position on the validity or scope of the patents and patent applications, nor on the appropriateness of the terms of the assurance. The Internet Society and other groups mentioned above have not made any determination as to any other intellectual property rights which may apply to the practice of this standard. Any further consideration of these matters is the user's own responsibility. > Analyzing the document rather than studying the context is not > necessarily the way to look at things when dealing with the IETF > standards process. Could you clarify that comment? Personally I think a patent free MUST cipher set is great, and very desirable. However I can also see that it would be nice to have backwards compatibility, and to provide a way for automatic backwards compatibility to be implemented within the documentation. An analogy for what Ian is arguing for might be perhaps SSL2.0 fallback mode for SSL3.0 to retain backwards compatibility. Could we not do this at the same time as having patented algorithms as SHOULDs or even MAYs. People don't have to implement SHOULD/MAY, but they can if they want, and presumably some vendors would to please users. Having more seamless backwards compatibility than pgp5.0 currently has might paradoxically speed the move to pgp5.x / OpenPGP algorithms and security improvements -- people may be holding back for various perceived compatibility reasons. (Personally my only hold up is MUA software (unix person), I'm quite happy with being able to cope with two key pairs and using appropriately.) Note that I am not saying you can't be interoperable with pgp5.0, clearly you can, as you can add both your old RSA keys if you have some, or generate both RSA and DSA/EG keys and manually select key types to use. I understand pgp5.0 windows client will warn you if you try to do things like sign with DSA key a document headed for someone with an RSA key. This kind of thing could be made seamless, so the user wouldn't even notice. So what is being suggested here is that there is some value to working through the process when the draft comes out to ensure that it would be possible to build such a system with the message and key formats allowing software to auto-detect what is the right thing to do. One trick SSL3.0 does is to diddle with some random value/value which is ignored which would not be noticeable to a 2.0 client, but which could be used by a 3.0 client to detect that it was talking to a 3.0 capable client. Building in more formalised upgrade paths in OpenPGP 1.0 version such as this, will ease the way for less hassles later. It is probably possible to do things like this with 2.x, but I'm not sure how pretty the result would be :-( (Hide EG/DSA key in pgp2.x comment field, or other place? Ugh. Yuck.) Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Thu, 6 Nov 1997 04:49:09 -0800 (PST) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 6 Nov 1997 12:49:10 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.8.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id HAA18518; Thu, 6 Nov 1997 07:51:20 -0500 (EST) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 6 Nov 1997 12:49:01 UT Received: from ferguson.newton.sabletech.com ([199.249.254.9]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id HAA09672; Thu, 6 Nov 1997 07:48:54 -0500 (EST) Message-Id: <3.0.3.32.19971106074236.0396e080@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 06 Nov 1997 07:42:36 -0500 To: iang@systemics.com From: Rodney Thayer Subject: Re: IETF process Cc: ietf-open-pgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk If you look at what has been happening in the IETF lately you'd see that TLS, IPSec, and PKIX have all run into this issue. Analyzing the document rather than studying the context is not necessarily the way to look at things when dealing with the IETF standards process. >Date: Wed, 05 Nov 1997 23:58:12 +0000 >From: Ian Grigg >Organization: Systemics >X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) >To: Raph Levien >CC: ietf-open-pgp@imc.org, Gene Hoffman >Subject: Re: IETF process (was How many 2.6 users?) >Sender: owner-ietf-open-pgp@imc.org > >Raph Levien wrote: >> I believe that the most relevant document explaining IETF process is RFC >> 2026. Quoting section 10.3.2(c), which is relevant for standards track >> documents: >> >> (C) Where the IESG knows of rights, or claimed rights under (A), the >> IETF Executive Director shall attempt to obtain from the claimant >> of such rights, a written assurance that upon approval by the IESG >> of the relevant Internet standards track specification(s), any >> party will be able to obtain the right to implement, use and >> distribute the technology or works when implementing, using or >> distributing technology based upon the specific specification(s) >> under openly specified, reasonable, non-discriminatory terms. >> The Working Group proposing the use of the technology with respect >> to which the proprietary rights are claimed may assist the IETF >> Executive Director in this effort. The results of this procedure >> shall not affect advancement of a specification along the >> standards track, except that the IESG may defer approval where a >> delay may facilitate the obtaining of such assurances. The >> results will, however, be recorded by the IETF Executive Director, >> and made available. The IESG may also direct that a summary of >> the results be included in any RFC published containing the >> specification. >> >> So the existence of patented technology (such as RSA or IDEA) would >> seem to be not necessarily a problem, as long as the patent is licensed >> under appropriately "open" terms. > >Wow. Let's look at this. IDEA first. > >IDEA is licensed by Ascom and their licensing page is at [1]. Their >schedule is at [2] and includes more prices than you can poke a stick >at. What is more interesting is that you can purchase the license over >the Internet at [3] (although you are forced to read the license to get >there). It's especially open in the hackers sense that you do not have >to use their source. > >I would therefore conclude that IDEA is: available to any party, >distributable, purchasable under open, "reasonable" and >non-discriminatory terms. Reasonable is of course a value judgement. > >As an administrative burden, the IETF ExecDirector should get a letter >that confirms this. My reading of the site and Ascom's reputation do >not indicate an issue here. > >> Whether RSA meets this standard is open >> to question - certainly they have been accused by their detractors of >> non-openness in their licensing process. > >OK, now RSA. > >I agree that RSADSI have a bad reputation on this issue. I had a look >at their web site and it is appallingly closed. Note however that the >above comment does not say that an assurance of openness is necessary: > > "The results of this procedure > shall not affect advancement of a specification along the > standards track, except that the IESG may defer approval where a > delay may facilitate the obtaining of such assurances. The > results will, however, be recorded by the IETF Executive Director, > and made available. The IESG may also direct that a summary of > the results be included in any RFC published containing the > specification." > >"shall not affect advancement" is quite specific, which leaves open the >question as to why the IESG supposedly rejected the S/MIME and SSL V3 >standards. Perhaps they were simply deferred instead, as this deferral >might be a bargaining chip in the hands of IETF. > >Can you comment in the S/MIME case as to why the above was considered to >be a rejection? > >I would think that having the RSA algorithm listed in the standard, >along with an IESG comment that said that this algorithm may not be >available under open, non-discriminatory and reasonable guidelines to >all parties would be quite a useful bargaining point. > >We could go even further. You could say that the RSA algorithm is to be >used, except where algorithm is not available under open, >non-discriminatory and reasonable guidelines. If we need a definition >of this, I would suggest > > * prices not in excess of other comparables (is ElGamal comparable? >:-), > * purchasable over the web with no possibility of a human > being interposing some "conditions." > * no restrictions on code use (i.e., roll-your-own is ok, as is use > somebody else's) > >All of which seems obvious of course, based on the snippet above. Are >there any counter-views? > > > >> Hope this helps. > >It's excellent, thanks. Clears the FUD right out. > > > >[1] http://www.ascom.ch/Web/systec/policy/main.html >[2] http://www.ascom.ch/Web/systec/policy/normal/exhibit3.html >[3] http://www.ascom.ch/Web/systec/policy/normal/orderform.html > >-- >iang systemics.com > >FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com > > Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA21349 for ietf-open-pgp-bks; Thu, 6 Nov 1997 04:23:10 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA21345 for ; Thu, 6 Nov 1997 04:23:03 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id NAA18723; Thu, 6 Nov 1997 13:23:02 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Conflicts and Options... Date: 6 Nov 1997 12:23:02 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: References: <87881584925188@cs26.cs.auckland.ac.nz> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Peter Gutmann wrote: >running PGP on pocket calculators and the like) is that it'd be a good idea to >finally split the key management off into a seperate program, especially with >the extra bloat added by the new algorithms and key packets. About 99% of the I use modules. ;-) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id DAA20832 for ietf-open-pgp-bks; Thu, 6 Nov 1997 03:30:57 -0800 (PST) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id DAA20828 for ; Thu, 6 Nov 1997 03:30:52 -0800 (PST) Received: from cs26.cs.auckland.ac.nz (cs26.cs.auckland.ac.nz [130.216.33.9]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id AAA26345; Fri, 7 Nov 1997 00:30:53 +1300 (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <87881584925188>; Fri, 7 Nov 1997 00:30:49 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: tom.phinney@ibm.net Subject: Re: Conflicts and Options... Cc: ietf-open-pgp@imc.org Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Fri, 7 Nov 1997 00:30:49 (NZDT) Message-ID: <87881584925188@cs26.cs.auckland.ac.nz> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk >I believe that most users would be willing to migrate from their >current 2.x version to a new version (say 2.6.5, to include the magic >"5") which had > (1) a DOS-like interface identical to 2.6.3in, but with support for >the additional algorithms of 5.x (SHA1 and DSA, EG, CAST5, 3DES); > (2) with key generation extended by optional additional parameters >to specify these algorithms (somewhat like PGP 5.5's choices); > (3) with defaults for these additional parameters set in pgp.ini for >existing programs which shell to PGP to generate keys. A fourth point (which you've already touched on with your mention of people running PGP on pocket calculators and the like) is that it'd be a good idea to finally split the key management off into a seperate program, especially with the extra bloat added by the new algorithms and key packets. About 99% of the time you never need to use the key management features, and you could probably halve the size of the program by moving the code into a seperate executable. If people really want to be able to run it under a single name, you could add a wrapper which invokes pgpcrypt or pgpkey depending on whether any of the args begin with -k. Peter. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id AAA16950 for ietf-open-pgp-bks; Thu, 6 Nov 1997 00:33:36 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id AAA16946 for ; Thu, 6 Nov 1997 00:33:31 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id JAA13430; Thu, 6 Nov 1997 09:33:30 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Conflicts and Options... Date: 6 Nov 1997 08:33:30 GMT Organization: IKS GmbH Jena Lines: 24 Message-ID: References: <199711060602.GAA38516@out2.ibm.net> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Tom Phinney wrote: >If I were going to do create this 2.6.5 version, I would start with >Lutz' 2.6.3in as the base, and add the necessary algorithms and key >flags and pgp.ini parameters. In addition to the source, I would Don't do that. I tried and failed. PGP 2.6.x code is not free for development (exept 2.6.3ui). The major problem is, that PGP 2.6.x is a bunch of patches you can't work with. So I restarted from stratch. Hope to finish this year. We (http://www.in-ca.individual.net/) have to get a licence for your software from the BSI (German NSA, but much smaller and inco.*oops*). The licence we need is called E4 (== B2 orange book) / high (strongest algorithms known) for the whole system incl. software. PGP 2.6.x will not get the licence, because E3 and higher requires a source code check these patches will not survive. The new development combined with a new enhanched(!) OpenPGP specification may allow even a E6 (== A1) classification. The sources for this PGPin will be published (as work progess snapshots) under GPL and LGPL (especially allow to link the lib statically into proprietary programms w/o source). Import into USA is not limited. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id WAA15104 for ietf-open-pgp-bks; Wed, 5 Nov 1997 22:02:17 -0800 (PST) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id WAA15100 for ; Wed, 5 Nov 1997 22:02:13 -0800 (PST) Received: from anonymous (slip129-37-235-117.ca.us.ibm.net [129.37.235.117]) by out2.ibm.net (8.8.5/8.6.9) with ESMTP id GAA38516 for ; Thu, 6 Nov 1997 06:02:09 GMT Message-Id: <199711060602.GAA38516@out2.ibm.net> From: "Tom Phinney" To: Subject: Re: Conflicts and Options... Date: Wed, 5 Nov 1997 23:00:24 -0000 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Grigg wrote: > Options have been on my mind lately. More than anything else, > sparked by the 2.6 versus 5.x issue. > 3. A compatible 2.6 / 5.x method arises, so all product can handle > all comms. This would migrate people over to the new methods more > quickly, perhaps within 2 years. > 4. Two separate standards opposed around some axis ... > (I am beginning to wonder myself whether this is inevitable, due to > the slow upgrade represented by the pure 5.x line ... > We should remember that standards might be written by WGs and > authorised by quango-like administrators, but they are accepted by > users. The success of any standard that this WG produces will not > be known for many years, and will be dictated by market reactions > to it and other factors. I believe that most users would be willing to migrate from their current 2.x version to a new version (say 2.6.5, to include the magic "5") which had (1) a DOS-like interface identical to 2.6.3in, but with support for the additional algorithms of 5.x (SHA1 and DSA, EG, CAST5, 3DES); (2) with key generation extended by optional additional parameters to specify these algorithms (somewhat like PGP 5.5's choices); (3) with defaults for these additional parameters set in pgp.ini for existing programs which shell to PGP to generate keys. The major problem with migration to PGP 5.x is not the additional algorithms; it is the limited integration of the PGP 5.x clients with existing platforms and tools. PGP 2.x works on 80286s and up, on palmtops, and on virtually any other machine's DOS emulator. It works with the remailers and nymservers and steganography tools and everything else which people use today to protect themselves from prying eyes. It integrates into a wide variety of mail and news clients through PGPclick and many other support tools. If I were going to do create this 2.6.5 version, I would start with Lutz' 2.6.3in as the base, and add the necessary algorithms and key flags and pgp.ini parameters. In addition to the source, I would produce both RSAREF-based and non-US/Canada executables for DOS PCs, so that the majority of users (who don't have the necessary compilation tools) could do a simple download to upgrade. But I don't have the toolset necessary to this task; perhaps those of you who do could tackle the job. Tom Phinney PGP: pub 1024 RSA:0xFA7148F1 DSS/EG:0x8A297007 on keyservers Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA13553 for ietf-open-pgp-bks; Wed, 5 Nov 1997 19:53:31 -0800 (PST) Received: from iglou2 (exim@iglou2.iglou.com [192.107.41.17]) by mail.proper.com (8.8.7/8.7.3) with SMTP id TAA13549 for ; Wed, 5 Nov 1997 19:53:27 -0800 (PST) Received: from XENA [204.255.239.95] by iglou2 with smtp (8.7.3/8.6.12) id 0xTJ0U-0002Zr-00; Wed, 5 Nov 1997 22:53:23 -0500 Received: by localhost with Microsoft MAPI; Wed, 5 Nov 1997 22:52:35 -0500 Message-ID: <01BCEA3D.822070C0.darrylr@iglou.com> From: "Darryl L. Rowe" To: "ietf-open-pgp@imc.org" Subject: Bravo! Date: Wed, 5 Nov 1997 22:18:57 -0500 X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Works for me. -----Original Message----- From: Richard Johnson [SMTP:rdump@river.com] Sent: Wednesday, November 05, 1997 17:33 PM To: Jon Callas; mark@unicorn.com; ietf-open-pgp@imc.org Subject: Re: Just say NO to key escrow or CMR/ARR revisited Instead, let's leave message recovery up to the implementors of individual applications, as an added feature not part of the official open-pgp standard. Those who sell into markets where such features are desired can add them. The rest of the world will not have to be forced to go along. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12895 for ietf-open-pgp-bks; Wed, 5 Nov 1997 18:43:28 -0800 (PST) Received: from colorado.river.com (colorado.river.com [206.168.172.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12885 for ; Wed, 5 Nov 1997 18:43:20 -0800 (PST) Received: from poudre.river.com (206.168.172.17) by colorado.river.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 5 Nov 1997 19:43:05 -0700 Message-Id: In-Reply-To: <199711052305.SAA11564@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Nov 1997 19:43:10 -0700 To: "William H. Geiger III" , ietf-open-pgp@imc.org From: "Richard Johnson" Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 15:49 -0700 on 11/05/1997, William H. Geiger III wrote: > In , on 11/05/97 > at 03:32 PM, "Richard Johnson" said: > > >It is not fear-mongering to request that the tags not even be defined > >because they unnecessarily weaken the security of the standard. > > How does having a request tag in the key weaken security?? The tag can be > used or ignored as the implementors see fit. No one is saying that you > MUST respect the request tag and no one is saying that you MUST generate > keys that contain such flags. > If only it were just a request tag. PGP Inc's SMTP policy enforcer turns the "request" into more of a demand. It says, in its most strict incarnation, 'encrypt to a 3rd party key we specify, or else your message will not be allowed to reach the intended recipients.' (Given the tags in the messages, if PGP didn't write such an enforcer, someone else would have.) > >Please, let's not place hooks that can easily be abused to require > >encryption to 3rd party keys into the standard. Enforcement of such > >requirements by software such as PGP's SMTP agent are all too real > >possibilities (er, that exists already, doesn't it). > > the biggest "hook" for the type of abuse you are so fearfull of is > the ability to encrypt to multiple keys. The CMR tag is quite trivial > compaired to this. So are you willing to continue with your logic that > such "hooks" are to be avoided and call for a complete re-write of PGP so > this can be advoided?? > The problem I'm worried about is _forced_ encryption to 3rd party keys by senders who don't need or desire to encrypt to those keys, but acquiese because their messages won't get through if they don't. Here, we just differ by a matter of degree. Taking your point about encryption to multiple keys being a "hook" a (large) step further, the ability to encrypt to even a single key is a "hook" that should probably be avoided if we want to keep attackers from having any chance of decrypting the message. Humor aside, I think capabilities that can easily be abused (and are being abused?) to _require_ encryption to 3rd party keys do not belong in the open-pgp specification. Such features offer a many orders of magnitude reduction of effort and storage needs to a drift-net attacker who wants to decrypt a large number of messages. Instead of having to obtain, sort and use thousands of individual keys, the attacker will only need to steal (or legislatively require access to) a single high value, long term recovery key. Also, in a worst-case attack scenario where the adversary is a national government (not necessarily your government...), it will certainly be politically easier for them to require access to recovery keys, as a wedge, than it will be to require access to all individual keys. Granted, either could be achieved by a government, but the high value recovery keys will be easier for them to both obtain and manage. In other attack scenarios with fewer overtones of big brother (or big French uncle), a high value, long term recovery key still reduces the work that needs to be done by an attacker seeking to perform corporate espionage. Message recovery, as implemented in PGP 5.5 with forceable encryption to 3rd party keys, is an unnecessary weakness in the message format that scales too well for the attacker. > >Instead, let's leave message recovery up to the implementors of > >individual applications, as an added feature not part of the official > >open-pgp standard. Those who sell into markets where such features are > >desired can add them. The rest of the world will not have to be forced > >to go along. > > No one is forceing anyone to do anything here. No one is calling for MUST > CMR key generation, no one is calling for MUST CMR implementation, all > that is being requested in the spec is the definition of the CMR tag in > the key. If you don't like it don't use it!! I think this falls in line > with letting those who wish to implement message recovery to do so and > those who do not don't. > PGP Inc.'s SMTP policy enforcer shows quite clearly how use of the CMR keys can be (and is being?) required. The tags should thus not be defined as part of the official standard, as this leaves a wide opening (already being exploited?) for forcing encryption of messages to 3rd party keys. This unnecessarily weakens the security of the standard. Message recovery can and should be done only for those markets that need it, in the clients they run, to avoid forcing the rest of the world to share the increased risk. Message recovery features thus need to be outside the open-pgp standard. Richard Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id SAA12842 for ietf-open-pgp-bks; Wed, 5 Nov 1997 18:39:54 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id SAA12837 for ; Wed, 5 Nov 1997 18:39:49 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id SAA20201; Wed, 5 Nov 1997 18:39:45 -0800 (PST) Message-Id: <3.0.3.32.19971105184011.009fd240@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 05 Nov 1997 18:40:11 -0800 To: "darrylr@iglou.com" , "ietf-open-pgp@imc.org" From: Jon Callas Subject: Re: Management by Committee ... In-Reply-To: <01BCE9CF.8FC53760.darrylr@iglou.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:45 AM 11/5/97 -0500, Darryl L. Rowe wrote: IMO, Phil/PGP should simply present the standard to IETF for review, make any modifications, resubmit and so on a couple more times and present a finished product. This group simply illustrates to me the fundamental rule that to really screw things up requires a committee. Though W. Geiger, Jon and a couple others are signalling quite well, others have an enhanced noise level which seems to be subverting any progress while others (i.e. RSA) manage to get their PR licks in on other fronts. (Wonder if any posters are RSA stooges ...?) Thanks for the vote of confidence, but I disagree comepletely about just "presenting" something to the IETF. Before we at PGP Inc. started this working group, we informally discussed something that we called "unencumbered PGP." This was PGP with no encumbered algorithms. PGP 5.0 was the first stab at it. Actually, PGP 3 was the first stab at it, from even before the formation of PGP Inc. All we did at PGP Inc. was to put a name to what had already been happening. (PGP 5.0 was the first release of the long-awaited "PGP 3" code. It got its number bumped to 5 because of the Viacrypt products numbered "PGP 4.x" that were actually modifications to 2.6.x.) There were also a number of other things that were happening related to that. Most importantly, we did not document the new key formats adequately. We put out a newsletter (called The Zimmermann Telegram) this spring that had notes on the new key and signature formats. When we did that, I sat down with a copy of RFC 1991 and the Zimmermann Telegram article and started writing some PGP-compatible utilities. I ended up with a long list of deficiencies, exceptions, and oh-by-the-ways that made it impossible to use those as specs. This concerned me, because there are a number of people who make PGP-compatible software who weren't going to have an easy time making it work with the new stuff. I started lobbying to get this done. In those days, we believed that the EAR provisions about providing "technical support" being an export precluded us from documenting the packet format except with ink on paper, too. I also wanted to revise the packet format. I dislike the "hand huffman-coding" in the PGP formats. There are other idiosyncratic things in the way PGP works that I have no opinion about, but other people don't like. I thought that housecleaning was in order. There are of course problems with doing a housecleaning, particularly in migrating old software forward, but that doesn't mean I don't want to houseclean, only that I understand I'm not likely to see that desire fulfilled. I don't know who exactly came up with the idea for an OP working group. It was some combination of Charles Breed and me, sometime in late June. We discussed the possibility with people in the IETF and people at PGP. We warned people at PGP that making something be an IETF standard means change control is released to the IETF, encumbered algorithms are disallowed (which we were doing anyway), and so on. I warned people that PGP 5.x would probably not be OP-compliant. Everyone agreed this was okay. (By the bye, according to the spec I'm now finishing up, it isn't.) We agreed to all the requirements that other people who want to make IETF standards have to. This includes the SECSH people, the TLS people, and anyone else who starts from proprietary technology. We got a BOF for Munich. We called it OpenPGP so that everyone would know what it meant. We also started working on an OpenPGP draft for Munich. Everyone who worked on that draft worked very hard, but it was only less woefully inadequate than what had gone before. At the BOF in Munich, we put everything on the table. I said, "everything is negotiable." At Munich, we were told that we've followed the procedures more closely than most working groups do. We were also given the advice, "stop being so nice." As the team of us formed the working group, we settled a number of the questions left open at the BOF. One was that there is to be no new format, we'd start OP from PGP 5.x because PGP 2.6 can't be an IETF standard, the PGP 5 formats solve those problems, solve the security weaknesses of the PGP 2.6, and they predate PGP Inc., too. If you want to propose new formats once OP 1.0 is finished, that's fine with me! I'm the editor for OP-FORMAT 1.0. My personal goal for the OP working group is to get OP done ASAP, in such a form that anyone -- PGP Inc., Systemics, Bill Geiger, and so on can build interoperable, expandable products from it. And then I want to leave. I'm an engineer, not a spec maven. By the bye, I want to say now that I've been grumpy about the October date for the OP-FORMAT draft. When the WG was formed, I said I wasn't going to make it, but I could make a Thanksgiving date. I am someone who thinks schedules are there to be met, not broken. I loathe being forced to play for down one, if you'll pardon the bridge metaphor. I'm pretty sure I can get the draft to John, Lutz, and Rodney by Friday so that it can be on an FTP site after they are done with it, but it's not a foregone conclusion. Like I said before, OP-FORMAT is not just a documentation of PGP 5.x. It's based on PGP 5.x, but it has changes in it to make it a good IETF standard, and PGP will have to catch up to that. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA12165 for ietf-open-pgp-bks; Wed, 5 Nov 1997 17:52:26 -0800 (PST) Received: from PICARD.3K.COM (picard.3k.com [198.151.172.33]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA12159 for ; Wed, 5 Nov 1997 17:52:22 -0800 (PST) From: "Chris Bartram" Organization: 3k Associates Reply-To: rcb@3k.com Message-Id: <006DSF@PICARD.3K.COM> X-Mailer: NetMail/3000 [Version B.06 97/10/28] MIME-Version: 1.0 Content-Type: Text/Plain Date: Wed, 5 Nov 1997 20:51:55 -0500 X-Hpdesk-Priority: 3 (Normal Priority) Subject: Re[2]: IETF process (was How many 2.6 users?) To: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In <34610813.7EB29377@systemics.com> IANG@SYSTEMICS.COM writes: [snip] > > So the existence of patented technology (such as RSA or IDEA) would > > seem to be not necessarily a problem, as long as the patent is licensed > > under appropriately "open" terms. [snip] > > Whether RSA meets this standard is open > > to question - certainly they have been accused by their detractors of > > non-openness in their licensing process. [snip] > I would think that having the RSA algorithm listed in the standard, > along with an IESG comment that said that this algorithm may not be > available under open, non-discriminatory and reasonable guidelines to > all parties would be quite a useful bargaining point. > > We could go even further. You could say that the RSA algorithm is to be > used, except where algorithm is not available under open, > non-discriminatory and reasonable guidelines. If we need a definition > of this, I would suggest [snip] > All of which seems obvious of course, based on the snippet above. Are > there any counter-views? As someone that develops for a platform not officially "blessed" by RSA, I would strongly object to RSA technology being referenced in an encryption standard. We have approached RSA multiple times, and cannot even *get* a license for their technology (even if we volunteer to port it ourselves) at any cost. We dropped out of monitoring the S/MIME standards a while back when it looked like it was going to require RSA technology-- so we took up monitoring OpenPGP as an alternative. We develop an e-mail system for HP3000 computers and fully intend to implement and support OpenPGP on this platform. Recommendation (or requirement) of a technology not available to *all* implementors should not be allowed in an IETF standard. Note; pgp and the rsalib code *do* work fine on our platform [hp 3000 computers running the MPE/iX OS] but we still cannot get a license for the technology to "legally" use it. Not very *open*. -Chris Bartram 3k Associates, Inc. ______________________/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_ Chris Bartram Sales (US): 800 Net-Mail Fax:+1 703 451-3720 ______ +1 703 569-9189 mailto:sales@3k.com /__ | \__________ Sales (Europe):+44(1480)414131 Fax:+44(1480)414134 / / | / ________ Sales (Pacific):+61 3 9489 8216 Fax:+61 3 9482 5124 | /_ |< ______ Tech Support:+1 703 569-9189 Fax:+1 703 451-3720 \ __)| \ ___ mailto:support at 3k.com Me: rcb at 3k.com \______/Associates, 6901 Old Keene Mill Rd Suite 500 Springfield VA 22150 _________________Inc._/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_/\_ Gopher: gopher.3k.com Anon-FTP: ftp.3k.com WWW: http://www.3k.com/ Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id RAA11519 for ietf-open-pgp-bks; Wed, 5 Nov 1997 17:10:35 -0800 (PST) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.7/8.7.3) with SMTP id RAA11515 for ; Wed, 5 Nov 1997 17:10:31 -0800 (PST) Received: from 206.63.131.9 by cane.deming.com with SMTP (WorldSecure Server SMTP Relay v2.01); Wed, 05 Nov 97 17:10:29 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCEA0D.B7CE8250@cane.deming.com>; Wed, 5 Nov 1997 17:10:29 -0800 Message-ID: From: "Ron Craswell" To: "'ietf-open-pgp@imc.org'" Subject: RE: Conflicts and Options... Date: Wed, 5 Nov 1997 17:10:29 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 X-WSS-ID: 187FC68F1895-187FC68F1896-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wednesday, November 05, 1997 4:33 PM, Ian Grigg [SMTP:iang@systemics.com] wrote: > > > You may also > > note that this new spec has no MUST requirement for any RSADSI > > technology. > > What is the proposal, and how does it cope with the existing user base? Please see ftp://ietf.org/internet-drafts/draft-ramsdell-smime-msg-00.txt Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id QAA10960 for ietf-open-pgp-bks; Wed, 5 Nov 1997 16:32:05 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id QAA10956 for ; Wed, 5 Nov 1997 16:32:01 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id DAA02607; Thu, 6 Nov 1997 03:06:24 +0100 (MET) Message-ID: <3461104A.371E284D@systemics.com> Date: Thu, 06 Nov 1997 00:33:14 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Ron Craswell CC: "'ietf-open-pgp@imc.org'" Subject: Re: Conflicts and Options... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ron Craswell wrote: > Please note that none of the authors are RSADSI employees. Accepted. > You may also > note that this new spec has no MUST requirement for any RSADSI > technology. What is the proposal, and how does it cope with the existing user base? -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA10287 for ietf-open-pgp-bks; Wed, 5 Nov 1997 15:57:03 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA10282 for ; Wed, 5 Nov 1997 15:56:59 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id CAA02501; Thu, 6 Nov 1997 02:31:21 +0100 (MET) Message-ID: <34610813.7EB29377@systemics.com> Date: Wed, 05 Nov 1997 23:58:12 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Raph Levien CC: ietf-open-pgp@imc.org, Gene Hoffman Subject: Re: IETF process (was How many 2.6 users?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Raph Levien wrote: > I believe that the most relevant document explaining IETF process is RFC > 2026. Quoting section 10.3.2(c), which is relevant for standards track > documents: > > (C) Where the IESG knows of rights, or claimed rights under (A), the > IETF Executive Director shall attempt to obtain from the claimant > of such rights, a written assurance that upon approval by the IESG > of the relevant Internet standards track specification(s), any > party will be able to obtain the right to implement, use and > distribute the technology or works when implementing, using or > distributing technology based upon the specific specification(s) > under openly specified, reasonable, non-discriminatory terms. > The Working Group proposing the use of the technology with respect > to which the proprietary rights are claimed may assist the IETF > Executive Director in this effort. The results of this procedure > shall not affect advancement of a specification along the > standards track, except that the IESG may defer approval where a > delay may facilitate the obtaining of such assurances. The > results will, however, be recorded by the IETF Executive Director, > and made available. The IESG may also direct that a summary of > the results be included in any RFC published containing the > specification. > > So the existence of patented technology (such as RSA or IDEA) would > seem to be not necessarily a problem, as long as the patent is licensed > under appropriately "open" terms. Wow. Let's look at this. IDEA first. IDEA is licensed by Ascom and their licensing page is at [1]. Their schedule is at [2] and includes more prices than you can poke a stick at. What is more interesting is that you can purchase the license over the Internet at [3] (although you are forced to read the license to get there). It's especially open in the hackers sense that you do not have to use their source. I would therefore conclude that IDEA is: available to any party, distributable, purchasable under open, "reasonable" and non-discriminatory terms. Reasonable is of course a value judgement. As an administrative burden, the IETF ExecDirector should get a letter that confirms this. My reading of the site and Ascom's reputation do not indicate an issue here. > Whether RSA meets this standard is open > to question - certainly they have been accused by their detractors of > non-openness in their licensing process. OK, now RSA. I agree that RSADSI have a bad reputation on this issue. I had a look at their web site and it is appallingly closed. Note however that the above comment does not say that an assurance of openness is necessary: "The results of this procedure shall not affect advancement of a specification along the standards track, except that the IESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the IETF Executive Director, and made available. The IESG may also direct that a summary of the results be included in any RFC published containing the specification." "shall not affect advancement" is quite specific, which leaves open the question as to why the IESG supposedly rejected the S/MIME and SSL V3 standards. Perhaps they were simply deferred instead, as this deferral might be a bargaining chip in the hands of IETF. Can you comment in the S/MIME case as to why the above was considered to be a rejection? I would think that having the RSA algorithm listed in the standard, along with an IESG comment that said that this algorithm may not be available under open, non-discriminatory and reasonable guidelines to all parties would be quite a useful bargaining point. We could go even further. You could say that the RSA algorithm is to be used, except where algorithm is not available under open, non-discriminatory and reasonable guidelines. If we need a definition of this, I would suggest * prices not in excess of other comparables (is ElGamal comparable? :-), * purchasable over the web with no possibility of a human being interposing some "conditions." * no restrictions on code use (i.e., roll-your-own is ok, as is use somebody else's) All of which seems obvious of course, based on the snippet above. Are there any counter-views? > Hope this helps. It's excellent, thanks. Clears the FUD right out. [1] http://www.ascom.ch/Web/systec/policy/main.html [2] http://www.ascom.ch/Web/systec/policy/normal/exhibit3.html [3] http://www.ascom.ch/Web/systec/policy/normal/orderform.html -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA09292 for ietf-open-pgp-bks; Wed, 5 Nov 1997 15:06:52 -0800 (PST) Received: from cane.deming.com (host9.deming.com [206.63.131.9]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA09285 for ; Wed, 5 Nov 1997 15:06:47 -0800 (PST) Received: from 206.63.131.9 by cane.deming.com with SMTP (WorldSecure Server SMTP Relay v2.01); Wed, 05 Nov 97 15:06:45 -0800 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5) id <01BCE9FC.6E734610@cane.deming.com>; Wed, 5 Nov 1997 15:06:45 -0800 Message-ID: From: "Ron Craswell" To: "'Ian Grigg'" , "'ietf-open-pgp@imc.org'" Subject: RE: Conflicts and Options... Date: Wed, 5 Nov 1997 15:06:43 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5 MIME-Version: 1.0 X-WSS-ID: 187E238F745-187E238F749-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, Nov 05, 1997 2:12 PM, "Ian Grigg" wrote: > > Whether you believe that PGP Inc would do such a thing or not, I doubt > if you would disagree that there is a clear conflict in interest in PGP > Inc writing the draft around PGP Inc product. The same conflict of > interest exists around RSADSI, for example. > Point of accuracy -- the current S/MIME spec is being written by: Section 1: Cryptographic Message Syntax Russ Housley SPYRUS Section 2: Enhanced Security Services for S/MIME Paul Hoffman Internet Mail Consortium Section 3: S/MIME Version 3 Message Specification Blake Ramsdell Worldtalk Please note that none of the authors are RSADSI employees. You may also note that this new spec has no MUST requirement for any RSADSI technology. -- Ron Craswell Worldtalk Corp. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA09241 for ietf-open-pgp-bks; Wed, 5 Nov 1997 15:04:57 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA09236 for ; Wed, 5 Nov 1997 15:04:52 -0800 (PST) Received: from users.invweb.net (cppp21.dotstar.net [208.143.93.121]) by users.invweb.net (8.8.7/8.8.7) with SMTP id SAA11564 for ; Wed, 5 Nov 1997 18:05:04 -0500 Message-Id: <199711052305.SAA11564@users.invweb.net> From: "William H. Geiger III" Date: Wed, 05 Nov 97 16:49:56 -0600 Subject: Re: Just say NO to key escrow or CMR/ARR revisited X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: rdump@river.com,jon@pgp.com,mark@unicorn.com,ietf-open-pgp@imc.org To: ietf-open-pgp@imc.org X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In , on 11/05/97 at 03:32 PM, "Richard Johnson" said: >At 13:25 -0700 on 11/5/97, Jon Callas wrote: >> At 08:04 AM 11/5/97 -0800, mark@unicorn.com wrote: >> I have no great problem with defining the neccesary flags and tags >> as 'implementation defined' so that non-CMR applications won't barf >> when they see them, but I certainly do not want to have to build >> snoopware into my applications in order to comply with the standard. >> >> This is *PRECISELY* what my original suggestion was. I think this is why >> some people talk about "fear mongering." No one has ever suggested anything >> by just defining the tags, and leaving treatment up to the application, >> except the fear mongers. >> >It is not fear-mongering to request that the tags not even be defined >because they unnecessarily weaken the security of the standard. How does having a request tag in the key weaken security?? The tag can be used or ignored as the implementors see fit. No one is saying that you MUST respect the request tag and no one is saying that you MUST generate keys that contain such flags. >Please, let's not place hooks that can easily be abused to require >encryption to 3rd party keys into the standard. Enforcement of such >requirements by software such as PGP's SMTP agent are all too real >possibilities (er, that exists already, doesn't it). the biggest "hook" for the type of abuse you are so fearfull of is the ability to encrypt to multiple keys. The CMR tag is quite trivial compaired to this. So are you willing to continue with your logic that such "hooks" are to be avoided and call for a complete re-write of PGP so this can be advoided?? >Also, use of "recovery" keys to which a large amount of traffic is >encrypted merely provides a high value key as a target for attack, by any >adversary, government or not. Well then don't implement it. No one is calling for CMR to be maditory in the specs. You don't like it don't use it. >Instead, let's leave message recovery up to the implementors of >individual applications, as an added feature not part of the official >open-pgp standard. Those who sell into markets where such features are >desired can add them. The rest of the world will not have to be forced >to go along. No one is forceing anyone to do anything here. No one is calling for MUST CMR key generation, no one is calling for MUST CMR implementation, all that is being requested in the spec is the definition of the CMR tag in the key. If you don't like it don't use it!! I think this falls in line with letting those who wish to implement message recovery to do so and those who do not don't. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGD6c49Co1n+aLhhAQFRewQAzV5dB+EtRwLsUEHEP34JwUa8C4NZCbPQ +0QabYKSyjVlCd/OQ+vS1sRZXTfrOikinPbY3ZV5h+Ou1r+GELsV7wVizRbg3VCb 3xa+zwS8pQRzATQud43GEctc9WjNcPFlddsATqcy7Cyycszhs1MSGo8cor8nAszs eR+2ISJbjXw= =h9gy -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08925 for ietf-open-pgp-bks; Wed, 5 Nov 1997 14:48:03 -0800 (PST) Received: from blacklodge.c2.net (blacklodge.c2.net [208.139.36.35]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08920 for ; Wed, 5 Nov 1997 14:48:00 -0800 (PST) Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id OAA05178; Wed, 5 Nov 1997 14:51:19 -0800 (PST) Date: Wed, 5 Nov 1997 14:51:19 -0800 (PST) From: Raph Levien X-Sender: raph@blacklodge.c2.net To: Ian Grigg cc: ietf-open-pgp@imc.org, Gene Hoffman Subject: IETF process (was How many 2.6 users?) In-Reply-To: <3460F0B6.19491176@systemics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, 5 Nov 1997, Ian Grigg wrote: > Can someone please post or point me at an authoritive reference to the > IETF policy that has been mentioned, to whit, will not accept encumbered > algorithms. > > ( While we're at it, it has been mentioned that there is an IETF policy > that there be an unencumbered implementation - does anybody have an > authoritive reference on that as well?) Sorry for jumping into the fray here. I'm no expert on IETF process, but I did look into this issue a couple of months ago when there was a similar debate on the S/MIME list. I believe that the most relevant document explaining IETF process is RFC 2026. Quoting section 10.3.2(c), which is relevant for standards track documents: (C) Where the IESG knows of rights, or claimed rights under (A), the IETF Executive Director shall attempt to obtain from the claimant of such rights, a written assurance that upon approval by the IESG of the relevant Internet standards track specification(s), any party will be able to obtain the right to implement, use and distribute the technology or works when implementing, using or distributing technology based upon the specific specification(s) under openly specified, reasonable, non-discriminatory terms. The Working Group proposing the use of the technology with respect to which the proprietary rights are claimed may assist the IETF Executive Director in this effort. The results of this procedure shall not affect advancement of a specification along the standards track, except that the IESG may defer approval where a delay may facilitate the obtaining of such assurances. The results will, however, be recorded by the IETF Executive Director, and made available. The IESG may also direct that a summary of the results be included in any RFC published containing the specification. So the existence of patented technology (such as RSA or IDEA) would seem to be not necessarily a problem, as long as the patent is licensed under appropriately "open" terms. Whether RSA meets this standard is open to question - certainly they have been accused by their detractors of non-openness in their licensing process. Hope this helps. Raph Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08634 for ietf-open-pgp-bks; Wed, 5 Nov 1997 14:34:34 -0800 (PST) Received: from colorado.river.com (colorado.river.com [206.168.172.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08630 for ; Wed, 5 Nov 1997 14:34:26 -0800 (PST) Received: from dolores.scd.ucar.edu (128.117.8.11) by colorado.river.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 5 Nov 1997 15:34:10 -0700 Message-Id: In-Reply-To: <3.0.3.32.19971105122514.00ae6100@mail.pgp.com> References: <878745869.8770.193.133.230.33@unicorn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Nov 1997 15:32:32 -0700 To: Jon Callas , mark@unicorn.com, ietf-open-pgp@imc.org From: "Richard Johnson" Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 13:25 -0700 on 11/5/97, Jon Callas wrote: > At 08:04 AM 11/5/97 -0800, mark@unicorn.com wrote: > I have no great problem with defining the neccesary flags and tags > as 'implementation defined' so that non-CMR applications won't barf > when they see them, but I certainly do not want to have to build > snoopware into my applications in order to comply with the standard. > > This is *PRECISELY* what my original suggestion was. I think this is why > some people talk about "fear mongering." No one has ever suggested anything > by just defining the tags, and leaving treatment up to the application, > except the fear mongers. > It is not fear-mongering to request that the tags not even be defined because they unnecessarily weaken the security of the standard. Please, let's not place hooks that can easily be abused to require encryption to 3rd party keys into the standard. Enforcement of such requirements by software such as PGP's SMTP agent are all too real possibilities (er, that exists already, doesn't it). Also, use of "recovery" keys to which a large amount of traffic is encrypted merely provides a high value key as a target for attack, by any adversary, government or not. Instead, let's leave message recovery up to the implementors of individual applications, as an added feature not part of the official open-pgp standard. Those who sell into markets where such features are desired can add them. The rest of the world will not have to be forced to go along. Richard Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08362 for ietf-open-pgp-bks; Wed, 5 Nov 1997 14:17:23 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08353 for ; Wed, 5 Nov 1997 14:17:13 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id AAA02080; Thu, 6 Nov 1997 00:51:39 +0100 (MET) Message-ID: <3460F0B6.19491176@systemics.com> Date: Wed, 05 Nov 1997 22:18:30 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: ietf-open-pgp@imc.org CC: Gene Hoffman Subject: Re: How many 2.6 users? References: <34595716.1CFBAE39@systemics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Grigg wrote: > Gene Hoffman wrote: > > I think that comparing what is in use today (90K DSA/ElGamal keys versus > > 20K RSA keys) with how many total copies of an old piece of software > > were distributed is a logical flaw. > > I must admit that I don't know how the 4 million was calculated, Now I remember where the figure of 4 million users of PGP software comes from. Check out the latest PGP Inc publicity release [vinnie@vmeng.com: PGP APPROVED TO EXPORT STRONG ENCRYPTION TO BANKS WORLDWIDE TO PROTECT FINANCIAL COMMUNICATIONS AND TRANSACTIONS [snip] About PGP .... With over four million users in 50 countries ... > But the issue keeps getting raised, so in order to clarify this > situation, let's find out. How can we work out how many pgp2.6 users > are out there? I've got one suggestion: post to cypherpunks these > questions: ( To cap off my recent survey, I got a smattering of responses that combined gave 0, 0, and 10-25% usage by pgp5.x keys. Not statistically significant, but zero support for any notion that pgp5.x keys are of a worthwhile percentage. ) Having established that we all agree that the user base of PGP software is in the order of four millions, and the user base for PGP Inc's 5.x products is also in the order of 100k, can we put the shaggy dog tales to bed and accept that the community is using legacy software? Now we just need to come up with a suitable proposal that seeks not to disenfranchise the four million in order to meet the IETF policy. Can someone please post or point me at an authoritive reference to the IETF policy that has been mentioned, to whit, will not accept encumbered algorithms. ( While we're at it, it has been mentioned that there is an IETF policy that there be an unencumbered implementation - does anybody have an authoritive reference on that as well?) -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA08221 for ietf-open-pgp-bks; Wed, 5 Nov 1997 14:10:47 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA08217 for ; Wed, 5 Nov 1997 14:10:42 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id AAA02045; Thu, 6 Nov 1997 00:44:59 +0100 (MET) Message-ID: <3460EF26.5B98DC11@systemics.com> Date: Wed, 05 Nov 1997 22:11:50 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: "darrylr@iglou.com" CC: "'Anonymous'" , "ietf-open-pgp@imc.org" Subject: Conflicts and Options... References: <01BCE9F4.4AF39260.darrylr@iglou.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Darryl L. Rowe wrote: > > I _did_ say: "...for review, ... modify, ... resubmit and so on > a couple (times)." > > That's _not_ a "rubber stamp." The danger is that even though it is reviewed, PGP Inc can attempt to keep changes to a minimum. As editor (or, employing the editor), PGP Inc are effectively in the driving seat. Whether you believe that PGP Inc would do such a thing or not, I doubt if you would disagree that there is a clear conflict in interest in PGP Inc writing the draft around PGP Inc product. The same conflict of interest exists around RSADSI, for example. One way to counterbalance that conflict is to write the draft in public (the Lutz method). Another way is to not put so much of the responsibility into PGP Inc's hands (which may not be practical if they are the only ones prepared to pay the editor's salary). Whatever your politics, it can't be fun being editor in that position. > No one is getting _anywhere_ with this more-or-less "off topic" > issue .... maybe this should be a _moderated_ list, eh? This might not be a good idea. It would kill it stone dead. Think of it this way. With the absence of a draft to discuss, and a moderated list being kept "on topic" we could also save on uneccessary words such as "Open." > ... Even a "rubber-stamped" PGP standard and CMR would > be preferable to _anything_ involving RSA IMO.... Options have been on my mind lately. More than anything else, sparked by the 2.6 versus 5.x issue. There are more options than you mention above: 1. The null case: * the pgp2.x de facto standard remains in place for 4 million users. (PGP Inc advertise this user base as their starting market.) * pgp5.x makes inroads into corporate America. and competes with S/MIME. * S/MIME remains in place as a de facto standard for large company mailers. I don't know how effective this is, whilst it is widespread in browsers (I gather) I have never heard of anyone using it. This is the do nothing case, which is synonymous with the WG folding without a result. 2. 5.x becomes the IETF standard. This is the "rubber-stamp." In this case, the 2.6 de facto standard will be around for a lot longer, due to the barriers. Hence, 4. below. 3. A compatible 2.6 / 5.x method arises, so all product can handle all comms. This would migrate people over to the new methods more quickly, perhaps within 2 years. 4. Two separate standards opposed around some axis of commercial/noncom or US/International. The difficulties we have experienced in this group are concentrated in the US/commercial area, so having a separate standard for one segment might work. (I am beginning to wonder myself whether this is inevitable, due to the slow upgrade represented by the pure 5.x line, as proposed in 2. above.) 5. S/MIME becomes the standard - I can't see this being the case, but RSADSI could always sweet-talk the IETF. In which case, it might gain currency in commercial markets, but I suspect pgp2.x will be around for a long time too. We should remember that standards might be written by WGs and authorised by quango-like administrators, but they are accepted by users. The success of any standard that this WG produces will not be known for many years, and will be dictated by market reactions to it and other factors. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA06238 for ietf-open-pgp-bks; Wed, 5 Nov 1997 12:24:58 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA06234 for ; Wed, 5 Nov 1997 12:24:54 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id MAA14406; Wed, 5 Nov 1997 12:24:48 -0800 (PST) Message-Id: <3.0.3.32.19971105122514.00ae6100@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 05 Nov 1997 12:25:14 -0800 To: mark@unicorn.com, ietf-open-pgp@imc.org From: Jon Callas Subject: Re: Just say NO to key escrow or CMR/ARR revisited In-Reply-To: <878745869.8770.193.133.230.33@unicorn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:04 AM 11/5/97 -0800, mark@unicorn.com wrote: This is precisely the point we're making. If CMR goes into the Open PGP spec then this will happen *automatically* with any compliant application which receives a GMR key from abroad. How do you know? >From my very first post on the subject to the OP list on CMR, I said that I opposed what you're suggesting above. If CMR were mandatory, PGP products would not comply, because it isn't mandatory in any PGP product. I have no great problem with defining the neccesary flags and tags as 'implementation defined' so that non-CMR applications won't barf when they see them, but I certainly do not want to have to build snoopware into my applications in order to comply with the standard. This is *PRECISELY* what my original suggestion was. I think this is why some people talk about "fear mongering." No one has ever suggested anything by just defining the tags, and leaving treatment up to the application, except the fear mongers. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA05978 for ietf-open-pgp-bks; Wed, 5 Nov 1997 12:10:59 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA05971 for ; Wed, 5 Nov 1997 12:10:45 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id MAA14049; Wed, 5 Nov 1997 12:07:19 -0800 (PST) Message-Id: <3.0.3.32.19971105120744.00ac6590@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 05 Nov 1997 12:07:44 -0800 To: Adam Back , I.Brown@cs.ucl.ac.uk From: Jon Callas Subject: Re: Just say NO to key escrow or CMR/ARR revisited Cc: whgiii@invweb.net, ietf-open-pgp@imc.org In-Reply-To: <199711051535.PAA05243@server.test.net> References: <346072BB.80BAD889@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 03:35 PM 11/5/97 GMT, Adam Back wrote: Because it is PGP Inc is trying CMR people's reasoning abilities kick out "It can't be bad... PGP Inc are doing it". "You don't understand it's very privacy respecting". Sheesh. Excuse me. We are doing no such thing. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA04983 for ietf-open-pgp-bks; Wed, 5 Nov 1997 11:26:15 -0800 (PST) Received: from out2.ibm.net (out2.ibm.net [165.87.194.229]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA04978 for ; Wed, 5 Nov 1997 11:26:09 -0800 (PST) Received: from slip139-92-41-70.ut.nl.ibm.net (slip139-92-41-70.ut.nl.ibm.net [139.92.41.70]) by out2.ibm.net (8.8.5/8.6.9) with SMTP id TAA111124 for ; Wed, 5 Nov 1997 19:25:58 GMT Message-Id: <3.0.3.16.19971105202340.346f5904@pop.mindspring.com> X-PGP-RSA-KeyID: 0x78CD4329 X-PGP-RSA-Fingerprint: A3 57 37 48 54 88 FE 4A D6 81 C0 74 DA 00 A6 F7 X-HomePage: X-Sender: aegreene@pop.mindspring.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (16) Date: Wed, 05 Nov 1997 20:23:40 +0100 To: IETF Open-PGP List From: "Anthony E. Greene" Subject: CMR & Open-PGP In-Reply-To: <199711051720.RAA07985@server.test.net> References: <878745869.8770.193.133.230.33@unicorn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- At 08:04 1997-11-05 -0800, mark@unicorn.com wrote: >I have no great problem with defining the neccesary flags and tags >as 'implementation defined' so that non-CMR applications won't barf >when they see them, but I certainly do not want to have to build >snoopware into my applications in order to comply with the standard. Mark's idea is a good one. It makes Open-PGP compatible with current implementations and does not add any dangers. It also leaves the door open for developers who need to implement CMR for their markets. PGP 5.0 does not choke on keys with ARR fields. This is the behavior we need to document. Whether or not an Open-PGP compliant application responds to ARR requests should be an implementation decision. Writing a completely new messaging security standard, even if one is needed, is not part of the charter. I recommend we stay within the charter and move forward with open issues. Tony -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: cp850 Comment: Anthony E. Greene PGP-RSA-KeyId: Pub 1083 0x78CD4329 iQCdAwUBNGDHZkRUP9V4zUMpAQHYDAQ6AgdTR7uN8/ZKKdNCQCJhjvFRSkW8TWeD 4mhVBxEmuaNxE2ZeqqkSZ2MZT85emFMd7YmP1NkQTmzKECWiatrAG1wT3Jf1HJQ8 ZvOZuN8xgm6NkpmnD4jWMOYhgLeOyX7q24Vn563v/Yp86ZgBN93Jcv73JvGWbi5/ s/a8YcBtO/3O8kWBEn8EAg== =uM4v -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA04878 for ietf-open-pgp-bks; Wed, 5 Nov 1997 11:22:11 -0800 (PST) Received: from tor.securecomputing.com (tor.securecomputing.com [199.71.190.98]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA04870 for ; Wed, 5 Nov 1997 11:22:05 -0800 (PST) Received: by janus.tor.securecomputing.com id <11653>; Wed, 5 Nov 1997 14:22:03 -0500 Message-Id: <97Nov5.142203est.11653@janus.tor.securecomputing.com> To: uri@watson.ibm.com cc: Ned.Freed@innosoft.com (Ned Freed), ietf-open-pgp@imc.org Subject: published Internet Drafts (was Re: Ballot result: Element vs Packet) References: <9711051534.AA42860@watpub1.watson.ibm.com> In-reply-to: uri's message of "Wed, 05 Nov 1997 10:34:53 -0500". <9711051534.AA42860@watpub1.watson.ibm.com> From: "C. Harald Koch" Date: Wed, 5 Nov 1997 14:21:56 -0500 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In message <9711051534.AA42860@watpub1.watson.ibm.com>, Uri Blumenthal writes: > > Ned, I take exception to this. In my NSH opinion, it is poerfectly OK to > circulate the drafts on the list until they're ready to be submitted to > the RFC editor (and that indeed is how several WGs do their job). The point of Internet Drafts is to get review of a document *before* it becomes an RFC. IDs usually go through several iterations before being submitted to the RFC Editor. This *includes* review by people who are interested in a particular area, but don't necessarily have time to wade through the WG mailing list (which is particularly verbose and off-topic in the PGP WG). Then there's the issue that E-Mail is not a good tool for distributing large documents. Some people still run e-mail clients on small machines, like palmtop computers, and don't like receiving internet-draft size messages. Get the drafts *published* and into the I-D FTP sites, so that we have a target to discuss, and we can get some rational discourse going. -- Harald Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA04642 for ietf-open-pgp-bks; Wed, 5 Nov 1997 11:09:07 -0800 (PST) Received: from iglou1 (exim@iglou1.iglou.com [192.107.41.3]) by mail.proper.com (8.8.7/8.7.3) with SMTP id LAA04637 for ; Wed, 5 Nov 1997 11:09:02 -0800 (PST) Received: from darrylr [204.255.233.239] by iglou1 with smtp (8.7.3/8.6.12) id 0xTAom-00016x-00; Wed, 5 Nov 1997 14:08:44 -0500 Received: by localhost with Microsoft MAPI; Wed, 5 Nov 1997 14:08:29 -0500 Message-ID: <01BCE9F4.4AF39260.darrylr@iglou.com> From: "Darryl L. Rowe" Reply-To: "darrylr@iglou.com" To: "'Anonymous'" , "ietf-open-pgp@imc.org" Subject: To Captain A. Duncel ... Date: Wed, 5 Nov 1997 14:08:28 -0500 Organization: Vocational Economics, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I _did_ say: "...for review, ... modify, ... resubmit and so on a couple (times)." That's _not_ a "rubber stamp." I can effectively do CMR using 2.6.2 and batch files and server file/dir rights, but it's a pain. CMR is irrelevant. Set up the standard so it won't choke on anyone's app that uses it and/or some other implementation "add-ins" and move on. No one is getting _anywhere_ with this more-or-less "off topic" issue .... maybe this should be a _moderated_ list, eh? Get something done and moving before RSA gets their foot in the door? (Even a "rubber-stamped" PGP standard and CMR would be preferable to _anything_ involving RSA IMO.) I may use PGP's crypto API in a couple of our apps to protect client confidentiality ... or I may use something else. I've used PGP 4/BE with corporate keys (CMR) before it (CMR) became such an overstated issue. When we use PGP here at work the PGP key's passphrase is known _both_ to the user and, if I look it up, to me and the COO (if he looks it up). We're NOT using our own dime here at the office. At home we (and I,) do what we want and keep our own personal/private keys to ourselves. At work we "speak for the company" and encrypting files is a no-no. Though we've played with Norton's YEO a little. YEO and SecurePC both have some nice ideas that PGP should, perhaps, look at and implement in some manner, if they can. If your company PGP uses CMR, don't use CMR at home. The vast majority of the time we only use PGP to "sign" plaintext emails, so CMR is _not_ an issue. I would be all for having 3 people required to access a user's key and decrypt their messages, or (gasp) recover their password or merely _reset_ it so they could get back in themselves. Norton has such a feature in the Admin kit (a 1-time-only password, I think). But then, Norton is a file/directory encryption product, not email. Matter of fact, this would do away with the whole CMR idea - have an Admin Kit for business users where the Admin/Supervisor can just "reset" the password to "password" so they can get back in and change it ... or the boss can if the employee is dead or in prison/Mexico. How many of you expire your keys routinely? How many "normal" users generate keys with expiration dates? Hmm. Some of us keep a personal email address/key and a company email address/key and never the twain meet. And no, I'm _not_ kidding. And I, too, am increasingly frustrated by the canine tail-chasing going on. But at least I'm not posting anonymously. Last word on the subject. On Wednesday, November 05, 1997 11:31 AM, Anonymous [SMTP:nobody@REPLAY.COM] wrote: > > Darryl Rowe getting with the spirit of Open Standards writes: > > > > IMO, Phil/PGP should simply present the standard to IETF for > > review, make any modifications, resubmit and so on a couple more > > times and present a finished product. > > Yeah, right on! They write it, we rubber stamp it without question. > > > Though W. Geiger, Jon and a couple others are signalling quite > > well, > > On the topic of CMR? You're kidding, right? > > > others have an enhanced noise level which seems to be subverting > > progress while others (i.e. RSA) manage to get their PR licks in > > - An OpenPGP list member who is getting increasingly pissed off > with certain "PGP only is allowed to speak" attitudes around here Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA04023 for ietf-open-pgp-bks; Wed, 5 Nov 1997 10:44:39 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA04019 for ; Wed, 5 Nov 1997 10:44:33 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPLVBK68NK9JE0S5@INNOSOFT.COM> for ietf-open-pgp@imc.org; Wed, 5 Nov 1997 10:43:59 PST Date: Wed, 05 Nov 1997 10:35:48 -0800 (PST) From: Ned Freed Subject: Re: Ballot result: Element vs Packet In-reply-to: "Your message dated Wed, 05 Nov 1997 10:34:53 -0500 (EST)" <9711051534.AA42860@watpub1.watson.ibm.com> To: Uri Blumenthal Cc: Ned.Freed@innosoft.com, ietf-open-pgp@imc.org Message-id: <01IPNC1NPA2Q9JE0S5@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/PLAIN; CHARSET=US-ASCII References: <01IPMJO0SPLU9JEXJ2@INNOSOFT.COM> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > > ........I see what appears to be a modified version of this posted by > > Lutz to the list (which isn't the correct thing to do with drafts, BTW)... > Ned, I take exception to this. In my NSH opinion, it is poerfectly OK to > circulate the drafts on the list until they're ready to be submitted to > the RFC editor (and that indeed is how several WGs do their job). Frankly, I also could care less about drafts being posted to the list. However, some people do care about this, and sometimes say so vociferously. And this list always has enough vociferous contributions, if you know what I mean. > No disagreement with the rest though. Good. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03647 for ietf-open-pgp-bks; Wed, 5 Nov 1997 10:30:11 -0800 (PST) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.174.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA03638; Wed, 5 Nov 1997 10:30:05 -0800 (PST) Received: from [199.106.106.130] (servo.qualcomm.com [129.46.101.170]) by mage.qualcomm.com (8.8.5/1.4/8.7.2/1.13) with ESMTP id KAA20781; Wed, 5 Nov 1997 10:29:31 -0800 (PST) X-Sender: jwn2@127.0.0.1 (Unverified) Message-Id: In-Reply-To: <3.0.3.32.19971104110653.009f02a0@mail.imc.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Eudora [Macintosh version 4.0b35-1.98] 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, 5 Nov 1997 10:07:36 -0800 To: Paul Hoffman / IMC From: "John W. Noerenberg" Subject: Re: Ballot result: Element vs Packet Cc: lutz@taranis.iks-jena.de (Lutz Donnerhacke), ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 11:06 AM -0800 11/4/97, Paul Hoffman / IMC wrote: >I find this wholly offensive. This is an IETF Working Group, not a informal >gang of developers making a spec by brute force. Actually, Paul, by publishing the results, Lutz has done us all a favor. The few number of voters is a much more vivid demonstration than my words of how inconclusive such polls frequently are in an IETF mailing list. As Harald observed, the number of contributors to the mailing list far exceeded the number of participants in the poll. Lutz, once again, thank you for taking the time to do this. Unfortunately, this time the results are not particularly helpful. Polls may have their place, but we will put this aside for now. john w noerenberg, ii jwn2@qualcomm.com pager: jwn2@pager.qualcomm.com -------------------------------------------------------------------- "The great man is he who in the midst of the crowd keeps with perfect sweetness the independence of solitude." -- Ralph Waldo Emerson, "Self Reliance", 1841 -------------------------------------------------------------------- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA02570 for ietf-open-pgp-bks; Wed, 5 Nov 1997 09:34:54 -0800 (PST) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.7/8.7.3) with SMTP id JAA02566 for ; Wed, 5 Nov 1997 09:34:45 -0800 (PST) Received: from aba@p09-meadowlark-gui.tch.virgin.net [194.168.69.189] by exub via ESMTP (RAA21982); Wed, 5 Nov 1997 17:34:25 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id RAA07995; Wed, 5 Nov 1997 17:33:29 GMT Date: Wed, 5 Nov 1997 17:33:29 GMT Message-Id: <199711051733.RAA07995@server.test.net> From: Adam Back To: david.hayes@mci.com CC: whgiii@invweb.net, ietf-open-pgp@imc.org In-reply-to: <3.0.2.32.19971105091040.006ada84@postoffice.switcheng.mci.com> (message from David Hayes on Wed, 05 Nov 1997 09:10:40 -0600) Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk David Hayes writes: > > At 06:53 AM 11/5/97 -0600, William H. Geiger III wrote: > >Plain and simple with or without CMR if the government is going to pass > >laws requiring that all messages be encrypted with a government key then > >you are f**ked, plain and simple. > > Your statement supposes that _the_ (singular) government will do this. In > fact, there are many governments in the world. Some of them already have > draconian laws, some have rejected them, and many are still sitting on the > fence. Absolutely. William's statement over-simplifies the logistic problems for governments in installing GAK. The interoperability issues (many governments with different political stances) and ease of software migration path are important. With a mail encryption standard, and implementations which aid the user in complying with French (SCSSI) additional recipient requests, and with Israel (mossad) requests the job is made considerably easier for governments. Let governments build their own infrastructure, let governments work out their own software migration plans, and let governments deploy their own software. Clipper failed, let's not help them build clipper VI aka OpenPGP with CMR. > PGP is supposed to protect our information from adversaries, even > democratically elected adversaries. Right. Security risks aren't fussy about the politics of the people who exploit them. > It would be better NOT to have features which are easily abusable by > adversaries, even if those features have some legitimate use. Certainly > such features should not be REQUIRED elements of a standard. Fortunately the CMR approach fails for security reasons alone, so we can dismiss it for that reason. (Though I do agree with the above statement). > Thus, using GAK means cutting one's self off from the rest of the > non-GAK world. This is exactly what I argue we should be engineering in open standards: extra GAK resistance. If the international standards purposely make it difficult to install GAK we have half won the battle. The IPSEC IETF standards people grok that argument, Ian Brown posted a URL a while back on this list explaining this strategy. To take an example SSL is forward secret. This means that it is hard to install `corporate/government web traffic recovery' because there is no software available to do it, and because it would cut those governments which tried it off from the rest of the world. This is why some of us have been arguing for forward secret transport level security for mail delivery. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Wed, 5 Nov 1997 09:34:34 -0800 (PST) Received: from aba@p09-meadowlark-gui.tch.virgin.net [194.168.69.189] by exub via ESMTP (RAA21979); Wed, 5 Nov 1997 17:34:23 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id RAA07985; Wed, 5 Nov 1997 17:20:08 GMT Date: Wed, 5 Nov 1997 17:20:08 GMT Message-Id: <199711051720.RAA07985@server.test.net> From: Adam Back To: mark@unicorn.com CC: ietf-open-pgp@imc.org In-reply-to: <878745869.8770.193.133.230.33@unicorn.com> (mark@unicorn.com) Subject: CMR semantics Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Mark Grant writes: > I have no great problem with defining the neccesary flags and tags > as 'implementation defined' so that non-CMR applications won't barf > when they see them, but I certainly do not want to have to build > snoopware into my applications in order to comply with the standard. Another option is to define in the standard correct behaviour for personal use software on receipt of ARR requests is to fill them in with random numbers as Bodo Moeller described. I can't see this worrying PGP Inc as they like to describe how easy it is to bypass anyway. This just makes the semantics that ARR is a `request' as the name suggests. And that the sender has the choice either to comply or not with that request. (Where not complying is filling random numbers in the requested extra crypto recipient.) > >The purpose of this group is to provide a strong message encryption > >standard. > > Good; so let's create that standard and leave snoopware, message > recovery and key escrow to individual implementors. Sounds good to me. I think that having multiple long term keys (up to 4 with pgp5.5!) able to decrypt messages transmitted over open communications channels is an unnecessary security risk. William stated that the discussion should be kept apolitical -- the CMR security risk is apolitical to the extent that the parties who might try to exploit the added CMR risks could be anyone: corporate espionage, disgruntled ex-employee, French secret service (long history of corporate espionage giving info to French competitors to US and other companies), etc. The point is why bother incurring the security risks, when there are simpler and more secure alternatives? I repeat: I'd like to see those who want CMR justify why they think it is necessary that it should go in the standard. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA01673 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:55:21 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA01665 for ; Wed, 5 Nov 1997 08:55:15 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Nov 1997 16:54:41 +0000 Message-ID: <3460A433.6B605882@cs.ucl.ac.uk> Date: Wed, 05 Nov 1997 16:52:03 +0000 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: "William H. Geiger III" CC: ietf-open-pgp@imc.org Subject: Re: Just say NO to key escrow or CMR/ARR revisited References: <199711051423.JAA06679@users.invweb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have *tried* and *tried* to remain entirely non-abusive and stick to the facts here. But since you are determined to attack this position - your choice. > Oh please, this is just more bad logic on top of bad logic. Oh please, this is entirely non-substantiated irrelevant abuse. Save it for somewhere else. > Having a CMR flag in some public keys does not mean that everyone > is using CMR It does if a government mandates it. May I remind you what Barbara Simons of the ACM's US Public Policy Committee said (since it seems to have gone RIGHT over your head): > 4. The NSA states that key recovery is doable and will not jeopardize > national security. And there is an existence proof for key recovery > software in the new PGP release. > No that is not the purpose of this group. The purpose of this group is to > provide a strong message encryption standard. Well, why don't we just go with S/MIME then? That provides a strong encryption standard within the US. DOH! It allows 40-bit encryption as well. Oh well. > Debate on the technical > merits of any part of the spec is warranted, political fearmongering is > not. So, what would you describe Phil Zimmerman's speeches about human rights and encryption as? > Lets see here, you take a quote of a quote from a competitor of PGP Inc. > as a factual statement and the basis of support for your position. Sorry > you will have to do better than that. Oh sorry, I didn't realise that a direct quote from Phil by a 'competitor' of PGP's was less valid than anyone else's. And Bruce Schneier - what kind of clueless snake-oil purveyor is he? (IRONY ALERT). Let me quote Phil directly, from pgpdoc1. Is that OK? > Most alarming of all is the White House's bold new encryption policy > initiative, under development at NSA since the start of the Bush > administration, and unveiled April 16th, 1993. The centerpiece of this > initiative is a Government-built encryption device, called the Clipper > chip, containing a new classified NSA encryption algorithm. The Government > is encouraging private industry to design it into all their secure > communication products, like secure phones, secure FAX, > etc. AT&T is now putting the Clipper into their secure voice products. > The catch: At the time of manufacture, each Clipper chip will be loaded with > its own unique key, and the Government gets to keep a copy, placed in escrow. > Not to worry, though -- the Government promises that they will use these keys > to read your traffic only when duly authorized by law. Of course, to make > Clipper completely effective, the next logical step would be to outlaw other > forms of cryptography. Oh I'm sorry. Was that political fearmongering? Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA01601 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:52:45 -0800 (PST) Received: from sniff.iway.nl (sniff.iway.nl [193.78.30.251]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA01597 for ; Wed, 5 Nov 1997 08:52:41 -0800 (PST) Received: from hayek.guvnet (iang@wildgoose [192.168.1.7]) by sniff.iway.nl (8.7.5/8.7.3) with SMTP id TAA01036; Wed, 5 Nov 1997 19:25:24 +0100 (MET) Message-ID: <3460A441.6E9DAAD9@systemics.com> Date: Wed, 05 Nov 1997 16:52:17 +0000 From: Ian Grigg Organization: Systemics X-Mailer: Mozilla 3.01Gold (X11; I; FreeBSD 2.2.2-RELEASE i386) MIME-Version: 1.0 To: Lutz Donnerhacke CC: ietf-open-pgp@imc.org Subject: Re: Next draft References: <199711051423.JAA06679@users.invweb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Lutz Donnerhacke wrote: > Next draft may be come out by the end of this week. Thx Jon. I think that we all would agree that the current lack of an open draft on which to work on is debilitating to the group, to the extent of dysfunctionality. I would commend Lutz for efforts to bring the draft to the open forum. If indeed it is the intention of the editor to release the draft by the end of the week, then perhaps we could call a truce in hostilities until it is presented. Then, we could resume group activity on the basis of working on the draft. -- iang systemics.com FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA01552 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:50:56 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA01548 for ; Wed, 5 Nov 1997 08:50:52 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id IAA26670 for ietf-open-pgp@imc.org; Wed, 5 Nov 1997 08:49:26 -0800 Message-ID: <19971105084923.41715@songbird.com> Date: Wed, 5 Nov 1997 08:49:23 -0800 From: Kent Crispin To: IETF OpenPGP Subject: Re: Just say NO to key escrow or CMR/ARR revisited References: <345F8D67.160D39D@cs.ucl.ac.uk> <19971104192814.04659@songbird.com> <346040BE.CC04D7C0@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <346040BE.CC04D7C0@cs.ucl.ac.uk>; from Ian Brown on Wed, Nov 05, 1997 at 09:47:42AM +0000 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Wed, Nov 05, 1997 at 09:47:42AM +0000, Ian Brown wrote: > > A completely bogus crux. In *both cases* we are talking about > > encrypted email. Therefore, in both cases we are talking about data > > sent across an insecure network. Therefore, in both cases the FBI has > > access to the ciphertext. In either case, data that doesn't get sent > > across an insecure network is not the issue. > > > > Forward secrecy in email is an orthogonal issue to CMR/key escrow. > > Forward secrecy in email is orthogonal to this post. > > In a CMR scheme, with a mandated government recipient, the ciphertext is > sent across an insecure network. There it can be intercepted and read by > any interested TLA. > > In an escrow scheme - with escrow of either decryption keys or > ciphertext encrypted to a company/FBI key *inside an organisation* - > ciphertext *outside* the organisation is not encrypted to anyone except > the recipient. It can be intercepted but not read. > > > You are not making any sense here. CMR doesn't automatically give > > keys to anyone. > > No, I didn't say that. With a mandated government recipient, no keys > need to be handed over. The ciphertext can be read as is. The usual rule of thumb is that you should compare oranges and oranges. With mandated escrow of all keys to the FBI the ciphertext can be read as is, just as well. Neither CMR nor CKE say anything about "mandated government access". Either of them can be perverted by requiring it. And either such perversion would require a huge infrastructure of some sort or another. Personally, I prefer CKE to CMR, because after you filter out all the FUD there actually is a serious and real problem here: organizational management of large numbers of keys. CKE more directly addresses this problem. CMR merely puts off the problem a while. It is my belief that *any* solution to this problem can be perverted by governments, as well. That's unfortunate, but it doesn't make the problem go away. As being online becomes more and more important and common, large organizations need to use encryption for organizational security. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA01299 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:41:10 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA01294 for ; Wed, 5 Nov 1997 08:41:05 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id RAA23361; Wed, 5 Nov 1997 17:40:57 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Everything discussed? Date: 5 Nov 1997 16:40:57 GMT Organization: IKS GmbH Jena Lines: 10 Message-ID: References: <199711051535.PAA05243@server.test.net> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Adam Back wrote: >Perhaps our IETF chairperson could help conduct a civilised discussion >of this question whilst we are waiting for the draft. There seems to >be agreement on the MUST/SHOULD/MAY status of various ciphers, and >nothing much else to discuss in the interim. I don't believe this. There are several open questions. I.e. what's with the empty line of an armor header, if armor headers do not exist at all? Other open questions (for me) are: Key usage, Group keys, UserID expiration vs. Key expiration.... (you all know my list). Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA00998 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:31:27 -0800 (PST) Received: from basement.replay.com (basement.replay.com [194.109.9.44]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA00993 for ; Wed, 5 Nov 1997 08:31:20 -0800 (PST) Received: (from replay@localhost) by basement.replay.com (8.8.5/RePlay, Inc.) id RAA13546 for ietf-open-pgp@imc.org; Wed, 5 Nov 1997 17:31:14 +0100 (MET) Date: Wed, 5 Nov 1997 17:31:14 +0100 (MET) Message-Id: <199711051631.RAA13546@basement.replay.com> To: ietf-open-pgp@imc.org From: nobody@REPLAY.COM (Anonymous) Organization: Replay and Company UnLimited X-001: Replay may or may not approve of the content of this posting X-002: Report misuse of this automated service to X-URL: http://www.replay.com/remailer/ In-reply-to: <01BCE9CF.8FC53760.darrylr@iglou.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Darryl Rowe getting with the spirit of Open Standards writes: > > IMO, Phil/PGP should simply present the standard to IETF for > review, make any modifications, resubmit and so on a couple more > times and present a finished product. Yeah, right on! They write it, we rubber stamp it without question. Then they can advertise it as "IETF approved standard". Sheesh. Come to think of it why even bother with IETF standards, that would dispense with inconveniences like having security flaws like CMR exposed for what they are. > Though W. Geiger, Jon and a couple others are signalling quite well, On the topic of CMR? You're kidding, right? > others have an enhanced noise level which seems to be subverting any > progress while others (i.e. RSA) manage to get their PR licks in on > other fronts. (Wonder if any posters are RSA stooges ...?) Not that I noticed... but one wonders about PGP stooges... are you a PGP stooge? - An OpenPGP list member who is getting increasingly pissed off with certain "PGP only is allowed to speak" attitudes around here Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA00548 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:13:52 -0800 (PST) Received: from switcheng.mci.com (lase-switcheng.ns.mci.com [166.35.210.39]) by mail.proper.com (8.8.7/8.7.3) with SMTP id IAA00543 for ; Wed, 5 Nov 1997 08:13:46 -0800 (PST) Received: from pop4200.switcheng.mci.com by switcheng.mci.com with smtp (Smail3.1.29.1 #1) id m0xT820-0008tLC; Wed, 5 Nov 97 10:10 CST Message-Id: <3.0.2.32.19971105091040.006ada84@postoffice.switcheng.mci.com> X-Sender: dhayes@postoffice.switcheng.mci.com X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.2 (32) Date: Wed, 05 Nov 1997 09:10:40 -0600 To: "William H. Geiger III" , ietf-open-pgp@imc.org From: David Hayes Subject: Re: Just say NO to key escrow or CMR/ARR revisited In-Reply-To: <199711051309.IAA05987@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 06:53 AM 11/5/97 -0600, William H. Geiger III wrote: >Plain and simple with or without CMR if the government is going to pass >laws requiring that all messages be encrypted with a government key then >you are f**ked, plain and simple. Your statement supposes that _the_ (singular) government will do this. In fact, there are many governments in the world. Some of them already have draconian laws, some have rejected them, and many are still sitting on the fence. >Debating what should or should not be in the Open-PGP specs based on what >law some government may or may not pass in the future does not have a >place here. But it does. The world's governments must be lumped together as "adversaries". From the point of view of a message sender, a government is a well-funded, determined, but unauthorized recipient. PGP is supposed to protect our information from adversaries, even democratically elected adversaries. It would be better NOT to have features which are easily abusable by adversaries, even if those features have some legitimate use. Certainly such features should not be REQUIRED elements of a standard. That's where I think the OpenPGP standard, a protocol document, ends. The rest is implementation choice. My implementation choice is that GAK/GMR should be a high-profile feature. I would prefer that other non-GAK/GMR implementations actively refuse to cooperate with a GAK program. Thus, using GAK means cutting one's self off from the rest of the non-GAK world. If the US government wants to require GAK or GMR, they will. But it should be very painful to crypto's users, so they can't just let it slip by unnoticed. -- David Hayes David.Hayes@MCI.Com Switch Systems Engineering voice: 972-918-7236 MCI Communications, Inc. VNET: 777-7236 --If these thoughts were MCI's official opinions, the line above would --read "MCI - Law & Public Policy Department". Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id IAA00312 for ietf-open-pgp-bks; Wed, 5 Nov 1997 08:04:41 -0800 (PST) Received: from sirius.infonex.com (sirius.infonex.com [206.170.114.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id IAA00306 for ; Wed, 5 Nov 1997 08:04:36 -0800 (PST) Received: (from nobody@localhost) by sirius.infonex.com (8.8.8/8.7.3) id IAA08771; Wed, 5 Nov 1997 08:04:30 -0800 (PST) Date: Wed, 5 Nov 1997 08:04:30 -0800 (PST) From: mark@unicorn.com To: ietf-open-pgp@imc.org Message-Id: <878745869.8770.193.133.230.33@unicorn.com> Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William H. Geiger III [whgiii@invweb.net] wrote: >well you are missing a step or two here: >1st everyone overseas must be using CMR. >2nd that software must force the user to encrypt to the GMR key. This is precisely the point we're making. If CMR goes into the Open PGP spec then this will happen *automatically* with any compliant application which receives a GMR key from abroad. I have no great problem with defining the neccesary flags and tags as 'implementation defined' so that non-CMR applications won't barf when they see them, but I certainly do not want to have to build snoopware into my applications in order to comply with the standard. >The purpose of this group is to >provide a strong message encryption standard. Good; so let's create that standard and leave snoopware, message recovery and key escrow to individual implementors. Mark Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA29614 for ietf-open-pgp-bks; Wed, 5 Nov 1997 07:37:08 -0800 (PST) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.7/8.7.3) with SMTP id HAA29597 for ; Wed, 5 Nov 1997 07:37:00 -0800 (PST) Received: from aba@p15-heron-gui.tch.virgin.net [194.168.65.75] by exub via ESMTP (PAA21805); Wed, 5 Nov 1997 15:36:36 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id PAA05243; Wed, 5 Nov 1997 15:35:10 GMT Date: Wed, 5 Nov 1997 15:35:10 GMT Message-Id: <199711051535.PAA05243@server.test.net> From: Adam Back To: I.Brown@cs.ucl.ac.uk CC: whgiii@invweb.net, ietf-open-pgp@imc.org In-reply-to: <346072BB.80BAD889@cs.ucl.ac.uk> (message from Ian Brown on Wed, 05 Nov 1997 13:20:59 +0000) Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ian Brown writes: > > Debating what should or should not be in the Open-PGP specs based on what > > law some government may or may not pass in the future does not have a > > place here. !! > Au contraire. The overall aim of this exercise is (at least, I used to > think) to improve everyone's privacy and prevent Big Brother taking > over. To quote Phil Zimmerman: > > > "It's poor civic hygene to install technologies that may someday > > facilitate a police state." > > [Source: Bruce Schneier] > > I would say a central principle of Open PGP design should be that we do > not do this. Perhaps people would get the picture better if the NSA or NIST were to join in this standardisation process, and ask for support for Lotus notes like backdoors. (Some of message key bits sent to CMR/GMR key belonging to NSA resulting in 40 bits for NSA to break, and more bits for everyone else to break) If the NSA tried to put this in the standard there would be uproar. If IBM, or TIS tried it also. Because it is PGP Inc is trying CMR people's reasoning abilities kick out "It can't be bad... PGP Inc are doing it". "You don't understand it's very privacy respecting". Sheesh. To the people who will jump in and say this post is off topic, it is _not_ off topic. CMR is poor design, and we are presenting the case for why it should be either removed out right, or at least phased out... Security-wise: CMR is crap. It is a security risk. We've gone over and over the risks of CMR and of simple obvious ways to reduce those risks. PGP Inc are having situations where 2, 3, 4 or even more long term keys will be able to decrypt traffic for all time. Attackers can easily archive email as it goes over the Internet. Ergonomics-wise: CMR is crap. You can't recover from forgotten passwords gracefully -- you've got to re-encrypt everything with the employees new key. I predict companies will use local escrow AND CMR if this persists, and this is doubly dangerous because they'll escrow the signature keys, and personal use keys too. Politically: The brand name "PGP" has certain reputation behind it. Lots of people have helped to give that brand name value. We don't want it associated with CMR/GMR techniques. Those who want CMR in the standard had better start making a good case for why that is necessary, and what advantages it has. I can't see that it has _any_. Perhaps our IETF chairperson could help conduct a civilised discussion of this question whilst we are waiting for the draft. There seems to be agreement on the MUST/SHOULD/MAY status of various ciphers, and nothing much else to discuss in the interim. Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA29557 for ietf-open-pgp-bks; Wed, 5 Nov 1997 07:35:12 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA29553 for ; Wed, 5 Nov 1997 07:35:08 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id KAA11522; Wed, 5 Nov 1997 10:34:55 -0500 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id KAA09532; Wed, 5 Nov 1997 10:34:54 -0500 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA42860; Wed, 5 Nov 1997 10:34:54 -0500 From: Uri Blumenthal Message-Id: <9711051534.AA42860@watpub1.watson.ibm.com> Subject: Re: Ballot result: Element vs Packet To: Ned.Freed@innosoft.com (Ned Freed) Date: Wed, 5 Nov 1997 10:34:53 -0500 (EST) Cc: ietf-open-pgp@imc.org In-Reply-To: <01IPMJO0SPLU9JEXJ2@INNOSOFT.COM> from "Ned Freed" at Nov 4, 97 08:19:15 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Ned Freed says: > ........I see what appears to be a modified version of this posted by > Lutz to the list (which isn't the correct thing to do with drafts, BTW)... Ned, I take exception to this. In my NSH opinion, it is poerfectly OK to circulate the drafts on the list until they're ready to be submitted to the RFC editor (and that indeed is how several WGs do their job). No disagreement with the rest though. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id HAA29114 for ietf-open-pgp-bks; Wed, 5 Nov 1997 07:13:06 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id HAA29100 for ; Wed, 5 Nov 1997 07:12:40 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id QAA21299; Wed, 5 Nov 1997 16:12:24 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Next draft Date: 5 Nov 1997 15:12:18 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: References: <199711051423.JAA06679@users.invweb.net> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * William H. Geiger III wrote: >Well I will wait until the official draft is made available and then make >my judgement on the technical merits of the proposal. The political >fearmongering can be left for other lists. Next draft may be come out by the end of this week. Thx Jon. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA28676 for ietf-open-pgp-bks; Wed, 5 Nov 1997 06:45:57 -0800 (PST) Received: from iglou2 (exim@iglou2.iglou.com [192.107.41.17]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA28672 for ; Wed, 5 Nov 1997 06:45:53 -0800 (PST) Received: from darrylr [204.255.233.239] by iglou2 with smtp (8.7.3/8.6.12) id 0xT6iJ-0004SZ-00; Wed, 5 Nov 1997 09:45:48 -0500 Received: by localhost with Microsoft MAPI; Wed, 5 Nov 1997 09:45:33 -0500 Message-ID: <01BCE9CF.8FC53760.darrylr@iglou.com> From: "Darryl L. Rowe" Reply-To: "darrylr@iglou.com" To: "ietf-open-pgp@imc.org" Subject: Management by Committee ... Date: Wed, 5 Nov 1997 09:45:32 -0500 Organization: Vocational Economics, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- IMO, Phil/PGP should simply present the standard to IETF for review, make any modifications, resubmit and so on a couple more times and present a finished product. This group simply illustrates to me the fundamental rule that to really screw things up requires a committee. Though W. Geiger, Jon and a couple others are signalling quite well, others have an enhanced noise level which seems to be subverting any progress while others (i.e. RSA) manage to get their PR licks in on other fronts. (Wonder if any posters are RSA stooges ...?) On Wednesday, November 05, 1997 7:54 AM, William H. Geiger III [SMTP:whgiii@invweb.net] wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > In <346040BE.CC04D7C0@cs.ucl.ac.uk>, on 11/05/97 > at 04:47 AM, Ian Brown said: > > >-----BEGIN PGP SIGNED MESSAGE----- > > >> A completely bogus crux. In *both cases* we are talking about > >> encrypted email. Therefore, in both cases we are talking about > >> data > >> sent across an insecure network. Therefore, in both cases the > >> FBI has > >> access to the ciphertext. In either case, data that doesn't get > >> sent > >> across an insecure network is not the issue. > >> > >> Forward secrecy in email is an orthogonal issue to CMR/key > >> escrow. > > >Forward secrecy in email is orthogonal to this post. > > >In a CMR scheme, with a mandated government recipient, the > >ciphertext is > >sent across an insecure network. There it can be intercepted and > >read by > >any interested TLA. > > >In an escrow scheme - with escrow of either decryption keys or > >ciphertext > >encrypted to a company/FBI key *inside an organisation* - > >ciphertext *outside* the organisation is not encrypted to anyone > >except > >the recipient. It can be intercepted but not read. > > >> You are not making any sense here. CMR doesn't automatically > >> give > >> keys to anyone. > > >No, I didn't say that. With a mandated government recipient, no > >keys need > >to be handed over. The ciphertext can be read as is. > > > This argument against CMR is getting old and is as flawed as when it > was > first brought up. :( > > Plain and simple with or without CMR if the government is going to > pass > laws requiring that all messages be encrypted with a government key > then > you are f**ked, plain and simple. CMR is not required for them to do > it, > plain old PGP 2.6 will work just as well. If they are going to > start > passing draconian laws in regards to encryption nothing done here > will be > of any importance as they will outlaw anything that does not > conform > (volentary GAK will never work and they know it). > > Debating what should or should not be in the Open-PGP specs based on > what > law some government may or may not pass in the future does not have > a > place here. I propose that the FBI/CIA/NSA ...et al will get laws > passed > banning the use of all crypto therefore we should drop everything > pack our > bags and go on home. > > - -- > - ------------------------------------------------------------- - -- > William H. Geiger III http://users.invweb.net/~whgiii > Geiger Consulting Cooking With Warp 4.0 > > Author of E-Secure - PGP Front End for MR/2 Ice > PGP & MR/2 the only way for secure e-mail. > OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html > > - ------------------------------------------------------------- - -- > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.3a > Charset: cp850 > Comment: Registered_User_E-Secure_v1.1b1_ES000000 > > iQCVAwUBNGBvYY9Co1n+aLhhAQHCOQP+MP2lwXtizpaPcg2N5nxMx8qO4WvjILIR > LOS28FasDwTkT3dkgSUYP971m6BcwsdUmWr13P7aKDMb7E6UUC3rC9ax24qzeCFf > obadn0TrqWiCw9/VfKR9FvuxhxeYUF+KkiTE5JybVh1P4GQTyJXNmWtmLyBI/L -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQEVAwUBNGCGiw/p7jvmPnflAQEtBgf/WzRfVMSAQZ/lh4r0XI1n1UpFDU/iJIck 98KNECbRthWGXECVEzHHJsXappLXA2fp8PdW7Fz79JJfZxt93p4dTmMvzITbyerU M/SE/JCeVDm70fgIt2iKT9zuC8c/qzNjvoc5NX3ie/AzIDP09KOCGU0CKYaO+Ne5 UH/eumUt4uRyKYhgoSCdJaw+vP5vpTvhtzyffbroWJTEWp366DAPkfuyCpF7maof OQ+D/bTl/a9nd9PMIAKLVrMVt/1jqiIYNmg/9i4y/cCdkRPJ/6dFzdtA7pwQA1S9 TZUlVmIQiCLRCuoupzJmhwamq+0PqZfd5UEhpW4YXBqCNPdWotAtEA== =DarX -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA28293 for ietf-open-pgp-bks; Wed, 5 Nov 1997 06:23:31 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA28288 for ; Wed, 5 Nov 1997 06:23:22 -0800 (PST) Received: from users.invweb.net (cppp27.dotstar.net [208.143.93.127]) by users.invweb.net (8.8.7/8.8.7) with SMTP id JAA06679 for ; Wed, 5 Nov 1997 09:23:10 -0500 Message-Id: <199711051423.JAA06679@users.invweb.net> From: "William H. Geiger III" Date: Wed, 05 Nov 97 08:20:09 -0600 Subject: Re: Just say NO to key escrow or CMR/ARR revisited X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: I.Brown@cs.ucl.ac.uk,whgiii@invweb.net,ietf-open-pgp@imc.org To: ietf-open-pgp@imc.org X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <346072BB.80BAD889@cs.ucl.ac.uk>, on 11/05/97 at 08:20 AM, Ian Brown said: >> Plain and simple with or without CMR if the government is going to pass >> laws requiring that all messages be encrypted with a government key then >> you are f**ked, plain and simple. CMR is not required for them to do it, >> plain old PGP 2.6 will work just as well. If they are going to start >> passing draconian laws in regards to encryption nothing done here will be >> of any importance as they will outlaw anything that does not conform >> (volentary GAK will never work and they know it). >The WHOLE POINT is that we don't want to make it any easier for any >government to impose such laws. If CMR becomes widespread, it is very >easy for a government to pass a law saying "This GMR key must be used as >a recipient on all messages". If everyone is using CMR already, few >people will see this as particularly controversial. Oh please, this is just more bad logic on top of bad logic. Having a CMR flag in some public keys does not mean that everyone is using CMR let alone support your position that this somehow conditions the public to support GMR. You have failed to show that having a CMR flag leads to everyone using CMR which leads to the government mandating GMR which leads to everyone accepting GMR. The only leg you have to stand on is the fearmongering the the government somehow someway might in the future pass some law to abuse CMR. My point is that if they are going down this route they don't need CMR to do it and CMR does not in any significant way aid them in this effort. >Even worse, it allows >governments to force such schemes on other countries without such laws. >If the US passed such a law, all US citizens' keys would have an ARR for >the GMR key. So if someone living in a country with more sensible >legislation sent the US citizen a message, it would still be snoopable by >the NSA. Is this what you want? well you are missing a step or two here: 1st everyone overseas must be using CMR. 2nd that software must force the user to encrypt to the GMR key. >> Debating what should or should not be in the Open-PGP specs based on what >> law some government may or may not pass in the future does not have a >> place here. >Au contraire. The overall aim of this exercise is (at least, I used to >think) to improve everyone's privacy and prevent Big Brother taking over. No that is not the purpose of this group. The purpose of this group is to provide a strong message encryption standard. Debate on the technical merits of any part of the spec is warranted, political fearmongering is not. >To quote Phil Zimmerman: >> "It's poor civic hygene to install technologies that may someday >> facilitate a police state." >[Source: Bruce Schneier] Lets see here, you take a quote of a quote from a competitor of PGP Inc. as a factual statement and the basis of support for your position. Sorry you will have to do better than that. >I would say a central principle of Open PGP design should be that we do >not do this. Well I will wait until the official draft is made available and then make my judgement on the technical merits of the proposal. The political fearmongering can be left for other lists. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGCAo49Co1n+aLhhAQHrUgP/fOUMLKW8sDTIEGOWS4ikDUGQLIPbtkJ5 Ns2fUvEqoOUH2+zzPeC/KKHiyLB4aVQHT+mQULkcvV4Sts6cnXUENWwBL3DR20Q0 OU2Gf80wNErmzwKgn0L82L1oQkx3ZsfVWDg8kf7shbV1nk8aYlzRO/x1ukprZ+lt 5x7kf8KHIFU= =ArcL -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA27579 for ietf-open-pgp-bks; Wed, 5 Nov 1997 05:26:14 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id FAA27574 for ; Wed, 5 Nov 1997 05:26:10 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Nov 1997 13:23:33 +0000 Message-ID: <346072BB.80BAD889@cs.ucl.ac.uk> Date: Wed, 05 Nov 1997 13:20:59 +0000 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: "William H. Geiger III" , IETF OpenPGP Subject: Re: Just say NO to key escrow or CMR/ARR revisited References: <199711051309.IAA05991@users.invweb.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Plain and simple with or without CMR if the government is going to pass > laws requiring that all messages be encrypted with a government key then > you are f**ked, plain and simple. CMR is not required for them to do it, > plain old PGP 2.6 will work just as well. If they are going to start > passing draconian laws in regards to encryption nothing done here will be > of any importance as they will outlaw anything that does not conform > (volentary GAK will never work and they know it). The WHOLE POINT is that we don't want to make it any easier for any government to impose such laws. If CMR becomes widespread, it is very easy for a government to pass a law saying "This GMR key must be used as a recipient on all messages". If everyone is using CMR already, few people will see this as particularly controversial. Even worse, it allows governments to force such schemes on other countries without such laws. If the US passed such a law, all US citizens' keys would have an ARR for the GMR key. So if someone living in a country with more sensible legislation sent the US citizen a message, it would still be snoopable by the NSA. Is this what you want? > Debating what should or should not be in the Open-PGP specs based on what > law some government may or may not pass in the future does not have a > place here. Au contraire. The overall aim of this exercise is (at least, I used to think) to improve everyone's privacy and prevent Big Brother taking over. To quote Phil Zimmerman: > "It's poor civic hygene to install technologies that may someday > facilitate a police state." [Source: Bruce Schneier] I would say a central principle of Open PGP design should be that we do not do this. Ian. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id FAA27398 for ietf-open-pgp-bks; Wed, 5 Nov 1997 05:09:40 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id FAA27394 for ; Wed, 5 Nov 1997 05:09:36 -0800 (PST) Received: from users.invweb.net (cppp27.dotstar.net [208.143.93.127]) by users.invweb.net (8.8.7/8.8.7) with SMTP id IAA05987 for ; Wed, 5 Nov 1997 08:09:26 -0500 Message-Id: <199711051309.IAA05987@users.invweb.net> From: "William H. Geiger III" Date: Wed, 05 Nov 97 06:53:35 -0600 Subject: Re: Just say NO to key escrow or CMR/ARR revisited X-AutoCrypt: This Message AutoEncrypted With E-Secure v1.1b1 X-Distribution: I.Brown@cs.ucl.ac.uk,kent@songbird.com,ietf-open-pgp@imc.org To: ietf-open-pgp@imc.org X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <346040BE.CC04D7C0@cs.ucl.ac.uk>, on 11/05/97 at 04:47 AM, Ian Brown said: >-----BEGIN PGP SIGNED MESSAGE----- >> A completely bogus crux. In *both cases* we are talking about >> encrypted email. Therefore, in both cases we are talking about data >> sent across an insecure network. Therefore, in both cases the FBI has >> access to the ciphertext. In either case, data that doesn't get sent >> across an insecure network is not the issue. >> >> Forward secrecy in email is an orthogonal issue to CMR/key escrow. >Forward secrecy in email is orthogonal to this post. >In a CMR scheme, with a mandated government recipient, the ciphertext is >sent across an insecure network. There it can be intercepted and read by >any interested TLA. >In an escrow scheme - with escrow of either decryption keys or ciphertext >encrypted to a company/FBI key *inside an organisation* - >ciphertext *outside* the organisation is not encrypted to anyone except >the recipient. It can be intercepted but not read. >> You are not making any sense here. CMR doesn't automatically give >> keys to anyone. >No, I didn't say that. With a mandated government recipient, no keys need >to be handed over. The ciphertext can be read as is. This argument against CMR is getting old and is as flawed as when it was first brought up. :( Plain and simple with or without CMR if the government is going to pass laws requiring that all messages be encrypted with a government key then you are f**ked, plain and simple. CMR is not required for them to do it, plain old PGP 2.6 will work just as well. If they are going to start passing draconian laws in regards to encryption nothing done here will be of any importance as they will outlaw anything that does not conform (volentary GAK will never work and they know it). Debating what should or should not be in the Open-PGP specs based on what law some government may or may not pass in the future does not have a place here. I propose that the FBI/CIA/NSA ...et al will get laws passed banning the use of all crypto therefore we should drop everything pack our bags and go on home. - -- - --------------------------------------------------------------- William H. Geiger III http://users.invweb.net/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNGBvYY9Co1n+aLhhAQHCOQP+MP2lwXtizpaPcg2N5nxMx8qO4WvjILIR LOS28FasDwTkT3dkgSUYP971m6BcwsdUmWr13P7aKDMb7E6UUC3rC9ax24qzeCFf obadn0TrqWiCw9/VfKR9FvuxhxeYUF+KkiTE5JybVh1P4GQTyJXNmWtmLyBI/Lwz BcsIfFtmBI4= =R49w -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id CAA23556 for ietf-open-pgp-bks; Wed, 5 Nov 1997 02:00:00 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mail.proper.com (8.8.7/8.7.3) with SMTP id BAA23552 for ; Wed, 5 Nov 1997 01:59:53 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Nov 1997 09:50:09 +0000 Message-ID: <346040BE.CC04D7C0@cs.ucl.ac.uk> Date: Wed, 05 Nov 1997 09:47:42 +0000 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Kent Crispin , IETF OpenPGP Subject: Re: Just say NO to key escrow or CMR/ARR revisited References: <345F8D67.160D39D@cs.ucl.ac.uk> <19971104192814.04659@songbird.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > A completely bogus crux. In *both cases* we are talking about > encrypted email. Therefore, in both cases we are talking about data > sent across an insecure network. Therefore, in both cases the FBI has > access to the ciphertext. In either case, data that doesn't get sent > across an insecure network is not the issue. > > Forward secrecy in email is an orthogonal issue to CMR/key escrow. Forward secrecy in email is orthogonal to this post. In a CMR scheme, with a mandated government recipient, the ciphertext is sent across an insecure network. There it can be intercepted and read by any interested TLA. In an escrow scheme - with escrow of either decryption keys or ciphertext encrypted to a company/FBI key *inside an organisation* - ciphertext *outside* the organisation is not encrypted to anyone except the recipient. It can be intercepted but not read. > You are not making any sense here. CMR doesn't automatically give > keys to anyone. No, I didn't say that. With a mandated government recipient, no keys need to be handed over. The ciphertext can be read as is. Ian. -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.2.2 iQCVAgUBNGBAwppi0bQULdFRAQFa0gP9HHEEKHaU1gKGlj7ZZwgYg0raUURH1k+x jpZ0AkaEfIHvl+y6RfDDwEO5o4h+Iwp+Ht3XFUAZH4x8qxxYHzb/tP6kbD2OdVCX WLpQRA40c6AQSrZDnHSYgkN6wYzJxITJls0TWahPpVbmG7w7QdDMjFG/TFHG7pG0 uOJcrlQmFso= =aSVC -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id XAA21162 for ietf-open-pgp-bks; Tue, 4 Nov 1997 23:05:44 -0800 (PST) Received: from colorado.river.com (colorado.river.com [206.168.172.12]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id XAA21158 for ; Tue, 4 Nov 1997 23:05:39 -0800 (PST) Received: from poudre.river.com (206.168.172.17) by colorado.river.com with ESMTP (Eudora Internet Mail Server 1.2); Wed, 5 Nov 1997 00:05:21 -0700 Message-Id: In-Reply-To: References: <878670082.10174.193.133.230.33@unicorn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 5 Nov 1997 00:02:55 -0700 To: Gene Hoffman , mark@unicorn.com From: "Richard Johnson" Subject: Re: Just say NO to key escrow or CMR/ARR revisited Cc: ietf-open-pgp@imc.org Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:16 -0700 on 11/04/1997, Gene Hoffman wrote: > On Tue, 4 Nov 1997 mark@unicorn.com wrote: > > > At the same time, it builds a 'feature' into every copy > > of PGP which could at some point in the future be used to provide > > government access to messages by forcing users to encrypt to a government > > key. This, to Adam and others (including me), is so great a risk that > > we'd much prefer key escrow or an alternate system. > > ... > It would take the same amount of government intervention to corrupt a > corporate key escrow system as CMR. > Requiring access to plaintext via a system using either CMR (easier) or corporate key escrow (slightly harder) would probably be well within the capabilities of your average government to arrange. However, there is one crucial difference between CMR and corporate key escrow. This difference leads me strongly _away_ from any kind of system that requires (or could be abused to require) encryption of messages to 3rd party keys. Think of what the adversary who wants to abuse CMR on a large scale would have to do, vs the task facing the adversary who wants to abuse a corporate key escrow system. Compare and contrast workload: With CMR (encryption to 3rd party keys), in a likely implementation scenario, the attacker only has to require encryption of all messages to a corporate/ISP/city/county key, which they also hold or can steal, for decryption at will. With corporate key escrow, to achieve the same effect, the attacker will need to require access to or steal copies of each key. At an average of only 10,000 users per corporate/ISP/city/county "recovery" key, CMR reduces the workload and storage needs of the attacker by 4 orders of magnitude. Throw in a province-wide or regional government recovery key, and you reduce the storage needs of the attacker (not necessarily the government) by 10 orders of magnitude or more. This is a serious bottom-level security flaw with the basic CMR idea as implemented in PGP 5.5. It is too scalable, to the benefit of an attacker. Implement message recovery outside open-pgp: To achieve message recovery when necessary, corporate key escrow implemented _outside_ the open-pgp standard (on a per-application basis) is the more secure and reasonable alternative. I would thus greatly prefer that the open-pgp standard not specify any kind of encryption to 3rd party keys. Of course, there is also no need for it to specify how any kind of key escrow might be done. Let's keep open-pgp simple, and leave message recovery to each application developer who sells into markets where such features are desired. Richard Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id VAA20167 for ietf-open-pgp-bks; Tue, 4 Nov 1997 21:13:16 -0800 (PST) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id VAA20162; Tue, 4 Nov 1997 21:13:12 -0800 (PST) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IPMGFIHCK09JEXJ2@INNOSOFT.COM>; Tue, 4 Nov 1997 21:12:03 PST Date: Tue, 04 Nov 1997 20:19:15 -0800 (PST) From: Ned Freed Subject: Re: Ballot result: Element vs Packet In-reply-to: "Your message dated Tue, 04 Nov 1997 11:06:53 -0800" <3.0.3.32.19971104110653.009f02a0@mail.imc.org> To: Paul Hoffman / IMC Cc: lutz@taranis.iks-jena.de, ietf-open-pgp@imc.org Message-id: <01IPMJO0SPLU9JEXJ2@INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > I find this wholly offensive. This is an IETF Working Group, not a informal > gang of developers making a spec by brute force. > Lutz, you have previously claimed ignorance of IETF rules, and it appears > that you have not done anything to fix that ignorance. I'd like to repeat > what the WG chairperson said weeks ago: > > Lutz, let me speak more plainly. The chair will not hear further > > discussion on this issue. The chair did not call for a straw poll. There > > will be no vote on this. > Which part of that did you not understand? Paul, I agree 100%. Folks, in case you haven't figured it out, this WG is in trouble. Discussion is wandering all over the map rather than focusing on the deliverables this WG is supposed to produce. Discussions of, say, RSA press releases, is _entirely_ out of order. I am also concerned that when I look at the IETF Web page for this WG for Internet Drafts I find ... nothing. I see one formats draft from July on the IMC Web site, I see what appears to be a modified version of this posted by Lutz to the list (which isn't the correct thing to do with drafts, BTW), I have a messasge from the chair saying that he's asked the various authors to work together to get a combined draft out, and I have a message from Jon Callas saying that he's going to merge all this stuff and have a draft out RSN. This is all quite confusing. Internet drafts are an essential part of a WG's operation. Not having produced any at this point would be fine. Missing the Oct 97 schedule for a draft is of no real consequence. Having all these documents lying around in lieu of legitimate drafts, however, is not fine. This group needs to get drafts out in the proper way, develop a list of open issues in those drafts, and hammer away at the issues on the list until they are all resolved. Ned Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id TAA18882 for ietf-open-pgp-bks; Tue, 4 Nov 1997 19:29:47 -0800 (PST) Received: from songbird.com (kent@songbird.com [206.14.4.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id TAA18878 for ; Tue, 4 Nov 1997 19:29:43 -0800 (PST) Received: (from kent@localhost) by songbird.com (8.8.4/8.7.3) id TAA19451 for ietf-open-pgp@imc.org; Tue, 4 Nov 1997 19:28:17 -0800 Message-ID: <19971104192814.04659@songbird.com> Date: Tue, 4 Nov 1997 19:28:14 -0800 From: Kent Crispin To: ietf-open-pgp@imc.org Subject: Re: Just say NO to key escrow or CMR/ARR revisited References: <345F8D67.160D39D@cs.ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <345F8D67.160D39D@cs.ucl.ac.uk>; from Ian Brown on Tue, Nov 04, 1997 at 09:02:31PM +0000 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, Nov 04, 1997 at 09:02:31PM +0000, Ian Brown wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > Building a key escrow system would do exactly the same thing. Putting in > > place the infrastructure for automated enterprise wide key escrow to a > > corporate key would mean building a technology infrastructure at exactly > > the same risk. A government could just as easily say, "Thou shalt escrow > > to the FBI key and send it to central storage" as they could corrupt CMR > > to say "Thou shalt encrypt to the FBI key." > > I'm not sure what you mean by 'central storage'. If you mean a backup > server within an organisation, this means the FBI still has to gain > physical access to the encrypted data. With CMR, the data is likely to > be sent across an insecure network so the FBI could access it easily. > > This is the crux of the argument. A completely bogus crux. In *both cases* we are talking about encrypted email. Therefore, in both cases we are talking about data sent across an insecure network. Therefore, in both cases the FBI has access to the ciphertext. In either case, data that doesn't get sent across an insecure network is not the issue. Forward secrecy in email is an orthogonal issue to CMR/key escrow. [...] > A properly designed escrow system > would require the keys to be physically handed over by the organisation > to the NSA. Regardless of how easy this step may be, it would hinder > fishing and leave some kind of audit trail - unlike CMR. You are not making any sense here. CMR doesn't automatically give keys to anyone. -- Kent Crispin "No reason to get excited", kent@songbird.com the thief he kindly spoke... PGP fingerprint: B1 8B 72 ED 55 21 5E 44 61 F4 58 0F 72 10 65 55 http://songbird.com/kent/pgp_key.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA15411 for ietf-open-pgp-bks; Tue, 4 Nov 1997 15:04:24 -0800 (PST) Received: from gatekeeper.mcimail.com (gatekeeper.mcimail.com [192.147.45.5]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA15404 for ; Tue, 4 Nov 1997 15:04:18 -0800 (PST) Received: from mcimail.com ([166.40.135.57]) by gatekeeper.mcimail.com (8.6.12/8.6.10) with ESMTP id XAA03565; Tue, 4 Nov 1997 23:03:37 GMT Received: from mcimail.com by DGN0IG.mcimail.com (PMDF V5.1-8 #24741) id <01IPMNQ5XUIGANBSIW@DGN0IG.mcimail.com>; Tue, 4 Nov 1997 23:08:18 GMT Date: Tue, 04 Nov 1997 18:03:32 -0500 (EST) From: Jeffrey Gold <0002595870@MCIMAIL.COM> Subject: Regulation: Self-Imposed or Goverment Mandated To: pgp-users , ietf-open-pgp Message-id: <01IPMNQ5XUIIANBSIW@DGN0IG.mcimail.com> X-Mailer: MailRoom for MCI Mail v3.3c (www.SierraSol.com/SierraSol) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I have no doubt that the following is meant to apply to PGP and other crypto-methods, both inside and eventually outside the United States. Any suggestions? Or, should it be ignored until it is mandated? ___________________________________________________________ CYBERSPACE REGULATION: DO IT YOURSELF OR HAVE IT DONE TO YOU In a speech to advertisers, Ira Magaziner, the Clinton administration's advisor on Internet issues, said: "The tremendous economic benefits of the Internet will not work if we don't get efficient industry self-regulation on issues like privacy and content, especially in the children's area. If you fail, we will have to go the legislative route. That gets caught up in the political process and will be less rational and efficient." (New York Times Cybertimes 4 Nov 97) ___________________________________________________________ Unfortunately, access to the New York Times Cybertimes outside the United States requires a paid-subscription. Reference: http://www.nytimes.com/library/cyber/week/110497magaziner.html Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA13667 for ietf-open-pgp-bks; Tue, 4 Nov 1997 13:38:50 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA13662 for ; Tue, 4 Nov 1997 13:38:44 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id NAA28442; Tue, 4 Nov 1997 13:37:47 -0800 (PST) Message-Id: <3.0.3.32.19971104133811.00a99160@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 04 Nov 1997 13:38:11 -0800 To: Adam Back , hoffmang@pgp.com From: Jon Callas Subject: Re: Just say NO to key escrow or CMR/ARR revisited Cc: mark@unicorn.com, ietf-open-pgp@imc.org In-Reply-To: <199711042050.UAA02374@server.test.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 08:50 PM 11/4/97 GMT, Adam Back wrote: Jon Callas stated earlier that some pgp 5.0 for business customers were already escrowing keys (signature keys included ouch!) All that needs to be done to fix this is to provide a menu option to copy backups of only company use encryption keys to floppy (presumably encrypted to a selected company escrow key). Just for the record, I didn't say what version they're using. They are pre-V5 customers. Probably 4.0 or 4.5, but I can't remember. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA13489 for ietf-open-pgp-bks; Tue, 4 Nov 1997 13:27:41 -0800 (PST) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA13485 for ; Tue, 4 Nov 1997 13:27:35 -0800 (PST) Received: from aba@p56-quail-gui.tch.virgin.net [194.168.69.56] by exub via ESMTP (VAA20937); Tue, 4 Nov 1997 21:26:15 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id UAA02374; Tue, 4 Nov 1997 20:50:21 GMT Date: Tue, 4 Nov 1997 20:50:21 GMT Message-Id: <199711042050.UAA02374@server.test.net> From: Adam Back To: hoffmang@pgp.com CC: mark@unicorn.com, ietf-open-pgp@imc.org Cc: andrada@earthlink.net In-reply-to: (message from Gene Hoffman on Tue, 4 Nov 1997 11:16:41 -0800 (PST)) Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Gene Hoffman writes: > On Tue, 4 Nov 1997 mark@unicorn.com wrote: > > > At the same time, it builds a 'feature' into every copy > > of PGP which could at some point in the future be used to provide > > government access to messages by forcing users to encrypt to a government > > key. This, to Adam and others (including me), is so great a risk that > > we'd much prefer key escrow or an alternate system. > > Building a key escrow system would do exactly the same thing. Putting in > place the infrastructure for automated enterprise wide key escrow to a > corporate key would mean building a technology infrastructure at exactly > the same risk. Jon Callas stated earlier that some pgp 5.0 for business customers were already escrowing keys (signature keys included ouch!) All that needs to be done to fix this is to provide a menu option to copy backups of only company use encryption keys to floppy (presumably encrypted to a selected company escrow key). This could be implemented by PGP Inc or other vendors outside of the OpenPGP standard. An international standard which includes support for message recovery (CMR) is dangerous. All you would have done with the local recovery system I discuss above is to minimize the risks of forgery inherent in escrowing signature keys. All you would be doing is building support for what companies will do anyway. You can minimise privacy risks by providing a personal use encryption subkey which is not escrowed by this operation. Even with CMR companies will probably escrow keys because the ergonomics of recovering from lost passwords with CMR are poor (re-encrypt all encrypted files on disk, floppy, backup tapes, etc). Users frequently forget passwords (as unix sysadmins will confirm). I suspect CMR will get you many tech support calls at PGP -- user's forgotten password, are you seriously telling us we've got to re-encryt all this data (megabytes scattered over write once CDs, tapes, harddisk, floppies, inside .ZIP archives etc). Not pretty. > A government could just as easily say, "Thou shalt escrow to the FBI > key and send it to central storage" as they could corrupt CMR to say > "Thou shalt encrypt to the FBI key." They could indeed do this. However local escrow is harder to abuse than CMR because: - it is logistically harder to organise collection of millions of keys than it is to publish one NSA owned key - especially when companies use different techniques locally Mark's point that CMR builds a feature which can be used for escrow into every copy of PGP is also good. He's referring to the fact that all versions of pgp5.x to date (pgp5.0, and pgp5.5 for both personal and company use) include support to make it easy for users to comply with demands for escrow. For example, say you are using pgp5.0 for personal use in the US, and you get a message from a French user where the French government have installed mandatory CMR (I suppose that would be GMR), with the master CMR key held by SCSSI. pgp5.0 helps you to comply with that request, and the CMR design simplifies the French governments task. If the French government wants to escrow user keys, let them work out the logistics of collecting all their citizens keys themselves without any help from PGP, or the OpenPGP standard. If you want bonus crypto-anarchic brownie points build forward secret transport level security -- that'll slow down governments. > Corporations are going to want central, encrypted escrow if PGP, Inc. > were to go that way. If that is the corporations mentality I suspect they will have one single master CMR key also, and that they will turn on the strict policy enforcer flag. I also suspect they will escrow the user private keys just to ease recovery -- users forgetting passwords is common, and CMR does not allow easy recovery from this. Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Tue, 4 Nov 1997 13:06:58 -0800 (PST) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 4 Nov 1997 21:04:56 +0000 Message-ID: <345F8D67.160D39D@cs.ucl.ac.uk> Date: Tue, 04 Nov 1997 21:02:31 +0000 From: Ian Brown Organization: University College London X-Mailer: Mozilla 4.02 [en] (WinNT; U) MIME-Version: 1.0 To: Gene Hoffman CC: mark@unicorn.com, ietf-open-pgp@imc.org Subject: Re: Just say NO to key escrow or CMR/ARR revisited References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- > Building a key escrow system would do exactly the same thing. Putting in > place the infrastructure for automated enterprise wide key escrow to a > corporate key would mean building a technology infrastructure at exactly > the same risk. A government could just as easily say, "Thou shalt escrow > to the FBI key and send it to central storage" as they could corrupt CMR > to say "Thou shalt encrypt to the FBI key." I'm not sure what you mean by 'central storage'. If you mean a backup server within an organisation, this means the FBI still has to gain physical access to the encrypted data. With CMR, the data is likely to be sent across an insecure network so the FBI could access it easily. This is the crux of the argument. CMR could enable widespread fishing by surveillance agencies; they already have access to the ciphertext (which would also be encrypted to their key). A properly designed escrow system would require the keys to be physically handed over by the organisation to the NSA. Regardless of how easy this step may be, it would hinder fishing and leave some kind of audit trail - unlike CMR. Ian. -----BEGIN PGP SIGNATURE----- Version: Cryptix 2.2.2 iQCVAgUBNF+Na5pi0bQULdFRAQHWqgP/SK4v+/oAUxWEzdIgXDP7T52qyMjqROUQ Lmfl6qf8dEfkmeGQl6mCuBYvDIOWYftj0IvehrHMOWg3erPuGCq+rASB1iKKfYvJ 0K/G4k04EhfnRCd+96Fqh64U3NWnxaV1LGK21+MLL8iRt6OF5fbkarrfA9sx0eCZ /9DHGBM+tSw= =XRln -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA13027 for ietf-open-pgp-bks; Tue, 4 Nov 1997 12:56:16 -0800 (PST) Received: from public.uni-hamburg.de (public.uni-hamburg.de [134.100.41.1]) by mail.proper.com (8.8.7/8.7.3) with SMTP id MAA13022 for ; Tue, 4 Nov 1997 12:56:11 -0800 (PST) Received: from max-182.public.uni-hamburg.de by public.uni-hamburg.de (AIX 4.1/UCB 5.64/4.03) id AA42364; Tue, 4 Nov 1997 21:56:03 +0100 Received: by ulf.mali.sub.org (Smail3.1.28.1 #1) id m0xSiD1-0003bQC; Tue, 4 Nov 97 13:35 GMT+0100 Message-Id: Date: Tue, 4 Nov 97 13:35 GMT+0100 From: Bodo_Moeller@public.uni-hamburg.de (Bodo Moeller) To: ietf-open-pgp@imc.org Subject: Re: What this WG is doing In-Reply-To: <3.0.3.32.19971030034250.006f94d8@popd.ix.netcom.com> Organization: =?ISO-8859-1?B?SW5zdGl0dXQgPT9JU08tODg1OS0xP1E/Zj1GQ3JfdmVyc2Nodz1GNnJ1bmdzdGhlb3JldGlzY2hlPz0gSW5mb3JtYXRpaw==?= Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Bill Stewart : > A program receiving a CMRK can do several things > 0) Be confused and crash when receiving public key records > containing CMRKs :-) > 1) Reject public key records containing CMRKs and complain to the user > 2) Ignore the CMRK and process the main key, though you need to record > the CMRK in the public key database since it's part of the signatures. > 3) Ask the user whether to encrypt a copy to the CMRK, if there's a user > 4) Ask the user, who's not there to respond to a dialog box, and hang > 5) Cooperate with the request, doing something appropriate if you > need to fetch the key matching the CMRK KeyID. > 6) Implement some totally different functionality using that field > 7) Obey Blindly There is one more option. For every public key encryption, the sender also has the option of sending garbage (in the case of RSA, a random number in the interval 1 .. N_key - 1; in the case of ElGamal, two random numbers in the interval 1 .. p_key - 1) instead of real data. Only with the appropriate private key is it possible to find out that the "encrypted data" does not make any sense. This feature is (AFAIK) not available in any version of PGP, up so far. But I always thought the user should have the possibility to 1. add recipients to public key encrypted messages (provided that he can decrypt the message himself), 2. add "fake recipients" in the sense explained above, 3. delete recipients. Usually, these features would have been pretty useless (although this obviously changed with the advent of PGP's e-mail filtering gateway). However, their existence would educate every PGP user that * PGP's message claiming that "This message can only be read by " does not really guarantee that all those users are in fact able to decrypt the message, and * that it also does not guarantee that the original sender chose the same list of recipients that is present in the received message. Note that options 2. and 3. above do not require the posession of a private key; i.e., they can be done by an attacker while the message is in transit. I am sure that many PGP users assume that, when PGP informs them that a message "can only be read by ...", the sender is responsible for the decision who can (apparently) read the message -- while in fact there is no authentication for that. Having features 1., 2. and 3. implemented in PGP could help to prevent that unjustified assumption. Bodo M"oller Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA12165 for ietf-open-pgp-bks; Tue, 4 Nov 1997 12:01:07 -0800 (PST) Received: from aun.uninett.no (aun.uninett.no [129.241.1.99]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA12161 for ; Tue, 4 Nov 1997 12:01:03 -0800 (PST) Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Tue, 4 Nov 1997 21:00:51 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id VAA29568; Tue, 4 Nov 1997 21:00:38 +0100 From: Harald.T.Alvestrand@uninett.no To: lutz@taranis.iks-jena.de (Lutz Donnerhacke) cc: ietf-open-pgp@imc.org Subject: Re: Ballot result: Element vs Packet In-reply-to: Your message of "04 Nov 1997 18:38:17 GMT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29564.878673637.1@dale.uninett.no> Date: Tue, 04 Nov 1997 21:00:38 +0100 Message-ID: <29566.878673638@dale.uninett.no> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk In IETF terms, a 6:9 split is usually called "no consensus". In a group with > 80 different people posting over the last few weeks, a "vote" with a turnout of 17 is called a failure. Harald A Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11659 for ietf-open-pgp-bks; Tue, 4 Nov 1997 11:29:16 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11654 for ; Tue, 4 Nov 1997 11:29:10 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id UAA26173; Tue, 4 Nov 1997 20:29:01 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Ballot result: Element vs Packet Date: 4 Nov 1997 19:29:01 GMT Organization: IKS GmbH Jena Lines: 4 Message-ID: References: <3.0.3.32.19971104110653.009f02a0@mail.imc.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Paul Hoffman / IMC wrote: >Which part of that did you not understand? That's a result. Plain and simple. I do not urge any actions based on this. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11503 for ietf-open-pgp-bks; Tue, 4 Nov 1997 11:19:20 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11498 for ; Tue, 4 Nov 1997 11:19:07 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id LAA26405 for ; Tue, 4 Nov 1997 11:18:38 -0800 (PST) Message-Id: <3.0.3.32.19971104111901.08918100@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 04 Nov 1997 11:19:01 -0800 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?) In-Reply-To: <199711021337.NAA09022@server.test.net> References: <199711021302.IAA30916@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:37 PM 11/2/97 GMT, Adam Back wrote: It may not be necessary to have CAST5 to be interoperable with pgp5.x -- the symmetric cipher capability flags which are attached to public keys would allow people not implementing "MAY/or just OID listed" CAST5 to warn pgp5.x that they can't handle CAST5. Or stated the other way around, if CAST5 is not to be listed as a SHOULD, there better be a way to tell pgp5.x not to send email encrypted with CAST5 which reliably ensures you don't get CAST5 in your mailbox. By reliably I mean even with Cc combinations of people with different combinations where multiple recipient encryption is used. Perhaps someone from PGP Inc with a better understanding of how this works (as the draft is not out yet) could explain how this would work out. There may even be that there is a case for CAST5 to be a SHOULD for compatibility with pgp5.x. PGP Inc clarifications please! The whole reason I originally suggested that CAST5 be a SHOULD algorithm was my principle that any algorithm needed for compatibility ought to be a SHOULD algorithm. Since then, though, Hal told me that PGP 5.x does not need CAST5 to be a SHOULD algorithm. In other words, given that Triple-DES is the MUST algorithm, a MUST-only implementation can interoperate with PGP 5.x. This is why I'm leaning away from making it a SHOULD. If Triple-DES is the MUST, and IDEA is a SHOULD, everything else can be a MAY and you still have maximal backwards compatiblilty. (Again, the most RSA or IDEA can be are SHOULD algorithms.) If you have a message that is encrypted to more than one recipient, and they all have their preferences, you quickly get to the MUST algorithm being the lowest common denominator. The painful rub for our current situation is that the MUST algorithm can't be the one for backwards compatibility. > My understanding is that CAST5 is the default algorithm in 5.x, if > it is not a MUST or SHOULD there still should be some mention that > it is the default in PGP and those wishing to be able to communicate > with 5.x users will need to implement it. Simmilar documentation > should be provide in regards to 2.6.x and the RSA/IDEA/MD5 > algortihms. I agree with the need to document cipher mode as well as OID -- for instance the IDEA mode is particularly odd: a non-standard CFB and it has particular checksum requirements. (8 byte random junk is encrypted to act as IV, and then 2 bytes of checksum repeating the last 2 bytes of the random junk. In addition something weird is done to the feedback at semantic boundaries in the message. Personally I find this quirky mode annoying, but we've got it now for backwards compatibility. Is this quirky semantic context variable length feedback CFB used with CAST5 and 3DES?) Hal can speak most clearly on this, but my understanding is that all the cyphers do the same thing. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11497 for ietf-open-pgp-bks; Tue, 4 Nov 1997 11:19:07 -0800 (PST) Received: from privnet.pgp.com (root@privnet.pgp.com [205.180.136.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11487 for ; Tue, 4 Nov 1997 11:18:29 -0800 (PST) Received: from localhost (hoffmang@localhost [127.0.0.1]) by privnet.pgp.com (8.7.6/8.7.3) with SMTP id LAA06525; Tue, 4 Nov 1997 11:16:42 -0800 Date: Tue, 4 Nov 1997 11:16:41 -0800 (PST) From: Gene Hoffman To: mark@unicorn.com cc: ietf-open-pgp@imc.org Subject: Re: Just say NO to key escrow or CMR/ARR revisited In-Reply-To: <878670082.10174.193.133.230.33@unicorn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-open-pgp@imc.org Precedence: bulk On Tue, 4 Nov 1997 mark@unicorn.com wrote: > At the same time, it builds a 'feature' into every copy > of PGP which could at some point in the future be used to provide > government access to messages by forcing users to encrypt to a government > key. This, to Adam and others (including me), is so great a risk that > we'd much prefer key escrow or an alternate system. Building a key escrow system would do exactly the same thing. Putting in place the infrastructure for automated enterprise wide key escrow to a corporate key would mean building a technology infrastructure at exactly the same risk. A government could just as easily say, "Thou shalt escrow to the FBI key and send it to central storage" as they could corrupt CMR to say "Thou shalt encrypt to the FBI key." Corporations are going to want central, encrypted escrow if PGP, Inc. were to go that way. It would take the same amount of government intervention to corrupt a corporate key escrow system as CMR. -Gene Hoffman PGP, Inc. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11346 for ietf-open-pgp-bks; Tue, 4 Nov 1997 11:08:49 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11342 for ; Tue, 4 Nov 1997 11:08:42 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id LAA21604; Tue, 4 Nov 1997 11:04:34 -0800 (PST) Message-Id: <3.0.3.32.19971104110653.009f02a0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 04 Nov 1997 11:06:53 -0800 To: lutz@taranis.iks-jena.de (Lutz Donnerhacke), ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: Ballot result: Element vs Packet In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I find this wholly offensive. This is an IETF Working Group, not a informal gang of developers making a spec by brute force. Lutz, you have previously claimed ignorance of IETF rules, and it appears that you have not done anything to fix that ignorance. I'd like to repeat what the WG chairperson said weeks ago: >Lutz, let me speak more plainly. The chair will not hear further >discussion on this issue. The chair did not call for a straw poll. There >will be no vote on this. Which part of that did you not understand? --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA11205 for ietf-open-pgp-bks; Tue, 4 Nov 1997 11:01:43 -0800 (PST) Received: from sirius.infonex.com (sirius.infonex.com [206.170.114.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA11199 for ; Tue, 4 Nov 1997 11:01:36 -0800 (PST) Received: (from nobody@localhost) by sirius.infonex.com (8.8.8/8.7.3) id LAA10175; Tue, 4 Nov 1997 11:01:24 -0800 (PST) Date: Tue, 4 Nov 1997 11:01:24 -0800 (PST) From: mark@unicorn.com To: ietf-open-pgp@imc.org Message-Id: <878670082.10174.193.133.230.33@unicorn.com> Subject: Re: Just say NO to key escrow or CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Since this probably is the wrong place for this discussion, I'll simply point out that every supposed advantage you give for CMR could equally apply to a properly designed key escrow system. Both provide access to data for those who have access to the recovery keys, and any system controlling access to CMR recovery keys could be used to control access to escrowed keys. The only advantage that PGP Inc have suggested for CMR over key escrow is that you can write your own version of PGP which puts garbage in the CMR key field. At the same time, it builds a 'feature' into every copy of PGP which could at some point in the future be used to provide government access to messages by forcing users to encrypt to a government key. This, to Adam and others (including me), is so great a risk that we'd much prefer key escrow or an alternate system. In fact, key escrow does not have to be built into PGP at all; it can be implemented by an external secret-sharing program. I for one do not want to see any such system included in the Open PGP spec, but strongly suspect that PGP Inc will push it, since CMR cannot work properly unless every implementation of PGP supports it. Mark Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA10656 for ietf-open-pgp-bks; Tue, 4 Nov 1997 10:38:36 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA10652 for ; Tue, 4 Nov 1997 10:38:31 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id TAA24983; Tue, 4 Nov 1997 19:38:18 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Ballot result: Element vs Packet Date: 4 Nov 1997 18:38:17 GMT Organization: IKS GmbH Jena Lines: 19 Message-ID: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Packet Element iang@systemics.com Ian Grigg ABSTAIN ABSTAIN lutz@taranis.iks-jena.de Lutz Donnerhacke ABSTAIN ABSTAIN agreene@pobox.com Anthony E. Greene NO YES david.hayes@mci.com David Hayes NO YES dformosa@st.nepean.uws.edu.au David Formosa NO YES funne@iquest.net Jason Dufair NO YES kent@songbird.com Kent Crispin NO YES mione@boeing.rutgers.edu Tony Mione NO YES sasgwi@unx.sas.com Gary Williams NO YES tom.phinney@ibm.net Tom Phinney NO YES yog@ns.adis.at Gerald Young NO YES I.Brown@cs.ucl.ac.uk Ian Brown YES NO aba@dcs.ex.ac.uk Adam Back YES NO kelm@cert.dfn.de Stefan Kelm YES NO mike@alien-r.ace.co.uk Mike Wynn YES NO wffong@ca.ibm.com WengFatt Fong YES NO whgiii@invweb.net William H. Geiger III YES NO Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA09095 for ietf-open-pgp-bks; Tue, 4 Nov 1997 09:14:00 -0800 (PST) Received: from mailgw2.lmco.com (mailgw2.lmco.com [192.91.147.3]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA09091 for ; Tue, 4 Nov 1997 09:13:56 -0800 (PST) Received: from emss03g01.ems.lmco.com ([141.240.4.144]) by mailgw2.lmco.com (PMDF V5.1-10 #20547) with ESMTP id <0EJ400ELHT72U4@mailgw2.lmco.com> for ietf-open-pgp@imc.org; Tue, 4 Nov 1997 12:13:50 -0500 (EST) Received: from hobbes.orl.lmco.com ([141.240.192.100]) by lmco.com (PMDF V5.1-10 #20544) with SMTP id <0EJ4002W4T71OW@lmco.com> for ietf-open-pgp@imc.org; Tue, 04 Nov 1997 12:13:49 -0500 (EST) Date: Tue, 04 Nov 1997 11:13:38 -0500 (EST) From: "A. Padgett Peterson P.E. Information Security" Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do To: jon@pgp.com Cc: ietf-open-pgp@imc.org Message-id: <971104111338.20e0891d@hobbes.orl.lmco.com> Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Sounds like the only MUST should be a standard means of adding plug-in algoritms. That way id someone wanted IDEA, they could license the module and link to the local engine. Warmly, Padgett Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id JAA09063 for ietf-open-pgp-bks; Tue, 4 Nov 1997 09:12:00 -0800 (PST) Received: from italy.it.earthlink.net (italy-c.it.earthlink.net [204.250.46.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id JAA09059 for ; Tue, 4 Nov 1997 09:11:57 -0800 (PST) Received: from andrada.earthlink.net (ip139.portland4.or.pub-ip.psi.net [38.28.33.139]) by italy.it.earthlink.net (8.8.7/8.8.5) with SMTP id JAA08396; Tue, 4 Nov 1997 09:10:58 -0800 (PST) Message-Id: <3.0.3.32.19971104091013.007e3dc0@mail.earthlink.net> X-Sender: andrada@mail.earthlink.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 04 Nov 1997 09:10:13 -0800 To: Adam Back , ietf-open-pgp@imc.org From: Andrea Subject: Just say NO to key escrow or CMR/ARR revisited Cc: jon@pgp.com In-Reply-To: <199711032338.XAA02005@server.test.net> References: <3.0.3.32.19971103115159.0894a320@mail.pgp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would someone please post the name of the correct mailing list for discussing this, as I do not believe that what I am about to say is appropriate for this forum. At 11:38 PM 11/3/97 GMT, Adam wrote: > >Jon Callas suggests that CMR has been discussed vigorously. What was >the outcome? > >Here's a short summary of a more secure and less politically >controversial alternative to CMR: > >1. Escrow employee company use encryption keys. >2. Don't escrow employee personal use encryption keys. >3. Don't escrow employee company use signature keys. Who do you work for Adam, the CIA, FBI, Interpol? Escrowing company keys creates a target for abuse. If security and privacy is the goal there is no room for ANY key escrow except that copy of the private key that the individual maintains for their own backup. Message recovery, when used properly, enhances security and privacy as follows: 1) There should never be only one message recovery key that can access all organizational information. It creates a security risk. In the event that such a key is compromised all previously secured intellectual property would be at risk. 2) Message recovery is to be configured at the client for small organizational units. 3) The unit's "TMR", trusted message recovery key, is to be accessed by trusted members of the group under the following conditions: a) The holder of the private key cannot decrypt the message/file. (forgot passphrase, on vacation, dropped dead, went to jail, etc.) b) TMR requires cooperative access by two or more individules within the organizational unit. (Won't get into my "shared/split split/shared secret" scheme at this point.) 4) Compromise of the TMR key would require collusion. In the event that such compromise occurred, its impact would be limited to the single organizational unit and uncovering the weak link would be a fairly simple process. TMR gives honest people the ability to protect their privacy and to secure their work from their own memory loss as well as unknown spies. >As pgp5 packet format already supports multiple encryption sub keys >attached to signature keys, all that has to be done to support the >above is to put comments in the userID to say what purpose the keys >are for: > >Jon Callas (personal use) >Jon Callas (company use) > 99.9% (at least) of corporate users of encryption are not cryptographers. Understanding the difference between public and private keys, what encryption, decryption, digital signatures, and signature verification means is enough of a challenge without adding the complexity of multiple keys to be used for different purposes. >Provide support in the business verion of the software to escrow the >company use key. Provide support for both company use and personal >use keys. If some companies want to disallow personal use, you might >consider adding this feature. > This approach would only be appropriate if you were creating a surveillence system or a burdensome corporate control structure designed to invite corruption. >The above is already provided for without CMR/ARR. > >CMR/ARR fields add political and security risks, so why bother? > > >So what is PGP Inc's position on the future of CMR? > >Is it going to be phased out? > I hope not. It solves the problem of multi-dimensional trust when communicating on behalf of yourself and the organization of which you are part. >Is it going in the OpenPGP standard? > >Are there any security, privacy or political objections to local >escrow? Yes to all of the above. The rule of thumb here is.. Just say NO to key escrow. Andrea -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQA/AwUBNF9W9KIk/IORSe0LEQIWAwCgjgEi+ghc/Z7OZZF39N7s+Aqh0pUAoNxy vR/2fZep9VozQn35qVVZFleT =7EXd -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA06154 for ietf-open-pgp-bks; Tue, 4 Nov 1997 06:09:27 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id GAA06150 for ; Tue, 4 Nov 1997 06:09:22 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id PAA18209; Tue, 4 Nov 1997 15:09:09 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Armor Header Optional? Date: 4 Nov 1997 14:09:09 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk My draft points out, that the armor header may be missing. In this case the empty line closing the armor header MUST NOT appear. My very first draft said, that this line MAY occur anyway. It was changed to strong requests from list members. Unfortunly, this is not true for PGP 2.xx. The empty line MUST appear. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA25368 for ietf-open-pgp-bks; Mon, 3 Nov 1997 15:55:45 -0800 (PST) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.7/8.7.3) with SMTP id PAA25364 for ; Mon, 3 Nov 1997 15:55:40 -0800 (PST) Received: from aba@p52-chachalaca-gui.tch.virgin.net [194.168.58.112] by exub via ESMTP (XAA19889); Mon, 3 Nov 1997 23:55:10 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id XAA02005; Mon, 3 Nov 1997 23:38:05 GMT Date: Mon, 3 Nov 1997 23:38:05 GMT Message-Id: <199711032338.XAA02005@server.test.net> From: Adam Back To: jon@pgp.com CC: cypherpunks@cyberpass.net, ietf-open-pgp@imc.org In-reply-to: <3.0.3.32.19971103115159.0894a320@mail.pgp.com> (message from Jon Callas on Mon, 03 Nov 1997 11:51:59 -0800) Subject: CMR/ARR revisited Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas suggests that CMR has been discussed vigorously. What was the outcome? Here's a short summary of a more secure and less politically controversial alternative to CMR: 1. Escrow employee company use encryption keys. 2. Don't escrow employee personal use encryption keys. 3. Don't escrow employee company use signature keys. As pgp5 packet format already supports multiple encryption sub keys attached to signature keys, all that has to be done to support the above is to put comments in the userID to say what purpose the keys are for: Jon Callas (personal use) Jon Callas (company use) Provide support in the business verion of the software to escrow the company use key. Provide support for both company use and personal use keys. If some companies want to disallow personal use, you might consider adding this feature. The above is already provided for without CMR/ARR. CMR/ARR fields add political and security risks, so why bother? So what is PGP Inc's position on the future of CMR? Is it going to be phased out? Is it going in the OpenPGP standard? Are there any security, privacy or political objections to local escrow? Enciphering minds want to know... Adam Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id PAA24942 for ietf-open-pgp-bks; Mon, 3 Nov 1997 15:13:28 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id PAA24933; Mon, 3 Nov 1997 15:13:17 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id PAA11141; Mon, 3 Nov 1997 15:13:02 -0800 (PST) Message-Id: <3.0.3.32.19971103151323.08953990@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 03 Nov 1997 15:13:23 -0800 To: Paul Hoffman / IMC , Rodney Thayer , ietf-open-pgp@imc.org From: Jon Callas Subject: Re: how to discuss 2.6.2 compatability in OP... In-Reply-To: <3.0.3.32.19971103135838.00aed930@mail.imc.org> References: <3.0.3.32.19971103163122.039942a4@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:58 PM 11/3/97 -0800, Paul Hoffman / IMC wrote: Actually, I'd like it in the OpenPGP document, probably as an appendix. It is certainly acceptable to have the main document say how to have backward compatibility with pre-standards PGP, as long as compatibility that violates IETF rules isn't required. Backward compatibility that doesn't violate IETF rules could be required, although it probably should be optional if it's duplicated overhead. Noted. It probably won't get in immediately -- I want to get out a draft to everyone at the end of the week, but it makes a lot of sense to make such an appendix. It seems to me that it makes sense for such a thing to be in OP-FORMAT (my document), but if it should be in another one, someone suggest which one. This is a very good reason for using the word SHOULD. You MUST do it this way, but you also SHOULD allow the user to do it this way to be compatible with earlier versions if they want to. I've also heard that there are errors and omissions in RFC 1991. If this is true, it would be very good if someone either rewrote RFC 1991 with them fixed or at least created a separate document that lists the fixes. However, that's separate from the OpenPGP work. There are. When I came to PGP, I sat down and wrote some PGP-compatible software using only RFC 1991 and our original ZT article that described the V5 formats. I'm intimately familiar with what all is left out, and documenting those was the original purpose of OP. OP-FORMAT is the replacement for RFC 1991. When I started, the WG chairs wanted a reorganization of the document from 1991 and The July Draft. I was working on that, but have dropped that. The next draft takes Lutz's trunk and grafts on text from The July Draft, your armoring work, and a lot of stuff from Hal Finney. That's four merged docs. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA24584 for ietf-open-pgp-bks; Mon, 3 Nov 1997 14:50:44 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA24577 for ; Mon, 3 Nov 1997 14:50:38 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id RAA31182 for ; Mon, 3 Nov 1997 17:50:25 -0500 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id RAA35910 for ; Mon, 3 Nov 1997 17:50:25 -0500 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA51506; Mon, 3 Nov 1997 17:50:25 -0500 From: Uri Blumenthal Message-Id: <9711032250.AA51506@watpub1.watson.ibm.com> Subject: Re: how to discuss 2.6.2 compatability in OP... To: ietf-open-pgp@imc.org Date: Mon, 3 Nov 1997 17:50:24 -0500 (EST) In-Reply-To: <3.0.3.32.19971103135838.00aed930@mail.imc.org> from "Paul Hoffman / IMC" at Nov 3, 97 01:58:38 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Let me remind what those magic words are: MUST - unless you have it, you cannot claim conformance, period. SHOULD - you can claim conformance even without this feature, but you have to be able to explain to your customers why you omitted the named feature from your product. If they don't buy your excuse, tough luck for you. MAY - entirely up to you, "no questions asked". -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id OAA24514 for ietf-open-pgp-bks; Mon, 3 Nov 1997 14:43:59 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id OAA24501 for ; Mon, 3 Nov 1997 14:43:37 -0800 (PST) Received: from mailhub.watson.ibm.com (mailhub.watson.ibm.com [9.2.250.97]) by igw3.watson.ibm.com (8.8.7/07-11-97) with ESMTP id RAA26934; Mon, 3 Nov 1997 17:43:21 -0500 Received: from watpub1.watson.ibm.com (watpub1.watson.ibm.com [9.2.101.12]) by mailhub.watson.ibm.com (8.8.7/07-14-97) with SMTP id RAA28468; Mon, 3 Nov 1997 17:42:00 -0500 Received: by watpub1.watson.ibm.com (AIX 4.1/UCB 5.64/6/25/96) id AA51588; Mon, 3 Nov 1997 17:37:57 -0500 From: Uri Blumenthal Message-Id: <9711032237.AA51588@watpub1.watson.ibm.com> Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do To: jon@pgp.com (Jon Callas) Date: Mon, 3 Nov 1997 17:37:56 -0500 (EST) Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971103123117.08944290@mail.pgp.com> from "Jon Callas" at Nov 3, 97 12:31:17 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ietf-open-pgp@imc.org Precedence: bulk Jon Callas says: > So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer > MUST, but I see the problem. > > Alas, it doesn't. The only thing that guarantees interoperability is MUST, > and you can't have a MUST algorithm that's got intellectual property > constraints, if there is an alternative. Wel, nobody asks to GUARANTEE backward compatibility in ALGORITHMS. On the other hand, nobody prohibits one from purchasing IDEA and RSA license and building a backward-compatible product, if this is what one thinks his customers want. To accomplish it, "MAY" would be sufficient. "SHOULD" is actively encouraging the interoperability with the obsoleted de-facto standard and is certainly more than enough. > When we started the BOF in Munich, we had as one of the OP goals "limited > backwards compatibility." What we meant by this was that we wouldn't even > consider backwards compatibility with anything before 2.6, we even think > that 2.6 should eventually be migrated/upgraded/phased out for security > reasons, and we knew that even 2.6 compatibility is not possible given IETF > because 2.6 used *only* encumbered algorithms. Thus, we put in the > weasel-words "limited backwards compatibility." Speaking PGP Inc. - I wish you ensured full backward compatibility wrt. the INTERFACE: for example, since I have no time to modify Mailcrypt-3.4 package that serves me nicely, I'd appreciate if you could make PGP-6 (or whatever version it is going to have :-) a perfect drop-in replacement for PGP-2.6.x having the default algorithm suit specified, let's say, in ~/.pgp/config.txt. > The bottom line is that we cannot be both an IETF standard and have > guaranteed backward compatibility with 2.6. Sure. How possibly can this be any different? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA22003 for ietf-open-pgp-bks; Mon, 3 Nov 1997 13:58:55 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id NAA21996 for ; Mon, 3 Nov 1997 13:58:51 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id NAA19112; Mon, 3 Nov 1997 13:56:20 -0800 (PST) Message-Id: <3.0.3.32.19971103135838.00aed930@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 03 Nov 1997 13:58:38 -0800 To: Rodney Thayer , ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: how to discuss 2.6.2 compatability in OP... In-Reply-To: <3.0.3.32.19971103163122.039942a4@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 04:31 PM 11/3/97 -0500, Rodney Thayer wrote: >I believe the proper thing to do in this situation is for some interested >party to write an informational draft that describes how, within the >context of the OP framework, one would build something that is backwards >compatible with 2.6.2. Actually, I'd like it in the OpenPGP document, probably as an appendix. It is certainly acceptable to have the main document say how to have backward compatibility with pre-standards PGP, as long as compatibility that violates IETF rules isn't required. Backward compatibility that doesn't violate IETF rules could be required, although it probably should be optional if it's duplicated overhead. This is a very good reason for using the word SHOULD. You MUST do it this way, but you also SHOULD allow the user to do it this way to be compatible with earlier versions if they want to. I've also heard that there are errors and omissions in RFC 1991. If this is true, it would be very good if someone either rewrote RFC 1991 with them fixed or at least created a separate document that lists the fixes. However, that's separate from the OpenPGP work. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id NAA21780 for ietf-open-pgp-bks; Mon, 3 Nov 1997 13:34:21 -0800 (PST) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id NAA21776 for ; Mon, 3 Nov 1997 13:34:16 -0800 (PST) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 3 Nov 1997 21:34:08 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id QAA01441 for ; Mon, 3 Nov 1997 16:36:24 -0500 (EST) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 3 Nov 1997 21:34:07 UT Received: from ferguson.newton.sabletech.com ([199.249.254.9]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id QAA25269 for ; Mon, 3 Nov 1997 16:34:03 -0500 (EST) Message-Id: <3.0.3.32.19971103163122.039942a4@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 03 Nov 1997 16:31:22 -0500 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: how to discuss 2.6.2 compatability in OP... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk I believe the proper thing to do in this situation is for some interested party to write an informational draft that describes how, within the context of the OP framework, one would build something that is backwards compatible with 2.6.2. In other words, write a draft that says: to be compatible with 2.6.2, use RSA and IDEA. Their identifiers are and . It gets the information documented. It's Informational so it doesn't violate the IETF guidelines. It can be referenced by the main document. It even gives you a place to write a nice speech in the Security Considerations section about how you wish people would migrate. > So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer > MUST, but I see the problem. > >Alas, it doesn't. The only thing that guarantees interoperability is MUST, >and you can't have a MUST algorithm that's got intellectual property >constraints, if there is an alternative. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id MAA20996 for ietf-open-pgp-bks; Mon, 3 Nov 1997 12:31:27 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id MAA20991 for ; Mon, 3 Nov 1997 12:31:11 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id MAA08607 for ; Mon, 3 Nov 1997 12:30:56 -0800 (PST) Message-Id: <3.0.3.32.19971103123117.08944290@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 03 Nov 1997 12:31:17 -0800 To: ietf-open-pgp@imc.org From: Jon Callas Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do In-Reply-To: References: <199710312043.UAA07558@server.test.net> <3.0.3.32.19971101112020.00a783a0@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 12:11 PM 11/3/97 GMT, Lutz Donnerhacke wrote: So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer MUST, but I see the problem. Alas, it doesn't. The only thing that guarantees interoperability is MUST, and you can't have a MUST algorithm that's got intellectual property constraints, if there is an alternative. When we started the BOF in Munich, we had as one of the OP goals "limited backwards compatibility." What we meant by this was that we wouldn't even consider backwards compatibility with anything before 2.6, we even think that 2.6 should eventually be migrated/upgraded/phased out for security reasons, and we knew that even 2.6 compatibility is not possible given IETF because 2.6 used *only* encumbered algorithms. Thus, we put in the weasel-words "limited backwards compatibility." The bottom line is that we cannot be both an IETF standard and have guaranteed backward compatibility with 2.6. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA20477 for ietf-open-pgp-bks; Mon, 3 Nov 1997 11:53:46 -0800 (PST) Received: from fusebox.pgp.com (fusebox.pgp.com [205.180.136.16]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA20468 for ; Mon, 3 Nov 1997 11:53:32 -0800 (PST) Received: from fnord (fnord.pgp.com [205.180.136.111]) by fusebox.pgp.com (8.8.7/8.8.5) with SMTP id LAA07958; Mon, 3 Nov 1997 11:51:39 -0800 (PST) Message-Id: <3.0.3.32.19971103115159.0894a320@mail.pgp.com> X-Sender: jon@mail.pgp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 03 Nov 1997 11:51:59 -0800 To: Adam Back , whgiii@invweb.net From: Jon Callas Subject: Re: RSA Blows Smoke Cc: cypherpunks@cyberpass.net, ietf-open-pgp@imc.org In-Reply-To: <199711021353.NAA09099@server.test.net> References: <199711021240.HAA30685@users.invweb.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 01:53 PM 11/2/97 GMT, Adam Back wrote: Unfortunately PGP Inc have closed off dialogue on the topic -- apparent blanket ban on employee discussion of CMR. Horsefeathers, Adam. We've been talking about this with you a lot and you know it. We set up a mailing list to discuss it, you've received personal phone calls, and lots of people have bent over backwards for you. If you think you're being ignored, perhaps you should re-examine the signal-to-noise ratio of your posts. Jon ----- Jon Callas jon@pgp.com Chief Scientist 555 Twin Dolphin Drive Pretty Good Privacy, Inc. Suite 570 (415) 596-1960 Redwood Shores, CA 94065 Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS) 665B 797F 37D1 C240 53AC 6D87 3A60 4628 (RSA) Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA13436 for ietf-open-pgp-bks; Mon, 3 Nov 1997 04:11:57 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA13432 for ; Mon, 3 Nov 1997 04:11:52 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id NAA11830; Mon, 3 Nov 1997 13:11:41 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do Date: 3 Nov 1997 12:11:41 GMT Organization: IKS GmbH Jena Lines: 14 Message-ID: References: <199710312043.UAA07558@server.test.net> <3.0.3.32.19971101112020.00a783a0@mail.imc.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Paul Hoffman / IMC wrote: >A very basic reason: SHOULD is only for things that are strongly desired by >all implementations. If we have a strong algorithm for a MUST and another >strong algorithm for a SHOULD, I see no point to tossing another SHOULD in. >Many developers try to implement all SHOULD-level specs, and this would >cause needless software bloat with little definable benefit. So IDEA as SHOULD would guarantee backward compatibility? Fine. I'd prefer MUST, but I see the problem. >And, again, I would strongly lobby against any MAY list. A list of IDs for >all known algorithms identifiers is enough. That's a MAY list. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA13345 for ietf-open-pgp-bks; Mon, 3 Nov 1997 04:07:55 -0800 (PST) Received: from grannus.iks-jena.de (news@grannus.iks-jena.de [194.221.90.36]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA13341 for ; Mon, 3 Nov 1997 04:07:49 -0800 (PST) Received: (from news@localhost) by grannus.iks-jena.de (8.8.8/8.8.7) id NAA11824; Mon, 3 Nov 1997 13:07:34 +0100 To: ietf-open-pgp@imc.org Path: lutz From: lutz@taranis.iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: expectation of privacy (Re: Symmetric Algorithm) Date: 3 Nov 1997 12:07:34 GMT Organization: IKS GmbH Jena Lines: 6 Message-ID: References: <971030175356.20e04e6b@hobbes.orl.lmco.com> <3.0.3.32.19971030180042.08918100@mail.pgp.com> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: slrn (0.9.4.0 UNIX) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk * Jon Callas wrote: >Your request for an algorithm identifier for ROT-13 has been duly noted. It >might be better if I generalized it in the spec to ROT-N, where N is a >128-bit number. Don't include it. It is too easy to break. Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id KAA03444 for ietf-open-pgp-bks; Sun, 2 Nov 1997 10:28:35 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id KAA03439 for ; Sun, 2 Nov 1997 10:28:31 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id KAA16366 for ; Sun, 2 Nov 1997 10:26:01 -0800 (PST) Message-Id: <3.0.3.32.19971102102759.0081d3e0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 02 Nov 1997 10:27:59 -0800 To: ietf-open-pgp@imc.org From: Paul Hoffman / IMC Subject: Re: Could We PLEASE stay on-topic here? In-Reply-To: <3.0.3.32.19971102093913.0396bcec@pop.pn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk At 09:39 AM 11/2/97 -0500, Rodney Thayer wrote: >I don't think RSA-bashing is on-topic for this IETF WORKING GROUP >mailing list. I completely agree. The last thing OpenPGP needs to be is sidetracked by the political machinations going on in the S/MIME world. RSADSI is who they have always been, and this is part of the need for OpenPGP to come out well, and soon. --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA01986 for ietf-open-pgp-bks; Sun, 2 Nov 1997 06:48:20 -0800 (PST) Received: from grinch.whoville.leftbank.com (grinch.leftbank.com [139.167.128.2]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA01982 for ; Sun, 2 Nov 1997 06:48:16 -0800 (PST) Received: from zax.whoville.leftbank.com by grinch.whoville.leftbank.com via smtpd (for mail.proper.com [206.86.127.224]) with SMTP; 2 Nov 1997 14:48:02 UT Received: from max.whoville.leftbank.com (max.whoville.leftbank.com [139.167.32.1]) by zax.leftbank.com (8.7.5/8.7.3/LeftBank-1.1/http://www.leftbank.com/) with SMTP id JAA09417 for ; Sun, 2 Nov 1997 09:50:11 -0500 (EST) Received: from lbo.leftbank.com ([192.31.227.130]) by max.whoville.leftbank.com via smtpd (for zax.whoville.leftbank.com [139.167.32.33]) with SMTP; 2 Nov 1997 14:47:54 UT Received: from ferguson.newton.sabletech.com ([199.249.254.9]) by lbo.leftbank.com (8.8.5/8.7.3/http://www.LeftBank.Com) with SMTP id JAA17794 for ; Sun, 2 Nov 1997 09:47:52 -0500 (EST) Message-Id: <3.0.3.32.19971102093913.0396bcec@pop.pn.com> X-PGP-Key: X-Sender: rodney@pop.pn.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 02 Nov 1997 09:39:13 -0500 To: ietf-open-pgp@imc.org From: Rodney Thayer Subject: Could We PLEASE stay on-topic here? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I don't think RSA-bashing is on-topic for this IETF WORKING GROUP mailing list. Could we please stick to the subject? If you want to bitch about RSA, do it on cypherpunks or something. Cross-posting is also somewhat offensive. -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBNFyQkMKmlvJNktGxAQGUkwQAwBGUlnisLSBBq5RDyqEL1UDHDO8s8gR1 7rsDvnN8Diqsq1z30MZRaWQb2MqDyxalM1aiK4S8GSW9lIPHL6DuaNQ20/LMW+Fp /CxKPH0PGDZo9Cos1FYVje1GX8kP4S0AHWyOyU9tiICtmUla+pERPDxo1UbIgupb 6Lvr+pUl+pg= =PnKB -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id GAA01704 for ietf-open-pgp-bks; Sun, 2 Nov 1997 06:05:24 -0800 (PST) Received: from exub.ex.ac.uk (exub.ex.ac.uk [144.173.6.72]) by mail.proper.com (8.8.7/8.7.3) with SMTP id GAA01694; Sun, 2 Nov 1997 06:05:15 -0800 (PST) Received: from aba@p45-flameback-gui.tch.virgin.net [194.168.62.45] by exub via ESMTP (OAA18469); Sun, 2 Nov 1997 14:04:53 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id NAA09022; Sun, 2 Nov 1997 13:37:42 GMT Date: Sun, 2 Nov 1997 13:37:42 GMT Message-Id: <199711021337.NAA09022@server.test.net> From: Adam Back To: whgiii@invweb.net CC: phoffman@imc.org, jon@pgp.com, hoffmang@pgp.com, ietf-open-pgp@imc.org In-reply-to: <199711021302.IAA30916@users.invweb.net> (whgiii@invweb.net) Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?) Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William Geiger writes: > >>[MUST = DSA/EG/3DES > >> SHOULD = RSA/IDEA/MD5] > > > >A very basic reason: SHOULD is only for things that are strongly desired > >by all implementations. If we have a strong algorithm for a MUST and > >another strong algorithm for a SHOULD, I see no point to tossing another > >SHOULD in. Many developers try to implement all SHOULD-level specs, and > >this would cause needless software bloat with little definable benefit. > > > >And, again, I would strongly lobby against any MAY list. A list of IDs > >for all known algorithms identifiers is enough. > > Well FWIW I don't have a problem with only having one MUST and one SHOULD > but if we are going that route there should be some documentation on what > algorithms PGP 2.6.x & PGP 5.x are using and what the default operations > are so implementors can insure that they have compatability with the > current software available. It may not be necessary to have CAST5 to be interoperable with pgp5.x -- the symmetric cipher capability flags which are attached to public keys would allow people not implementing "MAY/or just OID listed" CAST5 to warn pgp5.x that they can't handle CAST5. Or stated the other way around, if CAST5 is not to be listed as a SHOULD, there better be a way to tell pgp5.x not to send email encrypted with CAST5 which reliably ensures you don't get CAST5 in your mailbox. By reliably I mean even with Cc combinations of people with different combinations where multiple recipient encryption is used. Perhaps someone from PGP Inc with a better understanding of how this works (as the draft is not out yet) could explain how this would work out. There may even be that there is a case for CAST5 to be a SHOULD for compatibility with pgp5.x. PGP Inc clarifications please! > My understanding is that CAST5 is the default algorithm in 5.x, if > it is not a MUST or SHOULD there still should be some mention that > it is the default in PGP and those wishing to be able to communicate > with 5.x users will need to implement it. Simmilar documentation > should be provide in regards to 2.6.x and the RSA/IDEA/MD5 > algortihms. I agree with the need to document cipher mode as well as OID -- for instance the IDEA mode is particularly odd: a non-standard CFB and it has particular checksum requirements. (8 byte random junk is encrypted to act as IV, and then 2 bytes of checksum repeating the last 2 bytes of the random junk. In addition something weird is done to the feedback at semantic boundaries in the message. Personally I find this quirky mode annoying, but we've got it now for backwards compatibility. Is this quirky semantic context variable length feedback CFB used with CAST5 and 3DES?) Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0; Sun, 2 Nov 1997 06:05:16 -0800 (PST) Received: from aba@p45-flameback-gui.tch.virgin.net [194.168.62.45] by exub via ESMTP (OAA18466); Sun, 2 Nov 1997 14:04:50 GMT Received: (from aba@localhost) by server.test.net (8.8.3/8.6.12) id NAA09099; Sun, 2 Nov 1997 13:53:15 GMT Date: Sun, 2 Nov 1997 13:53:15 GMT Message-Id: <199711021353.NAA09099@server.test.net> From: Adam Back To: whgiii@invweb.net CC: cypherpunks@cyberpass.net, ietf-open-pgp@imc.org In-reply-to: <199711021240.HAA30685@users.invweb.net> (whgiii@invweb.net) Subject: Re: RSA Blows Smoke Sender: owner-ietf-open-pgp@imc.org Precedence: bulk William Geiger forwards article: > The Internet standards process is lengthy and complicated at > best. The sticking point in RSA's efforts to date is that the task > force will only consider non-proprietary technologies for the > standards track. But S/MIME 2, the protocol at the heart of the > effort, includes core RSA technologies that must be licensed. No hope then, cool :-) > RSA, in fact, is only one of five groups that have worked on S/MIME 2, > which is about to be submitted by the Internet Mail Coalition to the IETF > as an informational request for comments. Now, in order to retain its hold > on the S/MIME technology, RSA is taking sole credit for submitting it to > the task force, some observers claim. Who worked on S/MIME 2? How comes it's the same "Internet Mail Coalition" that is "submitting S/MIME 2 to the IETF" as the one which Paul Hoffman is slagging off RSA and S/MIME 2? What version of S/MIME does netscape support? > Hoffman reiterated that S/MIME 2 won't be an Internet standard > because it relies on proprietary security technology and weak > encryption. The Internet Mail Coalition is about to begin work on > S/MIME 3, which will use stronger encryption and true open > standards. What's the point? Why have two competing standards OpenPGP and S/MIME 3 -- does RSA hope that they will get some value from it? Does S/MIME 3 have key escrow or CMR snooping support? > "I hope [the announcement] hasn't sunk their chances because there > are still a lot of people who want to do S/MIME," said > Hoffman. "RSA's greediness could sink this, but I really hope it > doesn't." Before I heard about CMR additions to pgp5.x I would have said I do sincerely hope RSA's greed sinks this. (40 bit RC2/40 feh!) I think I still do hope RSA's greed sinks S/MIME on average, but I would be much more certain if this pgp5.x CMR thing could be resolved satisfactorily. Unfortunately PGP Inc have closed off dialogue on the topic -- apparent blanket ban on employee discussion of CMR. So will the OpenPGP draft which Jon Callas dubbed "non political" include CMR? Adam -- Now officially an EAR violation... Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/ print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0 From: "William H. Geiger III" Date: Sun, 02 Nov 97 06:53:09 -0600 To: Paul Hoffman / IMC In-Reply-To: <3.0.3.32.19971101112020.00a783a0@mail.imc.org> Cc: Jon Callas , Adam Back , hoffmang@pgp.com, ietf-open-pgp@imc.org Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?) X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- In <3.0.3.32.19971101112020.00a783a0@mail.imc.org>, on 11/01/97 at 02:20 PM, Paul Hoffman / IMC said: >> Anyway, I agree with the people who are arguing for MUST for 3DES, >> DSA, Elgamal; and SHOULD for RSA, IDEA, MD5, and MAY for the rest. >> >>This is my plan. I'm still open toward making CAST5 a SHOULD (in fact, that >>is my personal preference), but I hear more reasons for MAY than SHOULD. >A very basic reason: SHOULD is only for things that are strongly desired >by all implementations. If we have a strong algorithm for a MUST and >another strong algorithm for a SHOULD, I see no point to tossing another >SHOULD in. Many developers try to implement all SHOULD-level specs, and >this would cause needless software bloat with little definable benefit. >And, again, I would strongly lobby against any MAY list. A list of IDs >for all known algorithms identifiers is enough. Well FWIW I don't have a problem with only having one MUST and one SHOULD but if we are going that route there should be some documentation on what algorithms PGP 2.6.x & PGP 5.x are using and what the default operations are so implementors can insure that they have compatability with the current software available. My understanding is that CAST5 is the default algorithm in 5.x, if it is not a MUST or SHOULD there still should be some mention that it is the default in PGP and those wishing to be able to communicate with 5.x users will need to implement it. Simmilar documentation should be provide in regards to 2.6.x and the RSA/IDEA/MD5 algortihms. - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNFx5Z49Co1n+aLhhAQFyOgP/d34unVqFpG4hF5QvjCz2sMejCXpNjpE1 K9fqzcYEGvRGKXt+5h9p+ZstNz+zvWqep+Gk1xcVBs0YwSppC6dM4ROqSv5AZsbr QjHD6v+eASOflK3Qw23aQj9zVpsbiPmu1DJ4iQEIN5UJbLB6VHZ7ytETPNkRc4zb 2xBy9rcJUq8= =9v+z -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id EAA01269 for ietf-open-pgp-bks; Sun, 2 Nov 1997 04:41:31 -0800 (PST) Received: from users.invweb.net (root@users.invweb.net [198.182.196.33]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id EAA01264 for ; Sun, 2 Nov 1997 04:41:19 -0800 (PST) Received: from users.invweb.net (ppp20.dotstar.net [208.143.93.39]) by users.invweb.net (8.8.7/8.8.7) with SMTP id HAA30685; Sun, 2 Nov 1997 07:40:56 -0500 Message-Id: <199711021240.HAA30685@users.invweb.net> From: "William H. Geiger III" Date: Sun, 02 Nov 97 06:37:59 -0600 To: cypherpunks@cyberpass.net Cc: ietf-open-pgp@imc.org Subject: RSA Blows Smoke X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v1.40a b42 Sender: owner-ietf-open-pgp@imc.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Wierd News RSA Blows Standards Smoke James Glave james@wired.com" 6:16pm 31.Oct.97.PST http://www.wired.com/news/news/business/story/8196.html Today's announcement "http://www.rsa.com/smimelive/html/9710311.html" by RSA Data Security stating that the company has formally applied to the Internet Engineering Task Force to establish an email security standard is a blatant lie rooted in greed, allege sources close to the process. "RSA is lying, and I am really livid," said Paul Hoffman of the Internet Mail Coalition. "RSA has not submitted anything." The flap centers around the company's ongoing efforts to get its proprietary S/MIME email encryption technology endorsed as a standard by the task force. Such an endorsement would give the company credibility, and potentially, an increased market share over rival Pretty Good Privacy. PGP submitted a competing protocol for standards consideration last month. The Internet standards process is lengthy and complicated at best. The sticking point in RSA's efforts to date is that the task force will only consider non-proprietary technologies for the standards track. But S/MIME 2, the protocol at the heart of the effort, includes core RSA technologies that must be licensed. To be considered for standardization, RSA must relinquish "change control," or the ability to modify the technology, to the task force. And the portion the task force is most interested in altering is the portion that requires RSA technology. As a result, getting change control "has been like pulling teeth," claims Jeff Schiller, the organization's security director. "Their goal has always been get this into the IETF but don't really give up control," said Schiller. "[They want to] make sure that when the standard comes down, if an anyone wants to implement it then they have to be a licensee." Schiller says that until change control is secured, RSA has no hope of coming near a formal application - as they had claimed to have already done this morning. RSA, however, claims that it has granted change control. "They are trying to get more market share by claiming that the IETF is endorsing their commercial product," alleged Schiller. RSA, in fact, is only one of five groups that have worked on S/MIME 2, which is about to be submitted by the Internet Mail Coalition to the IETF as an informational request for comments. Now, in order to retain its hold on the S/MIME technology, RSA is taking sole credit for submitting it to the task force, some observers claim. "It's totally disacknowledging the work of a lot of other people," said Hoffman. A request for comments is one of the initial steps in the certification process, and Hoffman says that the Internet Mail Coalition has yet to put S/MIME 2 forward. Further, Schiller says, "When we do, it is not trying to get it as an Internet standard. It won't go - and therefore we are not going to try." Hoffman reiterated that S/MIME 2 won't be an Internet standard because it relies on proprietary security technology and weak encryption. The Internet Mail Coalition is about to begin work on S/MIME 3, which will use stronger encryption and true open standards. Tim Matthews, product manager for RSA, acknowledged that the announcement may be open to misinterpretation. "It's basically a summation of all the work we've been doing over the past month," he said. Instead of helping its own cause, and gaining public mindshare, RSA's announcement may end up flying back in its face. "If it fragments the S/MIME camp it could help PGP a bit," said Charles Breed, director of technology for competitor PGP. "I hope [the announcement] hasn't sunk their chances because there are still a lot of people who want to do S/MIME," said Hoffman. "RSA's greediness could sink this, but I really hope it doesn't." - -- - --------------------------------------------------------------- William H. Geiger III http://www.amaranth.com/~whgiii Geiger Consulting Cooking With Warp 4.0 Author of E-Secure - PGP Front End for MR/2 Ice PGP & MR/2 the only way for secure e-mail. OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html - --------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: cp850 Comment: Registered_User_E-Secure_v1.1b1_ES000000 iQCVAwUBNFx0To9Co1n+aLhhAQHzQwQAwfbrjUYnFP2Q72Zbld6zDOeprNWV/9Lc fzGy7wiS0Jewx9dgMxMw1jHonlqLak469XzJzJVbSnGpvfpau1QJjWus1sKDbUeL YC87k71t7vTcnWumqnsndlItwbn8AVw5TRLqRxsF+cz4PaspIAx4hIY8V9jDBIk6 EY9J1FSeFkg= =SINu -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by mail.proper.com (8.8.7/8.7.3) id LAA22029 for ietf-open-pgp-bks; Sat, 1 Nov 1997 11:20:50 -0800 (PST) Received: from proper.com (proper.com [165.227.249.2]) by mail.proper.com (8.8.7/8.7.3) with ESMTP id LAA22025 for ; Sat, 1 Nov 1997 11:20:46 -0800 (PST) Received: from prabhava.proper.com (prabhava.proper.com [165.227.249.110]) by proper.com (8.8.7/8.7.3) with SMTP id LAA14103; Sat, 1 Nov 1997 11:18:07 -0800 (PST) Message-Id: <3.0.3.32.19971101112020.00a783a0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 01 Nov 1997 11:20:20 -0800 To: Jon Callas , Adam Back , hoffmang@pgp.com From: Paul Hoffman / IMC Subject: Re: IDEA licensing vs RSA licensing (Re: What do we have to do today?) Cc: ietf-open-pgp@imc.org In-Reply-To: <3.0.3.32.19971031154754.00b30220@mail.pgp.com> References: <199710312043.UAA07558@server.test.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-open-pgp@imc.org Precedence: bulk > Anyway, I agree with the people who are arguing for MUST for 3DES, > DSA, Elgamal; and SHOULD for RSA, IDEA, MD5, and MAY for the rest. > >This is my plan. I'm still open toward making CAST5 a SHOULD (in fact, that >is my personal preference), but I hear more reasons for MAY than SHOULD. A very basic reason: SHOULD is only for things that are strongly desired by all implementations. If we have a strong algorithm for a MUST and another strong algorithm for a SHOULD, I see no point to tossing another SHOULD in. Many developers try to implement all SHOULD-level specs, and this would cause needless software bloat with little definable benefit. And, again, I would strongly lobby against any MAY list. A list of IDs for all known algorithms identifiers is enough. --Paul Hoffman, Director --Internet Mail Consortium