From owner-ietf-openpgp@mail.imc.org Thu Jun 1 15:09:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00873 for ; Thu, 1 Jun 2000 15:09:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05879 for ietf-openpgp-bks; Thu, 1 Jun 2000 11:42:04 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05873 for ; Thu, 1 Jun 2000 11:42:02 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id OAA30158; Thu, 1 Jun 2000 14:49:46 -0400 Message-Id: <200006011849.OAA30158@domains.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jun 2000 13:08:35 -0500 To: Dave Crocker In-Reply-To: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> Cc: ietf-openpgp@imc.org Subject: Re: patents? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net>, on 05/31/00 at 06:24 PM, Dave Crocker said: >At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote: >>Being as no evil lawyers from NAI or elsewhere have swooped down on this >>list or on the IETF I'd say it's safe for now. >> >>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >>>Probably just standard boilerplate. They are just putting you on notice >>>that by publishing their source code they are not giving up any rights >>>that the may hold on the code. >You are both being far too optimistic. While it is possible that you are > correct, it is equally possible -- and many would say more likely -- >that patents are, in fact, held or being prosecuted. >The IETF has had some patents emerge very late in the process, so the >concern is not academic. Well Dave I know several of the people in the PGP group at NAI and I don't think that they would allow something like this. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Fri Jun 2 05:34:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26846 for ; Fri, 2 Jun 2000 05:34:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00667 for ietf-openpgp-bks; Fri, 2 Jun 2000 02:08:26 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA00663 for ; Fri, 2 Jun 2000 02:08:24 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 3097 invoked from network); 2 Jun 2000 09:11:50 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 2 Jun 2000 09:11:50 -0000 To: ietf-openpgp@imc.org Subject: confidential subject lines -> use content description field w/ pgp/mime? X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000602181611R.1001@eccosys.com> Date: Fri, 02 Jun 2000 18:16:11 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 71 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit problem ------- imo, as the number of messages using pgp (or pgp/mime) for a user increases, the need for a mechanism for protecting the confidentiality of subject lines (i.e. what a user sees as a subject in a mail client) becomes greater. important information is often stored in the subject line and not having a meaningful subject which was specified by the author of the message can be a serious inconvenience to users (e.g. searching, referring to past messages in communication, etc.) -- which may likely lead to a decision on the user's part to go ahead and place sensitive information in the subject line. suggestion ---------- i think it would be a good idea to address this by defining a common specification. afaik, there isn't one yet -- please tell me if you know of one already. i've asked around on a few mailing lists for ideas about this, and, imho, the most promising one i heard was to give meaning to the Content-Description field for a particular mime part. the basic idea is to store the information which would normally be the value of a Subject header as the value of a Content-Description header which is placed in a "to-be-encrypted" text message part. Example: From: Michael Elkins To: Michael Elkins Subject: encrypted in CD: 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 & Content-Type: text/plain & Content-Description: this is the subject the user will see & & here is some message text & & :-) --foo-- where, as in the (open)pgp/mime specification, the ampersands indicate which portion of the text is encrypted. upon/after decryption, mail clients would make an effort to display the contents of the aforementioned Content-Description field in relevant user interface portions (e.g. title of a message window, where subject text might be displayed in a view that listed information about a collection of message [one message per line], etc.). mail clients might also make use of these Content-Description values for the purposes of searching and filtering. how does the basic idea sound? p.s. this idea was originally suggested by Kazu Yamamoto . From owner-ietf-openpgp@mail.imc.org Fri Jun 2 06:02:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26978 for ; Fri, 2 Jun 2000 06:01:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01643 for ietf-openpgp-bks; Fri, 2 Jun 2000 02:39:50 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA01635 for ; Fri, 2 Jun 2000 02:39:48 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A554E1F01C8; Fri, 02 Jun 2000 17:46:12 0800 Message-Id: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 02 Jun 2000 17:40:34 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: easy to understand openpgp book/doc? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, I was wondering if there is a book/document available that basically translates the 2440/2440bis documents into an understandable format. PS: I have an electronic engineering background and extensive experience with Internet protocols, so please, no derogatory remarks :) TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jun 2 06:45:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27593 for ; Fri, 2 Jun 2000 06:45:44 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA07003 for ietf-openpgp-bks; Fri, 2 Jun 2000 03:21:03 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA06998 for ; Fri, 2 Jun 2000 03:21:01 -0700 (PDT) Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Jun 2000 11:28:43 +0100 X-Mailer: exmh version 2.0.2 To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: Your message of "Fri, 02 Jun 2000 18:16:11 +0900." <20000602181611R.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Jun 2000 11:28:41 +0100 Message-ID: <515.959941721@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a really important thing we need to sort out. There was extensive discussion of it almost two years ago (!) but I don't know if that resulted in anything in the PGP/MIME draft. Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last e-mail on the subject, but you can read the discussion in the archives at www.imc.org Ian :) -- Date: Thu, 17 Sep 1998 11:04:15 -0700 (PDT) From: Ned Freed Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages To: Ian Bell Cc: ietf-open-pgp@imc.org, ietf-smime@imc.org > (Apologies if this has been done to death in the past - I can imagine > Ned sighing about protracted discussions prior to RFC1847 - but I > couldn't find any discussion in the archives) > RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only > allow MIME headers to be protected by the encryption process. Was there > any discussion during the preparation of RFC1847 about the possibility / > desirability / feasibility of allowing general RFC822 headers to be > included in the encrypted part of the message? There were extensive discussions of this. I probably have several hundred messages archived on this topic, and there were also WG discussions and several private meetings where the design team covered this area exhaustively. The basic conclusion was (and is) that this dog doesn't hunt and cannot be made to hunt. The problem is that message headers are routinely rewritten by intervening MTAs as messages are transferred via SMTP. They are refolded, reordered, addresses are converted from one form to another, encoded words are added or removed, entire fields are added or deleted. And all these activities are the rule, not the exception. And it is far more likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc, comments, etc. than to any others. In short, if you want to keep the transports from modifying things, you cannot put them in the primary header. You either have to put them in the body. And given this, MIME provides the obvious means to do this if that's what you're after -- nested messages. > The most obvious candidates for headers to be encrypted along with the > MIME headers would be Subject: and Disposition-Notification-To: (the > subject the sender may have intended to use may be too sensitive to use > as the subject of the open message: the sender may want any MDN to be > sent only when the message is decrypted), though cases could probably be > made for just about any RFC822 header. > Could (and should) any replacements for RFC2015 and RFC2311 be amended > to allow RFC822 headers to be sent encrypted, and for the decryption > process to swap any encrypted headers found with the corresponding > headers in the actual message? There is no need to do this. All you need to do is use MIME encapsulation to put the real headers into the body of the message. One thing that would be nice is if there was a way to say in the signature information that the inner message is actually supposed to replace the outer container message. (This could also be done as a parameter to message/rfc822 if need be, although there are arguments for doing it in the signature. There is one other thing that is missing, however, and that is a means of encapsulating the entire message including the envelope. There are many applications where the envelope itself is sensitive and needs end-to-end protection. And there is a proposal on the table to deal with this: draft-freed-bsmtp-02.txt. This defines envelope encapsulation and the semantics that necessarily follow from doing it. > As availability of encryption software becomes more widespread, many > end-users may find SMIME/PGP most useful as simply a transport security > mechanism rather than a way of securely storing messages. In any case, > MUAs implementing PGP or S/MIME probably already allow the user to save > the decrypted version of a message. Sure. > It would be good if there were an interoperable way of making the > stored, decrypted message reflect the message the author would have > liked to send in the first place. It would be particularly nice if the > author could transmit the intended subject of a message when this may be > too sensitive to put in the open message headers. See above. Ned From owner-ietf-openpgp@mail.imc.org Fri Jun 2 06:53:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27675 for ; Fri, 2 Jun 2000 06:53:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA07415 for ietf-openpgp-bks; Fri, 2 Jun 2000 03:29:25 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07410 for ; Fri, 2 Jun 2000 03:29:23 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 4474 invoked from network); 2 Jun 2000 10:32:53 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 2 Jun 2000 10:32:53 -0000 To: ietf-openpgp@imc.org Subject: Re: easy to understand openpgp book/doc? In-Reply-To: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> References: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000602193715H.1001@eccosys.com> Date: Fri, 02 Jun 2000 19:37:15 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: easy to understand openpgp book/doc? Date: Fri, 02 Jun 2000 17:40:34 +0800 Message-ID: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> > I was wondering if there is a book/document available that basically > translates the 2440/2440bis documents into an understandable format. that would be nice to have :-) assuming there isn't one, i'd be interested in participating in creating something along those lines. From owner-ietf-openpgp@mail.imc.org Fri Jun 2 23:07:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21102 for ; Fri, 2 Jun 2000 23:07:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA15018 for ietf-openpgp-bks; Fri, 2 Jun 2000 19:38:23 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15011 for ; Fri, 2 Jun 2000 19:38:22 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQ4YP668LC0004AW@mauve.mrochek.com> for ietf-openpgp@imc.org; Fri, 02 Jun 2000 19:45:58 -0700 (PDT) Date: Fri, 02 Jun 2000 19:44:26 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Fri, 02 Jun 2000 11:28:41 +0100" <515.959941721@cs.ucl.ac.uk> To: Ian BROWN Cc: sen_ml@eccosys.com, ietf-openpgp@imc.org Message-id: <01JQ50WA0ESA0004AW@mauve.mrochek.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <20000602181611R.1001@eccosys.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > This is a really important thing we need to sort out. There was extensive > discussion of it almost two years ago (!) but I don't know if that resulted in > anything in the PGP/MIME draft. > Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last > e-mail on the subject, but you can read the discussion in the archives at > www.imc.org Please note that since this discussion the BSMTP document has come out as RFC 2442. Ned From owner-ietf-openpgp@mail.imc.org Sat Jun 3 00:40:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22003 for ; Sat, 3 Jun 2000 00:40:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA23170 for ietf-openpgp-bks; Fri, 2 Jun 2000 21:20:20 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA23166 for ; Fri, 2 Jun 2000 21:20:19 -0700 (PDT) Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id VAA16139; Fri, 2 Jun 2000 21:28:16 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.7.0.20000602212423.00c71540@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 21:28:13 -0700 To: "William H. Geiger III" From: Dave Crocker Subject: Re: patents? Cc: ietf-openpgp@imc.org In-Reply-To: <200006011849.OAA30158@domains.invweb.net> References: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:08 PM 6/1/00 -0500, William H. Geiger III wrote: >In <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net>, on 05/31/00 > at 06:24 PM, Dave Crocker said: > >You are both being far too optimistic. While it is possible that you are > > correct, it is equally possible -- and many would say more likely -- > >that patents are, in fact, held or being prosecuted. > >Well Dave I know several of the people in the PGP group at NAI and I don't >think that they would allow something like this. And, of course, I was not trying to claim that NAI has any plans or would take such action. For that matter the entire history of PGP leads to the expectation that no such patent action would be taken. However the question was about possibilities and implications, particularly with respect to the import of being late in the standards process. That is, the important piece of information is that there is nothing that *forces* NAI (or any other participant) to disclose patent intent, and there is already some precedent (small pseudo-legal pun intended) for late-stage surfacing. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-ietf-openpgp@mail.imc.org Sat Jun 3 10:23:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06463 for ; Sat, 3 Jun 2000 10:23:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21694 for ietf-openpgp-bks; Sat, 3 Jun 2000 07:01:12 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21689 for ; Sat, 3 Jun 2000 07:01:10 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA13351 for ; Sat, 3 Jun 2000 10:09:10 -0400 Message-Id: <200006031409.KAA13351@domains.invweb.net> From: "William H. Geiger III" Date: Sat, 03 Jun 2000 08:56:32 -0500 To: ietf-openpgp@imc.org Subject: Packet Numbers X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I would like to propose to the list that we reserve a block of packet numbers for future use by NAI's PGP & GNUPG. This would eliminate problems of either of these vendors grabbing packet numbers to use for new packets for production level software (PhotoID packet is a good example). I also propose that in exchange for providing these vendors with a block of packet numbers that they agree to document the packet formats within a time after using them in production level software (six months sound good?). Any packets that a vendor wishes to keep proprietary should stay in the +100 range reserved for experimental packets. tks, -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Sun Jun 4 04:59:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06157 for ; Sun, 4 Jun 2000 04:59:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA14223 for ietf-openpgp-bks; Sun, 4 Jun 2000 01:34:10 -0700 (PDT) Received: from thetis.deor.org ([207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14219 for ; Sun, 4 Jun 2000 01:34:06 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id BAA09512; Sun, 4 Jun 2000 01:42:01 -0700 Date: Sun, 4 Jun 2000 01:41:53 -0700 (PDT) From: "L. Sassaman" To: "William H. Geiger III" cc: ietf-openpgp@imc.org Subject: Re: Packet Numbers In-Reply-To: <200006031409.KAA13351@domains.invweb.net> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this is an excellent idea. However, a few comments: On Sat, 3 Jun 2000, William H. Geiger III wrote: > Hi, > > I would like to propose to the list that we reserve a block of packet > numbers for future use by NAI's PGP & GNUPG. We'll need to propose a method for adding other implementations in the future as well. > This would eliminate problems of either of these vendors grabbing packet > numbers to use for new packets for production level software (PhotoID > packet is a good example). > > I also propose that in exchange for providing these vendors with a block > of packet numbers that they agree to document the packet formats within a > time after using them in production level software (six months sound > good?). 6 months sounds good. The documentation should be a supplimentary RFC. There is no reason to have to rewrite the OpenPGP standard each time. > Any packets that a vendor wishes to keep proprietary should stay in the > +100 range reserved for experimental packets. I would also propose that packet 100 be assigned to X.509 certificates, provided NAI documents this format, and the experimental block be moved to 101 --> 110. I also propose that no implementation should use an experimental packet in a production state (these should be for testing only!) - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5OhZYPYrxsgmsCmoRAiyPAJ4xwGoqwhIH5cGdhCRdWAQLI4EIJwCglrTz k99dQtFPKxtK2WWT0LACZlo= =Il53 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Jun 4 23:07:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13199 for ; Sun, 4 Jun 2000 23:07:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21156 for ietf-openpgp-bks; Sun, 4 Jun 2000 19:46:16 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21152 for ; Sun, 4 Jun 2000 19:46:14 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17770 invoked from network); 5 Jun 2000 02:49:48 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 5 Jun 2000 02:49:48 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQ50WA0ESA0004AW@mauve.mrochek.com> References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> <01JQ50WA0ESA0004AW@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000605115419X.1001@eccosys.com> Date: Mon, 05 Jun 2000 11:54:19 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Fri, 02 Jun 2000 19:44:26 -0700 (PDT) Message-ID: <01JQ50WA0ESA0004AW@mauve.mrochek.com> > Please note that since this discussion the BSMTP document has come out as > RFC 2442. so, if i understand the idea correctly, header protection can be had by having mail clients support bsmtp processing: sending side 1) create a message 2) create a bsmtp object out of the message (encapsulate) 3) encrypt (and optionally sign) 4) send the message receiving side 4) receive the message 5) decrypt (and optionally verify signature) 6) extract (recreate) the original message from the bsmtp object 7) read as usual does that sound about right? From owner-ietf-openpgp@mail.imc.org Mon Jun 5 00:27:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13933 for ; Mon, 5 Jun 2000 00:27:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27886 for ietf-openpgp-bks; Sun, 4 Jun 2000 21:05:02 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27882 for ; Sun, 4 Jun 2000 21:05:00 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQ7WFK047K0001I2@mauve.mrochek.com> for ietf-openpgp@imc.org; Sun, 04 Jun 2000 21:12:45 -0700 (PDT) Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Mon, 05 Jun 2000 11:54:19 +0900" <20000605115419X.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQ7WIKK0280001I2@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> <01JQ50WA0ESA0004AW@mauve.mrochek.com> <01JQ50WA0ESA0004AW@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Please note that since this discussion the BSMTP document has come out as > > RFC 2442. > so, if i understand the idea correctly, header protection can be had > by having mail clients support bsmtp processing: > sending side > 1) create a message > 2) create a bsmtp object out of the message (encapsulate) > 3) encrypt (and optionally sign) > 4) send the message > receiving side > 4) receive the message > 5) decrypt (and optionally verify signature) > 6) extract (recreate) the original message from the bsmtp object > 7) read as usual > does that sound about right? Yes, except that the protection extends to the envelope when you use BSMTP. If all you want to protect is the header it is easier to just use a message/rfc822 MIME encapsulation. Ned From owner-ietf-openpgp@mail.imc.org Mon Jun 5 00:55:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14062 for ; Mon, 5 Jun 2000 00:55:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA28099 for ietf-openpgp-bks; Sun, 4 Jun 2000 21:30:07 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA28094 for ; Sun, 4 Jun 2000 21:30:05 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A14E17E301FC; Mon, 05 Jun 2000 12:36:46 0800 Message-Id: <4.3.0.20000605122801.00b96b10@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 05 Jun 2000 12:30:59 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Quick Triple-DES Q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for use in the OpenPGP standard? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jun 5 01:23:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16575 for ; Mon, 5 Jun 2000 01:23:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28468 for ietf-openpgp-bks; Sun, 4 Jun 2000 22:00:08 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA28463 for ; Sun, 4 Jun 2000 22:00:06 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20591 invoked from network); 5 Jun 2000 05:03:42 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 5 Jun 2000 05:03:42 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQ7WIKK0280001I2@mauve.mrochek.com> References: <01JQ50WA0ESA0004AW@mauve.mrochek.com> <20000605115419X.1001@eccosys.com> <01JQ7WIKK0280001I2@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000605140812F.1001@eccosys.com> Date: Mon, 05 Jun 2000 14:08:12 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 47 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT) Message-ID: <01JQ7WIKK0280001I2@mauve.mrochek.com> ... > > does that sound about right? > > Yes, except that the protection extends to the envelope when you use BSMTP. > If all you want to protect is the header it is easier to just use a > message/rfc822 MIME encapsulation. so to protect the confidentiality of the Subject header: sending side 1) create a rfc 822 message (contains Subject) 2) mime encapsulate the message 3) encrypt (and optionally sign) 4) send the message receiving side 5) receive the message 6) decrypt (and optionally verify signature) 7) extract (recreate) the original message 8) read as usual (can see the Subject) right? if there is no better method yet, imo, it would be a good idea for this method of protecting headers to receive some kind of "endorsement" (e.g. mentioned in the openpgp/mime or some other spec for instance -- a separate document is may be too much, but who knows). also, i noticed the following statement in a past (septemeber 17th 1998) post by you in the archives: There are many applications where the envelope itself is sensitive and needs end-to-end protection. but i did not notice any concrete examples of such applications. would you mind mentioning a few? http://www.imc.org/ietf-open-pgp/mail-archive/msg01941.html From owner-ietf-openpgp@mail.imc.org Mon Jun 5 01:25:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16914 for ; Mon, 5 Jun 2000 01:25:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA28424 for ietf-openpgp-bks; Sun, 4 Jun 2000 21:58:47 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA28420 for ; Sun, 4 Jun 2000 21:58:45 -0700 (PDT) Received: from [63.73.97.184] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0); Sun, 4 Jun 2000 22:06:47 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.0.20000605122801.00b96b10@mail.comasp.com> References: <4.3.0.20000605122801.00b96b10@mail.comasp.com> Date: Sun, 4 Jun 2000 22:06:45 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Quick Triple-DES Q Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:30 PM +0800 6/5/00, Erron Criddle wrote: >To all, > >Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for >use in the OpenPGP standard? > No, they haven't. On the other hand, since they have utterly nothing to do with Triple-DES, there's no need for them to. Triple-DES is a completely open algorithm, which is why OpenPGP, as well as many other IETF standards, use it. Jon From owner-ietf-openpgp@mail.imc.org Mon Jun 5 02:21:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26443 for ; Mon, 5 Jun 2000 02:21:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00145 for ietf-openpgp-bks; Sun, 4 Jun 2000 22:57:03 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA00139 for ; Sun, 4 Jun 2000 22:57:00 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5AE79C02A4; Mon, 05 Jun 2000 14:03:42 0800 Message-Id: <4.3.0.20000605135243.00b94ee0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 05 Jun 2000 13:57:54 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: Quick Triple-DES Q In-Reply-To: References: <4.3.0.20000605122801.00b96b10@mail.comasp.com> <4.3.0.20000605122801.00b96b10@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 22:06 4/06/00 -0700, Jon Callas wrote: >At 12:30 PM +0800 6/5/00, Erron Criddle wrote: > >To all, > > > >Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for > >use in the OpenPGP standard? > > > >No, they haven't. On the other hand, since they have utterly nothing to do >with Triple-DES, there's no need for them to. Triple-DES is a completely >open algorithm, which is why OpenPGP, as well as many other IETF standards, >use it. Oh, sorry... I remember reading somewhere about RSA providing payment/royalty free access one of their algorithms and I thought it was for OpenPGP... Must have been something else :) As for linking Triple-DES with RSA - well, I certainly don't know where that came from :) Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jun 5 08:02:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29544 for ; Mon, 5 Jun 2000 08:02:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09886 for ietf-openpgp-bks; Mon, 5 Jun 2000 04:33:36 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09882 for ; Mon, 5 Jun 2000 04:33:35 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12yvFU-0001YC-00; Mon, 05 Jun 2000 13:40:52 +0200 To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: <200005312321.QAA13118@finney.org> From: Florian Weimer Date: 05 Jun 2000 13:40:52 +0200 In-Reply-To: hal@finney.org's message of "Wed, 31 May 2000 16:21:12 -0700" Message-ID: Lines: 53 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org writes: > The purpose of Alice's signature was to identify Bob, not to say that > he is trustworthy. I am the one who made that latter determination. > Given that Alice at one time certified Bob's identity, the fact that her > certification has expired doesn't change the fact that I still trust him. If a certification grants access to some resource, access should certainly be denied if the certification expires. (Perhaps this is a bad example, because this is quite easy to enforce during implementation because it only affects the "server" side, not the "client" side, where many OpenPGP implementations might coexist, while there's only one server protecting that specific resource.) A better example: the CA of an organization signs the public key of one of its members, knowing the member will perhaps leave the organization in, say, 6 months. So the CA lets the signature expire in 6 months. (If he's still around at that time, his key will get just another certificate.) According to the CA policy, a key certification implies the statement that the key owner is a member of said organization. If the signature expires and doesn't become invalid automatically, the CA still has to issue a revocation certificate to ensure that it's really invalid on all clients. If the organization has got a considerable member fluctuation, this will result in a quickly growing certificate revocation list (CRL) which mainly contains redundant information (the signatures are expired anyway). > In at least some cases, then, it might be reasonable to continue to use > expired signatures in trust calculation. But the user has to be notified that an expired signature was involved at some point. I don't it's a good idea to hide this fact. On the other hand, the user should be able to verify a signature which was made some time ago, and some links in the chain of trust to the signing key have expired since. (Internally, we call this the "time-travel" feature.) If the user trusts the signer not to issue bogus signatures, this feature is very helpful, even though OpenPGP doesn't provide safe timestamps. I think we can agree that the decision whether expired certificates should be part of validity calculations or not cannot be decided mechanically. Since the message format specification shouldn't assume interactive implementations, we have to make a decision here. My instincts say the safe alternative (i.e. expired certificates are ignored) should be chosen. (And our CRL wouldn't grow as fast as it would without this additional requirement. ;) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 From owner-ietf-openpgp@mail.imc.org Tue Jun 6 04:19:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29768 for ; Tue, 6 Jun 2000 04:19:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA13212 for ietf-openpgp-bks; Tue, 6 Jun 2000 00:52:51 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA13208 for ; Tue, 6 Jun 2000 00:52:48 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A25515DB0292; Tue, 06 Jun 2000 15:59:33 0800 Message-Id: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 06 Jun 2000 15:52:16 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 3.6.1.3 Clarification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Just to make sure I understand before we code, two options are available per instance (I am also not taking into consideration multiple instances when the hash bit count is smaller than the required key length). Consider the two options: 1) A simple salt + iteration: count=20 bytes salt=12 bytes pass phrase=12 bytes from this, we simply do: hash (salt + pass phrase) where: salt=12 bytes pass phrase=12 bytes 2) A concatenated salt + iteration: count=40 bytes salt=12 bytes pass phrase=12 bytes from this, we simply do: hash(salt(0) + pp(0) + salt(1) + pp(1)) where: salt(0)=12 bytes pass phrase (0)=12 bytes salt (1)=12 bytes pass phrase(1)=left 4 bytes of the 12 byte pass phrase Is this correct, or have I got it wrong? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Tue Jun 6 05:57:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00370 for ; Tue, 6 Jun 2000 05:57:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA18649 for ietf-openpgp-bks; Tue, 6 Jun 2000 02:34:01 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA18645 for ; Tue, 6 Jun 2000 02:33:59 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 18468 invoked from network); 6 Jun 2000 09:37:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jun 2000 09:37:36 -0000 To: ietf-openpgp@imc.org Subject: Re: 3.6.1.3 Clarification In-Reply-To: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> References: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000606184211H.1001@eccosys.com> Date: Tue, 06 Jun 2000 18:42:11 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: 3.6.1.3 Clarification Date: Tue, 06 Jun 2000 15:52:16 +0800 Message-ID: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> > Just to make sure I understand before we code, two options are available > per instance (I am also not taking into consideration multiple instances > when the hash bit count is smaller than the required key length). Consider > the two options: > > 1) A simple salt + iteration: > > count=20 bytes > salt=12 bytes > pass phrase=12 bytes > > from this, we simply do: > > hash (salt + pass phrase) > > where: > > salt=12 bytes > pass phrase=12 bytes this looks correct to me. it fulfills the "has at least one complete salt + passphrase" requirement. > 2) A concatenated salt + iteration: > > count=40 bytes > salt=12 bytes > pass phrase=12 bytes > > from this, we simply do: > > hash(salt(0) + pp(0) + salt(1) + pp(1)) > > where: > > salt(0)=12 bytes > pass phrase (0)=12 bytes > salt (1)=12 bytes > pass phrase(1)=left 4 bytes of the 12 byte pass phrase this looks correct to me as well. it fulfills the "assuming at least one complete salt + passphrase will be hashed, hash exactly count bytes" requirement. for reference, there was discussion of this area of the rfc recently, and i submitted candidate alternate phrasing for this section. you can find that at: http://www.imc.org/ietf-openpgp/mail-archive/msg03156.html From owner-ietf-openpgp@mail.imc.org Tue Jun 6 21:35:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21579 for ; Tue, 6 Jun 2000 21:35:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA24191 for ietf-openpgp-bks; Tue, 6 Jun 2000 18:04:21 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24182 for ; Tue, 6 Jun 2000 18:04:20 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQADWFKSA800088W@mauve.mrochek.com> for ietf-openpgp@imc.org; Tue, 06 Jun 2000 18:12:28 -0700 (PDT) Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Mon, 05 Jun 2000 14:08:12 +0900" <20000605140812F.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQAISQBPXO00088W@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQ50WA0ESA0004AW@mauve.mrochek.com> <20000605115419X.1001@eccosys.com> <01JQ7WIKK0280001I2@mauve.mrochek.com> <01JQ7WIKK0280001I2@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: ned.freed@innosoft.com > Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? > Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT) > Message-ID: <01JQ7WIKK0280001I2@mauve.mrochek.com> > ... > > > does that sound about right? > > > > Yes, except that the protection extends to the envelope when you use BSMTP. > > If all you want to protect is the header it is easier to just use a > > message/rfc822 MIME encapsulation. > so to protect the confidentiality of the Subject header: > sending side > 1) create a rfc 822 message (contains Subject) > 2) mime encapsulate the message > 3) encrypt (and optionally sign) > 4) send the message > receiving side > 5) receive the message > 6) decrypt (and optionally verify signature) > 7) extract (recreate) the original message > 8) read as usual (can see the Subject) > right? > if there is no better method yet, imo, it would be a good idea for > this method of protecting headers to receive some kind of > "endorsement" (e.g. mentioned in the openpgp/mime or some other spec > for instance -- a separate document is may be too much, but who > knows). > also, i noticed the following statement in a past (septemeber 17th > 1998) post by you in the archives: > There are many applications where the envelope itself is sensitive and > needs end-to-end protection. > but i did not notice any concrete examples of such applications. would you > mind mentioning a few? Two words: traffic analysis. Knowing who's getting a message is often enough to tell you something even if the contents are obscured. Ned From owner-ietf-openpgp@mail.imc.org Tue Jun 6 22:01:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22615 for ; Tue, 6 Jun 2000 22:01:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA29980 for ietf-openpgp-bks; Tue, 6 Jun 2000 18:31:09 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA29969 for ; Tue, 6 Jun 2000 18:31:06 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 1684 invoked from network); 7 Jun 2000 01:34:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 7 Jun 2000 01:34:45 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQAISQBPXO00088W@mauve.mrochek.com> References: <01JQ7WIKK0280001I2@mauve.mrochek.com> <20000605140812F.1001@eccosys.com> <01JQAISQBPXO00088W@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000607103920M.1001@eccosys.com> Date: Wed, 07 Jun 2000 10:39:20 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit thanks for the clarification. From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT) Message-ID: <01JQAISQBPXO00088W@mauve.mrochek.com> > Two words: traffic analysis. Knowing who's getting a message is > often enough to tell you something even if the contents are > obscured. sure. so the "There are many applications" statement referred to applications where the traffic analysis of envelope information is relevant. is that a reasonable interpretation? also, did you have other things in mind? assuming envelope information is protected using rfc 2442, is there a recommended mechanism for actually getting the encapsulated message to the receiving end? not anonymous remailers... i suppose one of these days we'll end up seeing all anonymous remailer functionality provided via several standards documents...i think that leaves: splitting messages up into equal size pieces (+ reassembly on the receiving end of course), sending cover traffic, pooling message pieces, making message pieces traverse different paths...am i missing anything? :-) From owner-ietf-openpgp@mail.imc.org Wed Jun 7 00:09:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24738 for ; Wed, 7 Jun 2000 00:09:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19944 for ietf-openpgp-bks; Tue, 6 Jun 2000 20:46:10 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19926 for ; Tue, 6 Jun 2000 20:46:08 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQANTYB4I80007JQ@mauve.mrochek.com> for ietf-openpgp@imc.org; Tue, 06 Jun 2000 20:54:15 -0700 (PDT) Date: Tue, 06 Jun 2000 20:48:38 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Wed, 07 Jun 2000 10:39:20 +0900" <20000607103920M.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQ7WIKK0280001I2@mauve.mrochek.com> <20000605140812F.1001@eccosys.com> <01JQAISQBPXO00088W@mauve.mrochek.com> <01JQAISQBPXO00088W@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > thanks for the clarification. > From: ned.freed@innosoft.com > Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? > Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT) > Message-ID: <01JQAISQBPXO00088W@mauve.mrochek.com> > > Two words: traffic analysis. Knowing who's getting a message is > > often enough to tell you something even if the contents are > > obscured. > sure. so the "There are many applications" statement referred to > applications where the traffic analysis of envelope information is > relevant. is that a reasonable interpretation? also, did you have > other things in mind? Signing the envelope also has its applications -- it prevents some forms of envelope tampering that might otherwise be used in some sorts of attacks. > assuming envelope information is protected using rfc 2442, is there a > recommended mechanism for actually getting the encapsulated message > to the receiving end? not anonymous remailers... Recommended, no. In practice regular SMTP is often used, in effect creating a variety of secure tunnel. Ned From owner-ietf-openpgp@mail.imc.org Wed Jun 7 16:14:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19843 for ; Wed, 7 Jun 2000 16:14:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14514 for ietf-openpgp-bks; Wed, 7 Jun 2000 12:35:30 -0700 (PDT) Received: from rgate.ricochet.net (rgate.ricochet.net [204.179.143.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14509 for ; Wed, 7 Jun 2000 12:35:28 -0700 (PDT) Received: from workstation.tillerman.to (mg-20425424-61.ricochet.net [204.254.24.61]) by rgate.ricochet.net (8.9.3/8.9.3) with ESMTP id OAA17798; Wed, 7 Jun 2000 14:41:12 -0500 (CDT) Message-Id: <4.3.2.6.2.20000607123431.00b23ae0@module-two.rwthayer.com> X-Sender: rodney@module-two.rwthayer.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Wed, 07 Jun 2000 12:35:17 -0700 To: Dave Crocker , ietf-openpgp@imc.org From: Rodney Thayer Subject: Re: patents? In-Reply-To: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> References: <4.3.2.6.2.20000531164608.02e00a50@module-two.rwthayer.com> <200005312006.QAA26250@domains.invweb.net> <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, but after the RFC has a number and after there is widespread common use of a technology goes over into the "they never enforced their patent" area. I mostly said what I said to shake any stealth lawyers out of the trees, which seems to not have happened. One can never stop scanning for submarine patents. they pop at the most annoying times... At 05:24 PM 5/31/00 -0700, Dave Crocker wrote: >At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote: >>Being as no evil lawyers from NAI or elsewhere have swooped down on this >>list or on the IETF I'd say it's safe for now. >> >>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >>>Probably just standard boilerplate. They are just putting you on notice >>>that by publishing their source code they are not giving up any rights >>>that the may hold on the code. > >You are both being far too optimistic. While it is possible that you are >correct, it is equally possible -- and many would say more likely -- that >patents are, in fact, held or being prosecuted. > >The IETF has had some patents emerge very late in the process, so the >concern is not academic. > >d/ > > >=-=-=-=-= >Dave Crocker >Brandenburg Consulting >Tel: +1.408.246.8253, Fax: +1.408.273.6464 >675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-ietf-openpgp@mail.imc.org Thu Jun 8 01:06:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27406 for ; Thu, 8 Jun 2000 01:05:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24278 for ietf-openpgp-bks; Wed, 7 Jun 2000 21:40:21 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA24267 for ; Wed, 7 Jun 2000 21:40:19 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 27040 invoked from network); 8 Jun 2000 04:44:00 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 8 Jun 2000 04:43:59 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> References: <01JQAISQBPXO00088W@mauve.mrochek.com> <20000607103920M.1001@eccosys.com> <01JQAOGAY4ES0007JQ@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000608134840J.1001@eccosys.com> Date: Thu, 08 Jun 2000 13:48:40 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Tue, 06 Jun 2000 20:48:38 -0700 (PDT) Message-ID: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> ... > > assuming envelope information is protected using rfc 2442, is there a > > recommended mechanism for actually getting the encapsulated message > > to the receiving end? not anonymous remailers... > > Recommended, no. In practice regular SMTP is often used, in effect creating a > variety of secure tunnel. i see that the MAIL FROM info for the container message can be made different from the corresponding information in the bsmtp object w/o having adverse affects on delivery. for RCPT TO though, the best i've come up w/ so far is to specify an address that forwards received messages to other forwarders or to the ultimate recipient. is it possible to do better than this? what am i missing? thanks for bearing w/ me. p.s. is this an appropriate place to discuss rfc 2442? if not, is there some other place? From owner-ietf-openpgp@mail.imc.org Thu Jun 8 01:35:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01618 for ; Thu, 8 Jun 2000 01:35:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA27503 for ietf-openpgp-bks; Wed, 7 Jun 2000 22:09:41 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA27499 for ; Wed, 7 Jun 2000 22:09:40 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQBUZBCTDC0009XA@mauve.mrochek.com> for ietf-openpgp@imc.org; Wed, 07 Jun 2000 22:17:58 -0700 (PDT) Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Thu, 08 Jun 2000 13:48:40 +0900" <20000608134840J.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQC5NHEOFM0009XA@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQAISQBPXO00088W@mauve.mrochek.com> <20000607103920M.1001@eccosys.com> <01JQAOGAY4ES0007JQ@mauve.mrochek.com> <01JQAOGAY4ES0007JQ@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > i see that the MAIL FROM info for the container message can be made > different from the corresponding information in the bsmtp object w/o > having adverse affects on delivery. > for RCPT TO though, the best i've come up w/ so far is to specify an > address that forwards received messages to other forwarders or to the > ultimate recipient. is it possible to do better than this? The RCPT TO needs to be the address of the BSMTP processor. You can have a single processor for a large number of individual users, and if you do this, you cannot tell from the outer envelope what user is being sent to. Not knowing the specific user makes traffic analysis a heck of a lot harder. Ned From owner-ietf-openpgp@mail.imc.org Thu Jun 8 12:48:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11767 for ; Thu, 8 Jun 2000 12:48:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28648 for ietf-openpgp-bks; Thu, 8 Jun 2000 09:08:38 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28631 for ; Thu, 8 Jun 2000 09:08:29 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3IFA62U@mta5.rcsntx.swbell.net> for ietf-openpgp@imc.org; Thu, 8 Jun 2000 11:05:52 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:52 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-openpgp@imc.org Message-id: <0FVU00DK7FDP2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-ietf-openpgp@mail.imc.org Thu Jun 8 23:59:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23617 for ; Thu, 8 Jun 2000 23:59:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06771 for ietf-openpgp-bks; Thu, 8 Jun 2000 20:29:29 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA06755 for ; Thu, 8 Jun 2000 20:29:25 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 18899 invoked from network); 9 Jun 2000 03:33:08 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 9 Jun 2000 03:33:08 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQC5NHEOFM0009XA@mauve.mrochek.com> References: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> <20000608134840J.1001@eccosys.com> <01JQC5NHEOFM0009XA@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000609123752V.1001@eccosys.com> Date: Fri, 09 Jun 2000 12:37:52 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT) Message-ID: <01JQC5NHEOFM0009XA@mauve.mrochek.com> > > for RCPT TO though, the best i've come up w/ so far is to specify an > > address that forwards received messages to other forwarders or to the > > ultimate recipient. is it possible to do better than this? > > The RCPT TO needs to be the address of the BSMTP processor. hmm, so making the RCPT TO (of the outer envelope) an address that will forward to the address of the BSMTP processor won't work? i don't understand why. what am i missing? > You can have a single processor for a large number of individual > users, and if you do this, you cannot tell from the outer envelope > what user is being sent to. Not knowing the specific user makes > traffic analysis a heck of a lot harder. yes, i suppose it does increase the amount of work that must be done -- i guess that amount is related to how much use the bsmtp processor is getting and by how many users. so there should be incentive to use a processor that is heavily used and by a lot of users. i suppose one can place encrypted bsmtp objects inside of bsmtp objects and do chaining of bsmtp processors... thanks very much for the explanations. p.s. does anyone know of any bsmtp processor implementations? From owner-ietf-openpgp@mail.imc.org Fri Jun 9 00:56:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23901 for ; Fri, 9 Jun 2000 00:56:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA10731 for ietf-openpgp-bks; Thu, 8 Jun 2000 21:29:20 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10723 for ; Thu, 8 Jun 2000 21:29:19 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQBUZBCTDC0009XA@mauve.mrochek.com> for ietf-openpgp@imc.org; Thu, 08 Jun 2000 21:37:44 -0700 (PDT) Date: Thu, 08 Jun 2000 21:27:45 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Fri, 09 Jun 2000 12:37:52 +0900" <20000609123752V.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQDIJWZ2LC0009XA@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> <20000608134840J.1001@eccosys.com> <01JQC5NHEOFM0009XA@mauve.mrochek.com> <01JQC5NHEOFM0009XA@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: ned.freed@innosoft.com > Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? > Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT) > Message-ID: <01JQC5NHEOFM0009XA@mauve.mrochek.com> > > > for RCPT TO though, the best i've come up w/ so far is to specify an > > > address that forwards received messages to other forwarders or to the > > > ultimate recipient. is it possible to do better than this? > > > > The RCPT TO needs to be the address of the BSMTP processor. > hmm, so making the RCPT TO (of the outer envelope) an address that > will forward to the address of the BSMTP processor won't work? i > don't understand why. what am i missing? Nothing; it can be any address that gets to the processor. Any amount of aliasing or forwarding is fine. But the more actual recipients associated with a single outer address, the better. > p.s. does anyone know of any bsmtp processor implementations? There are a bunch, although many of them are likely not in full compliance with the RFC, which specifies support for certain aspects of ESMTP. Remember, the entire BITNET network was implemented using BSMTP to get around the 8X8 address limit of NJE. In its heyday BITNET amounted to several thousand systems running on a variety of hardware and software platforms. One implementation that is up to date is the one in PMDF, which is descended from our BITNET handling code. The same code is also in SIMS. I also doubt if we would have written the specification had we not had an actual implementation in hand. The BITNET experience showed that turning an interactive protocol into a batch protocol has some subtle spots to it. Ned From owner-ietf-openpgp@mail.imc.org Fri Jun 9 09:26:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11176 for ; Fri, 9 Jun 2000 09:26:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13639 for ietf-openpgp-bks; Fri, 9 Jun 2000 05:49:40 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13635 for ; Fri, 9 Jun 2000 05:49:38 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id NAA13232; Fri, 9 Jun 2000 13:58:06 +0100 (BST) Message-ID: Date: Fri, 9 Jun 2000 13:55:44 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> In-Reply-To: <515.959941721@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2 Jun 2000, Ian BROWN wrote: >This is a really important thing we need to sort out. There was extensive >discussion of it almost two years ago (!) but I don't know if that resulted in >anything in the PGP/MIME draft. > >Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last >e-mail on the subject, but you can read the discussion in the archives at >www.imc.org So far in this thread, two methods of encrypting headers have been discussed: encapsulating a complete message in a message/rfc822 and encapsulating an SMTP session in BSMTP. Both can be used for end-to-end encryption and the first probably inter-operates quite well amongst existing PGP/MIME or S/MIME clients. However, encrypting message headers could also be potentially useful for protecting stored messages as well, but here the message/rfc822 solution is not so useful (and BSMTP not appropriate at all). For instance, an IMAP client may want to allow its users to encrypt all messages being archived on an IMAP server in order to protect the user against any server security event. It could do this by encapsulating existing messages in a message/rfc822 and holding the resulting encrypted message in a vanilla outer message header (e.g. no subject, all addressees set to the user themselves etc...). However if this is done to lots of messages, the problem arises that the user won't be able to distinguish between messages without the client downloading and decrypting all messages (including bodies) first! Two things seem to be needed to usefully support this sort of stored message encryption: the ability of a client to know that there are some replacement headers in an encrypted message and the ability of the client to decrypt those headers independently of the body. This could be accomplished using an unencrypted multipart message, where the first part could hold the headers (text/rfc822-headers, encrypted using PGP/MIME or S/MIME) and the second part could hold the body (again encrypted). If a new type were defined (multipart/rfc822?), an IMAP client could recognize the top level Content-Type, download and decrypt the secure headers and thereafter display the decrypted header information to the user. Just an idea, but without something like this, re-encrypting messages for storage involves either making the user enter alternative header details, or not securing the headers in the first place. -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Sun Jun 11 21:35:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10775 for ; Sun, 11 Jun 2000 21:35:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA26999 for ietf-openpgp-bks; Sun, 11 Jun 2000 18:07:11 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA26988 for ; Sun, 11 Jun 2000 18:07:09 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 7728 invoked from network); 12 Jun 2000 01:10:56 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 12 Jun 2000 01:10:56 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQDIJWZ2LC0009XA@mauve.mrochek.com> References: <01JQC5NHEOFM0009XA@mauve.mrochek.com> <20000609123752V.1001@eccosys.com> <01JQDIJWZ2LC0009XA@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000612101549S.1001@eccosys.com> Date: Mon, 12 Jun 2000 10:15:49 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 33 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Thu, 08 Jun 2000 21:27:45 -0700 (PDT) Message-ID: <01JQDIJWZ2LC0009XA@mauve.mrochek.com> ... > > p.s. does anyone know of any bsmtp processor implementations? > > There are a bunch, although many of them are likely not in full compliance > with the RFC, which specifies support for certain aspects of ESMTP. > Remember, the entire BITNET network was implemented using BSMTP to get > around the 8X8 address limit of NJE. In its heyday BITNET amounted to > several thousand systems running on a variety of hardware and software > platforms. i was an email-only user (i.e. not a user w/ administrative knowledge) when i was using bitnet, so i cannot claim to have any in-depth knowledge. thanks for the explanation though. > One implementation that is up to date is the one in PMDF, which is descended > from our BITNET handling code. The same code is also in SIMS. thank you very much for the pointers. > I also doubt if we would have written the specification had we not had an > actual implementation in hand. The BITNET experience showed that turning an > interactive protocol into a batch protocol has some subtle spots to it. in your opinion, are those subtle spots adequately and comprehensively covered in the rfc? i ask because if bsmtp encapsulation is to become widely used (assuming here that it isn't at the moment), it seems to me that there may have to be a few more implementations. From owner-ietf-openpgp@mail.imc.org Sun Jun 11 21:55:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11720 for ; Sun, 11 Jun 2000 21:55:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA02108 for ietf-openpgp-bks; Sun, 11 Jun 2000 18:41:25 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA02097 for ; Sun, 11 Jun 2000 18:41:23 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 8101 invoked from network); 12 Jun 2000 01:35:49 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 12 Jun 2000 01:35:49 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000612104040U.1001@eccosys.com> Date: Mon, 12 Jun 2000 10:40:40 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 58 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Ian Bell Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Fri, 9 Jun 2000 13:55:44 +0100 Message-ID: > So far in this thread, two methods of encrypting headers have been > discussed: encapsulating a complete message in a message/rfc822 and > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > encryption and the first probably inter-operates quite well amongst > existing PGP/MIME or S/MIME clients. > > However, encrypting message headers could also be potentially useful for > protecting stored messages as well, but here the message/rfc822 solution > is not so useful (and BSMTP not appropriate at all). i used to think this might be a good idea, but i started thinking that encrypting filesystems or directories where the messages are stored (on the server end in your imap example) might be a better solution. on the other hand, messages are sometimes stored w/in databases...unless most databases support the notion of encrypting records, i guess this could be problematic in that case, but may be databases should support encryption/decryption. > For instance, an IMAP client may want to allow its users to encrypt all > messages being archived on an IMAP server in order to protect the user > against any server security event. right, so you can protect against having the message contents revealed and w/ signing against message content being tampered w/. not to say this idea isn't useful, but i don't know how to protect against deletion. > It could do this by encapsulating existing messages in a > message/rfc822 and holding the resulting encrypted message in a > vanilla outer message header (e.g. no subject, all addressees set to > the user themselves etc...). > > However if this is done to lots of messages, the problem arises that the > user won't be able to distinguish between messages without the client > downloading and decrypting all messages (including bodies) first! another approach: encrypted messages a user receives could initially be decrypted on the client end, modified to a decrypted form and placed again on the server (whether they replace the original messages could be a policy decision). the server could implement confidentiality services through local store (e.g. filesystem, directory, etc.) encryption -- a key for decryption could be requested from the user during imap authentication (or computed using authentication info). all messages for a given user on the server end could then be protected using this key. before imap (or pop) processing occurs, messages are decrypted. when the processing is complete (e.g. imap session ends), messages are encrypted. From owner-ietf-openpgp@mail.imc.org Sun Jun 11 22:44:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12981 for ; Sun, 11 Jun 2000 22:44:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08350 for ietf-openpgp-bks; Sun, 11 Jun 2000 19:29:25 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08346 for ; Sun, 11 Jun 2000 19:29:23 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQHKG7A3OG000E2F@mauve.mrochek.com> for ietf-openpgp@imc.org; Sun, 11 Jun 2000 19:28:42 -0700 (PDT) Date: Sun, 11 Jun 2000 19:26:42 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Mon, 12 Jun 2000 10:15:49 +0900" <20000612101549S.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQHKWZDEDI000E2F@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQC5NHEOFM0009XA@mauve.mrochek.com> <20000609123752V.1001@eccosys.com> <01JQDIJWZ2LC0009XA@mauve.mrochek.com> <01JQDIJWZ2LC0009XA@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > There are a bunch, although many of them are likely not in full compliance > > with the RFC, which specifies support for certain aspects of ESMTP. > > Remember, the entire BITNET network was implemented using BSMTP to get > > around the 8X8 address limit of NJE. In its heyday BITNET amounted to > > several thousand systems running on a variety of hardware and software > > platforms. > i was an email-only user (i.e. not a user w/ administrative knowledge) > when i was using bitnet, so i cannot claim to have any in-depth > knowledge. thanks for the explanation though. > > One implementation that is up to date is the one in PMDF, which is descended > > from our BITNET handling code. The same code is also in SIMS. > thank you very much for the pointers. > > I also doubt if we would have written the specification had we not had an > > actual implementation in hand. The BITNET experience showed that turning an > > interactive protocol into a batch protocol has some subtle spots to it. > in your opinion, are those subtle spots adequately and comprehensively > covered in the rfc? Yes they are. Indeed, this was the entire point of writing the RFC -- to explain how this can be done and what the issues are with doing it. > i ask because if bsmtp encapsulation is to become > widely used (assuming here that it isn't at the moment), it seems to > me that there may have to be a few more implementations. Frankly, I doubt if it will ever be widely used. But writing the document seemed to be useful given that there have been a fair number of implementations in the past and they didn't get it right without a specification. Ned From owner-ietf-openpgp@mail.imc.org Sun Jun 11 23:16:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13199 for ; Sun, 11 Jun 2000 23:16:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12057 for ietf-openpgp-bks; Sun, 11 Jun 2000 19:57:22 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA12053 for ; Sun, 11 Jun 2000 19:57:19 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A40611C80298; Mon, 12 Jun 2000 10:55:18 PDT Message-Id: <4.3.0.20000612103737.00b404f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 12 Jun 2000 10:47:37 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Hidden session key generation & storage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, This is only slightly related to PGP, however: I was wondering if there is some "standard" out there that defines how a session key is stored/saved/hidden after a file is encrypted and stored on a computer system using the same key. Ideally, the only thing that *should* be able to decrypt the file is the same computer program that generated the key. You can play around with binary files, the XOR function, CRC checks, Hashing algorithms and a host of other "tricks" to "make life very difficult" for the reverse engineer, however is there a 100% secure way for an executable to encrypt and store data (to be decrypted later on by the same program)? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jun 12 10:57:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03325 for ; Mon, 12 Jun 2000 10:57:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA03235 for ietf-openpgp-bks; Mon, 12 Jun 2000 07:39:04 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03231 for ; Mon, 12 Jun 2000 07:39:02 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitgs04238; Mon, 12 Jun 2000 14:38:12 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27156; Mon, 12 Jun 00 10:34:35 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA04839; Mon, 12 Jun 2000 10:38:11 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14660.62930.973835.485437@xedia.com> Date: Mon, 12 Jun 2000 10:38:10 -0400 (EDT) To: ejc@comasp.com Cc: ietf-openpgp@imc.org Subject: Re: Hidden session key generation & storage References: <4.3.0.20000612103737.00b404f0@mail.comasp.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Erron" == Erron Criddle writes: Erron> To all, This is only slightly related to PGP, however: Erron> I was wondering if there is some "standard" out there that Erron> defines how a session key is stored/saved/hidden after a file Erron> is encrypted and stored on a computer system using the same Erron> key. Ideally, the only thing that *should* be able to decrypt Erron> the file is the same computer program that generated the key. No. Done correctly, the only way to decrypt the file is for the human who owns the key to supply that key. That is the PGP way... Erron> You can play around with binary files, the XOR function, CRC Erron> checks, Hashing algorithms and a host of other "tricks" to Erron> "make life very difficult" for the reverse engineer, however Erron> is there a 100% secure way for an executable to encrypt and Erron> store data (to be decrypted later on by the same program)? No, there is not. That's why programs that offer real security DO NOT DO THIS. If you see a program that does do this -- i.e., can decrypt your encrypted file without asking you for the key -- then it is by definition insecure and should be thrown in the garbage can. paul From owner-ietf-openpgp@mail.imc.org Tue Jun 13 03:12:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00191 for ; Tue, 13 Jun 2000 03:12:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA27336 for ietf-openpgp-bks; Mon, 12 Jun 2000 23:52:03 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA27326 for ; Mon, 12 Jun 2000 23:51:58 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AC8237AB0298; Tue, 13 Jun 2000 14:49:54 PDT Message-Id: <4.3.0.20000613142845.00b5ef00@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 13 Jun 2000 14:42:07 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Open-PGP Q re DSA and keys > 1024 bit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Upon reading 2440bis re DSA and a PGP key length limit of 1024 bits, I was wondering what the Open-PGP group recommends for signing if you use PGP keys > 1024 bits? If you do use PGP Keys > 1024 bits, should you have another set of keys <=1024 bits for signing or is there a standard way to reduce 2048 bit PGP keys down to 1024 bits suitable for the DSA signature algorithm? TIA for any info. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Wed Jun 14 22:46:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09807 for ; Wed, 14 Jun 2000 22:46:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08411 for ietf-openpgp-bks; Wed, 14 Jun 2000 19:24:04 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08396 for ; Wed, 14 Jun 2000 19:23:59 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0CBC66027A; Thu, 15 Jun 2000 10:22:19 PDT Message-Id: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 15 Jun 2000 10:14:25 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Is there a fully searchable Open-PGP Archive? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Does anyone know of a fully searchable Open-PGP archive? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Thu Jun 15 16:13:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13777 for ; Thu, 15 Jun 2000 16:13:00 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00977 for ietf-openpgp-bks; Thu, 15 Jun 2000 12:47:01 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00973 for ; Thu, 15 Jun 2000 12:46:59 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 6040 invoked from network); 15 Jun 2000 19:41:34 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2000 19:41:34 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000616044636N.1001@eccosys.com> Date: Fri, 16 Jun 2000 04:46:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Ian Bell Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Fri, 9 Jun 2000 13:55:44 +0100 Message-ID: > On Fri, 2 Jun 2000, Ian BROWN wrote: > >This is a really important thing we need to sort out. There was extensive > >discussion of it almost two years ago (!) but I don't know if that resulted in > >anything in the PGP/MIME draft. > > > >Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last > >e-mail on the subject, but you can read the discussion in the archives at > >www.imc.org > > So far in this thread, two methods of encrypting headers have been > discussed: encapsulating a complete message in a message/rfc822 and > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > encryption and the first probably inter-operates quite well amongst > existing PGP/MIME or S/MIME clients. at this point, i'd like to see the methods mentioned/referred to in some specification so i can point mail client developers at such a document for the purposes of having them work on implementations that will interoperate. even w/ some kind of endorsement in the form of being present in a specification, it may take a while for header (and/or envelope) protection to be implemented at the user-level -- i.e. there is a single command a user can use to create such header-protected messages. so, any plans or takers on this point? From owner-ietf-openpgp@mail.imc.org Thu Jun 15 16:13:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13788 for ; Thu, 15 Jun 2000 16:13:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00903 for ietf-openpgp-bks; Thu, 15 Jun 2000 12:43:09 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00899 for ; Thu, 15 Jun 2000 12:43:07 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 5987 invoked from network); 15 Jun 2000 19:37:41 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2000 19:37:41 -0000 To: ietf-openpgp@imc.org Subject: Re: Is there a fully searchable Open-PGP Archive? In-Reply-To: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> References: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000616044243R.1001@eccosys.com> Date: Fri, 16 Jun 2000 04:42:43 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: Is there a fully searchable Open-PGP Archive? Date: Thu, 15 Jun 2000 10:14:25 +0800 Message-ID: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> > Does anyone know of a fully searchable Open-PGP archive? i don't know of one. i'd be glad to be informed of one. in the mean time, i suppose the "entire archive" (perhaps it's in two pieces now?) mentioned at: http://www.imc.org/ietf-openpgp/ can be downloaded and searched locally... From owner-ietf-openpgp@mail.imc.org Thu Jun 15 17:10:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14621 for ; Thu, 15 Jun 2000 17:10:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA03625 for ietf-openpgp-bks; Thu, 15 Jun 2000 13:53:21 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03621 for ; Thu, 15 Jun 2000 13:53:19 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA04662; Thu, 15 Jun 2000 13:52:59 -0700 Date: Thu, 15 Jun 2000 13:52:59 -0700 Message-Id: <200006152052.NAA04662@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > So far in this thread, two methods of encrypting headers have been > > discussed: encapsulating a complete message in a message/rfc822 and > > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > > encryption and the first probably inter-operates quite well amongst > > existing PGP/MIME or S/MIME clients. > > at this point, i'd like to see the methods mentioned/referred to in > some specification so i can point mail client developers at such a > document for the purposes of having them work on implementations that > will interoperate. I don't see what any of this has to do with OpenPGP. Modifying SMTP is clearly out of our scope, and message/rfc822 is already defined in the MIME spec. We don't have anything to do with this, and IMO this discussion should be transferred elsewhere. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Jun 15 17:23:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14801 for ; Thu, 15 Jun 2000 17:23:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA03911 for ietf-openpgp-bks; Thu, 15 Jun 2000 14:04:41 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA03907 for ; Thu, 15 Jun 2000 14:04:38 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 7357 invoked from network); 15 Jun 2000 20:59:13 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2000 20:59:13 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <200006152052.NAA04662@finney.org> References: <200006152052.NAA04662@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000616060416X.1001@eccosys.com> Date: Fri, 16 Jun 2000 06:04:16 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 46 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Thu, 15 Jun 2000 13:52:59 -0700 Message-ID: <200006152052.NAA04662@finney.org> > > > So far in this thread, two methods of encrypting headers have been > > > discussed: encapsulating a complete message in a message/rfc822 and > > > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > > > encryption and the first probably inter-operates quite well amongst > > > existing PGP/MIME or S/MIME clients. > > > > at this point, i'd like to see the methods mentioned/referred to in > > some specification so i can point mail client developers at such a > > document for the purposes of having them work on implementations that > > will interoperate. > > I don't see what any of this has to do with OpenPGP. Modifying SMTP > is clearly out of our scope, and message/rfc822 is already defined in > the MIME spec. We don't have anything to do with this, and IMO this > discussion should be transferred elsewhere. i think an important point is that if you look at the openpgp/mime spec or the openpgp spec as they stand now, they don't explicitly mention either of the methods for protecting header information of messages. at least i didn't notice any mention of them...perhaps i miseed something? last i checked, the headers are part of the message -- if one of the goals of openpgp/mime is to protect message confidentiality, then i think it's relevant to at least mention the aforementioned methods in one of the openpgp specs. how many mail clients claim pgp/mime compatibility? http://www.cryptorights.org/pgp-users/pgp-mail-clients.html how many of those protect message headers? there may be a few, but i have yet to encouter one. i think this is a problem that could be addressed by placing a disucssion of the issue in an existing spec or to create a new spec for that purpose. it is far more likely for header protection to be implemented that way. we may disagree about how important header protection is, but it seems pretty related to openpgp (at least openpgp/mime) to me. From owner-ietf-openpgp@mail.imc.org Thu Jun 15 18:45:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16661 for ; Thu, 15 Jun 2000 18:45:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA05383 for ietf-openpgp-bks; Thu, 15 Jun 2000 15:28:30 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05378 for ; Thu, 15 Jun 2000 15:28:28 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA05145 for ietf-openpgp@imc.org; Thu, 15 Jun 2000 15:28:08 -0700 Date: Thu, 15 Jun 2000 15:28:08 -0700 Message-Id: <200006152228.PAA05145@finney.org> To: ietf-openpgp@imc.org Subject: Revised MDC packet spec Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Based on internal discussions we would like to make a small change to the Symmetrically Encrypted Integrity Protected Data Packet format. We would like to include the random bytes which precede the plaintext in the hash. This will make the hash value less predictable and would make an attacker's job harder. It is also somewhat simpler conceptually because now the material which is hashed is the same as the material which is encrypted, except for the last 20 bytes. Also Werner pointed out a typo in the previous draft, the 0xD0 value should be 0xD3 to match the MDC packet CTB. The revised draft follows. Hal Finney PGP.COM ============ 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18) The Symmetrically Encrypted Integrity Protected Data packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The last such decrypted packet must be a Modification Detection Code packet. The body of this packet consists of: - A one-octet version number. The only currently defined value is 1. - Encrypted data, the output of the selected symmetric-key cipher operating in Cipher Feedback mode with shift amount equal to the block size of the cipher (CFB-n where n is the block size). The symmetric cipher used MUST be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data Packet. In either case, the cipher algorithm octet is prefixed to the session key before it is encrypted. The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes an octet string to the data before it is encrypted. The length of the octet string equals the block size of the cipher in octets, plus two. The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet. For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectivelly. Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data. The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. Specifically, the input to the hash function includes the prefix octet string described above (equal in length to the cipher block size, plus two octets), followed by all of the plaintext, and then also two octets of values 0xD3, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets. The resulting hash value is stored in a Modification Detection Code packet which MUST use the two octet encoding just given to represent its tag and length field. The body of the MDC packet is the 20 octet output of the SHA-1 hash. The Modification Detection Code packet is appended to the plaintext and encrypted along with the plaintext using the same CFB context. During decryption, the decrypted data should be hashed with SHA-1, including the prefix octet string, the plaintext itself and also the packet tag and length field of the Modification Detection Code packet. The body of the MDC packet, upon decryption, should be compared with the result of the SHA-1 hash. Any difference in hash values is an indication that the message has been modified and SHOULD be reported to the user. Likewise, the absence of an MDC packet, or an MDC packet in any position other than the end of the plaintext, also represent message modifications and SHOULD also be reported. Note: future designs of new versions of this packet should consider rollback attacks since it will be possible for an attacker to change the version back to 1. 5.Y Modification Detection Code Packet (Tag 19) The Modification Detection Code packet contains a SHA-1 hash of plaintext data which is used to detect message modification. It is only used in the context of a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data which is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place. A Modification Detection Code packet MUST have a length of 20 octets. The body of this packet consists of: - A 20-octet SHA-1 hash of the preceding plaintext data of the Symmetrically Encrypted Integrity Protected Data packet, not including prefix data but including the tag and length byte of the Modification Detection Code packet. Note that the Modification Detection Code packet MUST always use a new-format encoding of the packet tag, and a one-octet encoding of the packet length. (These requirements are already imposed by the rules for tag and length encoding.) From owner-ietf-openpgp@mail.imc.org Fri Jun 16 03:57:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07414 for ; Fri, 16 Jun 2000 03:57:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18544 for ietf-openpgp-bks; Fri, 16 Jun 2000 00:31:40 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18531 for ; Fri, 16 Jun 2000 00:31:37 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 132qlu-0000el-00; Fri, 16 Jun 2000 09:42:34 +0200 Date: Fri, 16 Jun 2000 09:42:34 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Revised MDC packet spec Message-ID: <20000616094234.F2464@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200006152228.PAA05145@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <200006152228.PAA05145@finney.org>; from hal@finney.org on Thu, Jun 15, 2000 at 03:28:08PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, On Thu, 15 Jun 2000, hal@finney.org wrote: > Based on internal discussions we would like to make a small change to > the Symmetrically Encrypted Integrity Protected Data Packet format. This is fine with me. One suggestion: Add a note that the old PGP sync mode is not used with the wew packet 18. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Fri Jun 16 17:08:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24526 for ; Fri, 16 Jun 2000 17:08:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24199 for ietf-openpgp-bks; Fri, 16 Jun 2000 13:53:29 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24195 for ; Fri, 16 Jun 2000 13:53:27 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id QAA04999 for ; Fri, 16 Jun 2000 16:53:12 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id QAA16185 for ietf-openpgp@imc.org; Fri, 16 Jun 2000 16:53:10 -0400 Date: Fri, 16 Jun 2000 16:53:09 -0400 From: Tom Zerucha To: ietf-openpgp@imc.org Subject: Re: Revised MDC packet spec Message-ID: <20000616165309.A16176@deimos.mw.mediaone.net> References: <200006152228.PAA05145@finney.org> <20000616094234.F2464@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000616094234.F2464@djebel.gnupg.de>; from wk@gnupg.org on Fri, Jun 16, 2000 at 09:42:34AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 16, 2000 at 09:42:34AM +0200, Werner Koch wrote: > Hi, > > On Thu, 15 Jun 2000, hal@finney.org wrote: > > > Based on internal discussions we would like to make a small change to > > the Symmetrically Encrypted Integrity Protected Data Packet format. > > This is fine with me. > > One suggestion: Add a note that the old PGP sync mode is not used with > the wew packet 18. Did I miss something? The description of the new type 18 packet indicates a prefix that looks like the PGP-sync prefix used elsewhere. But I didn't see the resync operation that is done everywhere else (I didn't read that carefully). So if I understand correctly, we are going to use the prefix but NOT going to do the resync? From owner-ietf-openpgp@mail.imc.org Fri Jun 16 17:54:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25826 for ; Fri, 16 Jun 2000 17:54:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24689 for ietf-openpgp-bks; Fri, 16 Jun 2000 14:40:22 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24685 for ; Fri, 16 Jun 2000 14:40:21 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id OAA08433; Fri, 16 Jun 2000 14:40:07 -0700 Date: Fri, 16 Jun 2000 14:40:07 -0700 Message-Id: <200006162140.OAA08433@finney.org> To: ietf-openpgp@imc.org, tz@execpc.com Subject: Re: Revised MDC packet spec Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tom writes, quoting Werner: > > One suggestion: Add a note that the old PGP sync mode is not used with > > the wew packet 18. > > Did I miss something? The description of the new type 18 packet > indicates a prefix that looks like the PGP-sync prefix used elsewhere. > > But I didn't see the resync operation that is done everywhere else (I > didn't read that carefully). > > So if I understand correctly, we are going to use the prefix but NOT > going to do the resync? That's correct. This is for two reasons: one is that the sync is nonstandard and has caused problems. Perhaps someday we can deprecate the old symmetric encryption packet and eliminate the sync altogether. The second reason is to make the encrypted data in these packets more different from the data in the old packets, making it less likely that an attacker could turn a new packet into an old one. Maybe as Werner said the spec should have an explicit note confirming that the sync is not done in this packet. Hal From owner-ietf-openpgp@mail.imc.org Fri Jun 16 21:08:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29594 for ; Fri, 16 Jun 2000 21:08:19 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA26531 for ietf-openpgp-bks; Fri, 16 Jun 2000 17:56:42 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26527 for ; Fri, 16 Jun 2000 17:56:41 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA09930 for ; Fri, 16 Jun 2000 17:55:58 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA09926 for ; Fri, 16 Jun 2000 17:55:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200006162140.OAA08433@finney.org> References: <200006162140.OAA08433@finney.org> Date: Fri, 16 Jun 2000 17:38:28 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Revised MDC packet spec Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Or maybe we should just do the sync anyway. It's one thing to not be standard, but it's another to not be consistent. The only thing that one can complain about PGP-CFB for is that it's not standard CFB. I don't see that as an issue. Other systems, like CMS, use CBC mode not CFB at all, so we're no less different even if we switch. I would prefer to keep one encryption mode and use it everywhere. The one to use, is of course PGP-CFB. However, if we're going to change it, we should discuss using CBC mode. Jon From owner-ietf-openpgp@mail.imc.org Sat Jun 17 01:47:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09304 for ; Sat, 17 Jun 2000 01:47:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA01373 for ietf-openpgp-bks; Fri, 16 Jun 2000 22:25:47 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01368 for ; Fri, 16 Jun 2000 22:25:46 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id BAA00906; Sat, 17 Jun 2000 01:25:33 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id BAA18954; Sat, 17 Jun 2000 01:25:24 -0400 Date: Sat, 17 Jun 2000 01:25:24 -0400 From: Tom Zerucha To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Revised MDC packet spec Message-ID: <20000617012524.A18894@deimos.mw.mediaone.net> References: <200006162140.OAA08433@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jon@callas.org on Fri, Jun 16, 2000 at 05:38:28PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 16, 2000 at 05:38:28PM -0700, Jon Callas wrote: > Or maybe we should just do the sync anyway. > > It's one thing to not be standard, but it's another to not be consistent. > The only thing that one can complain about PGP-CFB for is that it's not > standard CFB. I don't see that as an issue. > > Other systems, like CMS, use CBC mode not CFB at all, so we're no less > different even if we switch. > > I would prefer to keep one encryption mode and use it everywhere. The one > to use, is of course PGP-CFB. However, if we're going to change it, we > should discuss using CBC mode. I agree with this since I separate the operators from the core, though cfb mode is one of the standard calls in openssl. For all else I have a cfbomatic routine. However wasn't there something about NOT resetting if the block length for the cipher was over 9 bytes in length? Let me bring up another consideration (while looking for the above). 3.6.2.1... These are followed by an 8-octet Initial Vector for the decryption of the secret values, if they are encrypted, and then the secret key values themselves. 5.5.3... - [Optional] If secret data is encrypted, eight-octet Initial Vector (IV). and With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block bou The symmetric ciphers are used more than one place - one is for unlocking secret keys, and we have resyncs here. So what happens for secret keys using a cipher with a 128 bit block size? Do we use 16 octet IVs? Do we resync on mpi boundaries for a V3 key (is this possible - I don't see anywhere in the spec where it says you MUST use IDEA to encrypt V3 secret key material)? (Actually I have a problem in my current opgp implementation since I don't support block sizes other than 8 bytes (no, I refuse to always use "octet"), but as soon as I can get the new algorithms going I know where and how to fix it). From owner-ietf-openpgp@mail.imc.org Mon Jun 19 18:03:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24380 for ; Mon, 19 Jun 2000 18:03:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28005 for ietf-openpgp-bks; Mon, 19 Jun 2000 14:39:14 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28000 for ; Mon, 19 Jun 2000 14:39:11 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id XAA25275 for ; Mon, 19 Jun 2000 23:38:31 +0200 (MET DST) Received: from ppp62.stud.tu-darmstadt.de (ppp62.stud.tu-darmstadt.de [130.83.177.62]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id XAA23811 for ; Mon, 19 Jun 2000 23:39:04 +0200 (MET DST) Received: id ; Mon, 19 Jun 2000 16:45:48 +0200 (CEST) Message-Id: Date: Mon, 19 Jun 2000 16:45:48 +0200 (CEST) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: References: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: L. Sassaman : > [...] Expanding from the right is less natural to users whose language > reads from left to right, in my opinion. Have you used a telephone lately? From owner-ietf-openpgp@mail.imc.org Mon Jun 19 21:45:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27811 for ; Mon, 19 Jun 2000 21:45:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA07664 for ietf-openpgp-bks; Mon, 19 Jun 2000 18:30:22 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA07654 for ; Mon, 19 Jun 2000 18:30:19 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ABEF2560204; Tue, 20 Jun 2000 09:29:35 0800 Message-Id: <4.3.0.20000620091941.00b43240@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Jun 2000 09:20:57 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Open-PGP Q re DSA and keys > 1024 bit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Upon reading 2440bis re DSA and a ElGamal key length limit of 1024 bits, I was wondering what the Open-PGP group recommends for signing if you use ElGamal keys > 1024 bits? If you do use ElGamal Keys > 1024 bits, should you have another set of keys <=1024 bits for signing or is there a standard way to reduce 2048 bit PGP keys down to 1024 bits suitable for the DSA signature algorithm? TIA for any info. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Tue Jun 20 05:33:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15738 for ; Tue, 20 Jun 2000 05:33:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA15968 for ietf-openpgp-bks; Tue, 20 Jun 2000 02:16:18 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA15962 for ; Tue, 20 Jun 2000 02:16:15 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A925662020C; Tue, 20 Jun 2000 17:15:33 0800 Message-Id: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Jun 2000 17:06:51 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Do sigs. on encoded data confirm to OpenPGP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Has anyone thought about this: If I am to produce a signature on a 100 MByte file (for example), unless I produce the signature from the encrypted (and encoded?) file, the receiver would have to decrypt the entire 100MByte file just to verify a signature that may be invalid! Would it be possible (to alleviate this situation), to: 1) Compress Plaintext 2) Encrypt Plaintext 3) Encode the file (if necessary) 4) Produce Signature 5) Encrypt Signature (using same session key as in 2?) 6) Encrypt session key using receiver's public key. Detached signatures are mentioned in 10.3 from 2440 that may address this situation, however there are no specific details on this methodology. When the e-mail is received, the following would occur: 1) Decryption of session key (using private key) 2) Decryption of signature (using private key) 3) Run hashing algorithm and DSA over the encrypted/encoded data 4) Compare sigs and either discard or decrypt to the original plaintext. This way, the receiver doesn't have to decrypt a 100 MByte file just to verify a signature that may be invalid! I know you can use a single pass signature to speed up the process of decryption etc, however you still have to decrypt to the original plain-text and that seems to be a waste of time if the sigs don't match. If someone could advise on a solution they may have come across whereby you do not have to decrypt/decode just to verify a signature, it would be much appreciated. TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Tue Jun 20 09:28:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21198 for ; Tue, 20 Jun 2000 09:28:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA03956 for ietf-openpgp-bks; Tue, 20 Jun 2000 06:10:49 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03947 for ; Tue, 20 Jun 2000 06:10:45 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 134Nmb-0002Ui-00 for ietf-openpgp@imc.org; Tue, 20 Jun 2000 15:09:37 +0200 To: ietf-openpgp@imc.org Subject: Signature subpacket clarification From: Florian Weimer Date: 20 Jun 2000 15:09:37 +0200 Message-ID: Lines: 38 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The phrase "MUST be present in the hashed area." has to be added to the following sections: 5.2.3.4. Signature creation time 5.2.3.6. Key expiration time 5.2.3.10. Signature expiration time 5.2.3.12. Revocable 5.2.3.13. Trust signature 5.2.3.14. Regular expression 5.2.3.15. Revocation key 5.2.3.17. Key server preferences 5.2.3.19. Primary user id 5.2.3.21. Key Flags 5.2.3.22. Signer's User ID 5.2.3.23. Reason for Revocation I'm not sure about the following (GnuPG puts them into the hashed area): 5.2.3.7. Preferred symmetric algorithms 5.2.3.8. Preferred hash algorithms 5.2.3.9. Preferred compression algorithms Hash protection is obviously not needed for: 5.2.3.5. Issuer 5.2.3.11. Exportable Certification 5.2.3.18. Preferred key server (resolving URLs isn't secure anyway) 5.2.3.20. Policy URL (ditto) Whether notation data has to be put into the hashed area depends on that data, of course. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 From owner-ietf-openpgp@mail.imc.org Tue Jun 20 09:59:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22250 for ; Tue, 20 Jun 2000 09:59:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA05793 for ietf-openpgp-bks; Tue, 20 Jun 2000 06:41:29 -0700 (PDT) Received: from alcove.wittsend.com (IDENT:root@alcove.wittsend.com [130.205.0.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05789 for ; Tue, 20 Jun 2000 06:41:27 -0700 (PDT) Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id IAA04974; Tue, 20 Jun 2000 08:41:05 -0400 Date: Tue, 20 Jun 2000 08:41:05 -0400 From: "Michael H. Warfield" To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: Quick Triple-DES Q Message-ID: <20000620084105.A2730@alcove.wittsend.com> References: <4.3.0.20000605122801.00b96b10@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: <4.3.0.20000605122801.00b96b10@mail.comasp.com>; from ejc@comasp.com on Mon, Jun 05, 2000 at 12:30:59PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jun 05, 2000 at 12:30:59PM +0800, Erron Criddle wrote: > To all, > Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for > use in the OpenPGP standard? AFAIK, RSA has no IP encumberances on DES or 3-DES what so ever. The patent on the RSA algorithm expires in a few months at which time RSA labs loses their IP encumberance on that. > TIA. > Regards > Erron Criddle > Comasp Ltd. > ACN: 089 468 682 > Level 2, 45 Stirling Hwy > NEDLANDS WA 6009 > Australia > > Fax: +61 8 9386 9473 > Tel: +61 8 9386 9534 > Mob: +414/0414 800 888 > > ejc@comasp.com > http://www.comasp.com > > -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! From owner-ietf-openpgp@mail.imc.org Tue Jun 20 23:14:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10213 for ; Tue, 20 Jun 2000 23:14:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA09026 for ietf-openpgp-bks; Tue, 20 Jun 2000 19:52:00 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA09013 for ; Tue, 20 Jun 2000 19:51:57 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20815 invoked from network); 21 Jun 2000 02:46:42 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 21 Jun 2000 02:46:42 -0000 To: ietf-openpgp@imc.org Subject: Re: Do sigs. on encoded data confirm to OpenPGP? In-Reply-To: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> References: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000621115201G.1001@eccosys.com> Date: Wed, 21 Jun 2000 11:52:01 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: Do sigs. on encoded data confirm to OpenPGP? Date: Tue, 20 Jun 2000 17:06:51 +0800 Message-ID: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> > Has anyone thought about this: > > If I am to produce a signature on a 100 MByte file (for example), unless I > produce the signature from the encrypted (and encoded?) file, the receiver > would have to decrypt the entire 100MByte file just to verify a signature > that may be invalid! i'm a little fuzzy at this time of day, but isn't there some sort of attack that's possible if you sign some encrypted data? perhaps someone else who is more awake can confirm ;-) From owner-ietf-openpgp@mail.imc.org Thu Jun 22 14:53:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12990 for ; Thu, 22 Jun 2000 14:53:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24883 for ietf-openpgp-bks; Thu, 22 Jun 2000 11:31:23 -0700 (PDT) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24879 for ; Thu, 22 Jun 2000 11:31:22 -0700 (PDT) Received: from mwyoung.transarc.com (1Cust204.tnt8.lax3.da.uu.net [63.23.75.204]) by snipe.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id LAA21165 for ; Thu, 22 Jun 2000 11:31:37 -0700 (PDT) Message-ID: <001801bfdc77$b075eac0$cc4b173f@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: Revised MDC packet spec Date: Thu, 22 Jun 2000 14:28:35 -0400 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.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >Or maybe we should just do the sync anyway. I would normally be in favor maintaining the traditional resync, since it's code any implementation has to have anyway, but here it would open up a huge hole. An attacker could easily convert a new SEIP data packet into an old SE data packet by replacing the header+version and tearing off the known-sized MDC packet at the end. Depending on the difference in resync mode alone doesn't feel good to me, though. Perhaps Hal could elaborate on the internal discussions that motivate including the block+2 pad in the hash. If you don't need the block+2 pad in the hash, then you could just use another level of nested packet, something like: Symmetrically-Encrypted-Packet { block+2 pad MDC-packet { arbitrary-packet // compressed or literal hash } } I would find another nesting level much easier to implement in a pipelined receiver. To implement the latest (non-nested) proposal, an inner packet-parsing loop would need access to context from the outer reading logic, which is not nearly as natural. Looking through the archive, I see Tom Zerucha proposed bracketing with two new packets, but I haven't seen this nested approach mentioned. It's quite possible I've just missed it -- there's been a lot for me to catch up on -- so if it's been discussed, can someone point me at the messages? From owner-ietf-openpgp@mail.imc.org Thu Jun 22 17:15:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15825 for ; Thu, 22 Jun 2000 17:15:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27353 for ietf-openpgp-bks; Thu, 22 Jun 2000 13:56:06 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27348 for ; Thu, 22 Jun 2000 13:56:05 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id NAA31903; Thu, 22 Jun 2000 13:38:02 -0700 Date: Thu, 22 Jun 2000 13:37:49 -0700 (PDT) From: "L. Sassaman" To: Bodo Moeller cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 19 Jun 2000, Bodo Moeller wrote: > L. Sassaman : > > > [...] Expanding from the right is less natural to users whose language > > reads from left to right, in my opinion. > > Have you used a telephone lately? That's a non sequitor if I have ever seen one... __ L. Sassaman System Administrator | "If you chose not to decide, Technology Consultant | you still have made a choice" icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Rush -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5UnkmPYrxsgmsCmoRArMBAJ4tqPqkwGNp5a2ggFcGDz3/l15R2QCg9EQ5 14IcTnfJiTJw6NDSF8jXExA= =co+4 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jun 22 22:34:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20501 for ; Thu, 22 Jun 2000 22:34:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10907 for ietf-openpgp-bks; Thu, 22 Jun 2000 19:16:12 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA10901 for ; Thu, 22 Jun 2000 19:16:10 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10367 invoked from network); 23 Jun 2000 02:11:00 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Jun 2000 02:11:00 -0000 To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: References: X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000623111625T.1001@eccosys.com> Date: Fri, 23 Jun 2000 11:16:25 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "L. Sassaman" Subject: Re: KeyID as left vs right substring of fingerprint Date: Thu, 22 Jun 2000 13:37:49 -0700 (PDT) Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 19 Jun 2000, Bodo Moeller wrote: > > > L. Sassaman : > > > > > [...] Expanding from the right is less natural to users whose language > > > reads from left to right, in my opinion. > > > > Have you used a telephone lately? > > That's a non sequitor if I have ever seen one... i didn't understand the remark about the telephone. does it have to do w/ a touch pad or display or numbers on a screen? perhaps the original poster could elaborate? From owner-ietf-openpgp@mail.imc.org Fri Jun 23 02:18:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04554 for ; Fri, 23 Jun 2000 02:18:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA24400 for ietf-openpgp-bks; Thu, 22 Jun 2000 23:01:20 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24392 for ; Thu, 22 Jun 2000 23:01:18 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id IAA19294; Fri, 23 Jun 2000 08:00:45 +0200 (MET DST) Received: from ppp343.stud.tu-darmstadt.de (ppp343.stud.tu-darmstadt.de [130.83.176.94]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id IAA10066; Fri, 23 Jun 2000 08:01:28 +0200 (MET DST) Received: id ; Fri, 23 Jun 2000 07:59:55 +0200 (CEST) Date: Fri, 23 Jun 2000 07:59:55 +0200 From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: "L. Sassaman" Cc: Bodo Moeller , ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000623075954.A4134@epsilon> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from rabbi@quickie.net on Thu, Jun 22, 2000 at 01:37:49PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 22, 2000 at 01:37:49PM -0700, L. Sassaman wrote: > On Mon, 19 Jun 2000, Bodo Moeller wrote: >> L. Sassaman : >>> [...] Expanding from the right is less natural to users whose language >>> reads from left to right, in my opinion. >> Have you used a telephone lately? > That's a non sequitor if I have ever seen one... Dialing certain postfixes of a given phone number can work, dialing any prefix won't. That is, phone numbers expand from the right. I haven't yet heard of anyone complaing about this on the grounds that thear language reads from left to right. From owner-ietf-openpgp@mail.imc.org Fri Jun 23 03:44:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05084 for ; Fri, 23 Jun 2000 03:44:04 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA26778 for ietf-openpgp-bks; Fri, 23 Jun 2000 00:21:29 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26773 for ; Fri, 23 Jun 2000 00:21:28 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA03289; Fri, 23 Jun 2000 00:08:09 -0700 Date: Fri, 23 Jun 2000 00:07:57 -0700 (PDT) From: "L. Sassaman" To: Bodo Moeller cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <20000623075954.A4134@epsilon> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 23 Jun 2000, Bodo Moeller wrote: > On Thu, Jun 22, 2000 at 01:37:49PM -0700, L. Sassaman wrote: > > On Mon, 19 Jun 2000, Bodo Moeller wrote: > >> L. Sassaman : > > >>> [...] Expanding from the right is less natural to users whose language > >>> reads from left to right, in my opinion. > > >> Have you used a telephone lately? > > > That's a non sequitor if I have ever seen one... > > Dialing certain postfixes of a given phone number can work, dialing > any prefix won't. That is, phone numbers expand from the right. > I haven't yet heard of anyone complaing about this on the grounds that > thear language reads from left to right. That's an invalid analogy. Telephone prefixes exist so that phone numbers can be grouped seperately. There is no such grouping with OpenPGP key ideas -- all key ids are members of one group. In a left to right most-significant-bit key id expansion, if the 32 or 64 bits you provided weren't enough, you could keep adding more until a match was found. In a left to right least-signification-bit expansion, you would have to start over with the new information. This is all academic, however, since I think we decided that changing this now would be worse than leaving it the way it is. __ L. Sassaman System Administrator | "If you chose not to decide, Technology Consultant | you still have made a choice" icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Rush -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5UwzZPYrxsgmsCmoRAiE9AKDQSEgF2hMJlE1Niwdb3oL+X1Q5VQCg/AA3 rMeJBPdynBM7rI6CrWSB7TU= =W8Or -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jun 23 06:31:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06169 for ; Fri, 23 Jun 2000 06:31:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05829 for ietf-openpgp-bks; Fri, 23 Jun 2000 03:13:10 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA05817 for ; Fri, 23 Jun 2000 03:13:04 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB03696024A; Fri, 23 Jun 2000 18:12:35 0800 Message-Id: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 23 Jun 2000 18:03:40 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: V4 signature Q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was wondering if someone could please clarify something (again :) : Regarding a V4 signature; 5.2.3 states that the third octec of a signature contains the public key algorithm. Would it be correct for me to say that the values of the 3rd octec of a signature packet can contain either: 1 - RSA (Encrypt or sign) 3 - RSA (sign only) 17 - DSA 20 - ElGamal (encrypt or sign) I'm trying to work out where the digital signature algorithm is specified in the signature and this is the only place I can see it fitting. thank you in advance for any answers... Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jun 23 08:46:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08642 for ; Fri, 23 Jun 2000 08:46:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12420 for ietf-openpgp-bks; Fri, 23 Jun 2000 05:32:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA12413 for ; Fri, 23 Jun 2000 05:32:54 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 22347 invoked from network); 23 Jun 2000 12:27:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Jun 2000 12:27:45 -0000 To: ietf-openpgp@imc.org Subject: Re: V4 signature Q In-Reply-To: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> References: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000623213312C.1001@eccosys.com> Date: Fri, 23 Jun 2000 21:33:12 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 33 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: V4 signature Q Date: Fri, 23 Jun 2000 18:03:40 +0800 Message-ID: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> > Regarding a V4 signature; > > 5.2.3 states that the third octec of a signature contains the public key > algorithm. Would it be correct for me to say that the values of the 3rd > octec of a signature packet can contain either: > > 1 - RSA (Encrypt or sign) > 3 - RSA (sign only) > 17 - DSA > 20 - ElGamal (encrypt or sign) > > I'm trying to work out where the digital signature algorithm is specified > in the signature and this is the only place I can see it fitting. the location looks correct to me for specifying the public key algorithm portion of specifying the method of computation of the digital signature. i think the hash algorithm is also relevant as it is also part of the process of computing a signature...but it's the next octet over anyway ;-) note the comment in section 12.4 regarding rsa sign-only keys that says: There are algorithm types for RSA-signature-only, and RSA-encrypt- only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, and generalizes it to all algorithms. An implementation SHOULD NOT create such a key, but MAY interpret it. From owner-ietf-openpgp@mail.imc.org Sun Jun 25 01:16:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21548 for ; Sun, 25 Jun 2000 01:16:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA17728 for ietf-openpgp-bks; Sat, 24 Jun 2000 21:57:59 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA17719 for ; Sat, 24 Jun 2000 21:57:55 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A42C3150024A; Sun, 25 Jun 2000 12:57:32 0800 Message-Id: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 25 Jun 2000 12:48:32 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: OpenPGP should be called ClosedPGP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all that can (well most): Just e-mailing to say that I am appalled at the helpfulness of this list; I have been involved with the Internet for six years now and have also been involved with other standards, lists and discussion forums and this is the most "closed" list I have ever come across! After literally many hours of research, I have come across only one document that explains part of 2440 in a understandable format and that is: http://www.openpgp.net/pgpemail_toc.html I have also noticed there is a book called: OpenPGP Specification & Sample Code; ISBN: 1583680144; by Jon Callas... however, upon e-mailing the author for instructions on how to obtain the book and visits to www.cryptography.org and www.pibooks.com to purchase it (found URL's in openpgp archives), I am still left wondering whether the book actually exists! Come on people who are developing this standard - if you want it to take off, help people and/or make something available to people like me and other project directors so we can develop the OpenPGP standard and not get bogged down cryptanalysing the 2440 document into plain text! PS: Thanks to those who have responded to my e-mails - it certainly has confirmed many things I was unsure of regarding OpenPGP. PSS: Ignore this message if the MITM is blocking everyone's answers to my e-mails :) Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jun 26 11:58:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09190 for ; Mon, 26 Jun 2000 11:58:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12824 for ietf-openpgp-bks; Mon, 26 Jun 2000 08:32:21 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12815 for ; Mon, 26 Jun 2000 08:32:19 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 136b5X-0006rN-00; Mon, 26 Jun 2000 17:46:19 +0200 Date: Mon, 26 Jun 2000 17:46:19 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000626174619.F26051@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <4.3.0.20000625121620.00ba26c0@mail.comasp.com>; from ejc@comasp.com on Sun, Jun 25, 2000 at 12:48:32PM +0800 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 25 Jun 2000, Erron Criddle wrote: > After literally many hours of research, I have come across only one > document that explains part of 2440 in a understandable format and that is: OpenPGP is quite complex (but not as complex as some other protocols), so it takes a while to understand all the details. A lot of things have been explained on this mailing list here more than one time. Have a look at the archives. And there are at least 3 implementations which you can consult to check how a detail is actually done. > Come on people who are developing this standard - if you want it to take > off, help people and/or make something available to people like me and PGP is around for nearly a decade now. OpenPGP is just an enhancement on the PGP 2 data formats. > other project directors so we can develop the OpenPGP standard and not get > bogged down cryptanalysing the 2440 document into plain text! I think Jon did a fine job as editor of this document and to me it is an easy to understand specification. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Mon Jun 26 13:34:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11683 for ; Mon, 26 Jun 2000 13:34:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14606 for ietf-openpgp-bks; Mon, 26 Jun 2000 09:04:27 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14601 for ; Mon, 26 Jun 2000 09:04:25 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin141-nt.pg10.frankfurt.nikoma.de [213.54.41.141]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id SAA90171 for ; Mon, 26 Jun 2000 18:04:59 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 952062ED44; Mon, 26 Jun 2000 18:00:22 +0200 (CEST) Date: Mon, 26 Jun 2000 18:00:22 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000626180022.B10751@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.4i In-Reply-To: <20000626174619.F26051@djebel.gnupg.de>; from wk@gnupg.org on Mon, Jun 26, 2000 at 05:46:19PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-06-26 17:46:19 +0200, Werner Koch wrote: > PGP is around for nearly a decade now. OpenPGP is just > an enhancement on the PGP 2 data formats. Actually, it might be instructive to first try to understand the considerably simpler PGP 2 data formats as documented in the pgformat.doc file which comes with PGP 2. From owner-ietf-openpgp@mail.imc.org Mon Jun 26 19:47:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17131 for ; Mon, 26 Jun 2000 19:47:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25654 for ietf-openpgp-bks; Mon, 26 Jun 2000 16:30:26 -0700 (PDT) Received: from smtp.canberra.net.au (jake.canberra.net.au [203.29.91.119]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25650 for ; Mon, 26 Jun 2000 16:30:23 -0700 (PDT) Received: from Windoze.cyberone.com.au (dialup347.canberra.net.au [203.33.188.219]) by smtp.canberra.net.au (8.9.3/8.9.3) with ESMTP id JAA20426 for ; Tue, 27 Jun 2000 09:30:55 +1000 Message-Id: <4.3.2.20000627093355.00a9d580@pop1.canberra.net.au> X-Sender: michaelw$cyberone.com.au@pop1.canberra.net.au X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Jun 2000 09:34:13 +1000 To: ietf-openpgp@imc.org From: Michael Walker Subject: Perl/CGI integration?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm fairly new to the OpenPGP concept so please forgive me if I'm ignorant. Is there a way to encrypt an email using OpenPGP (or any other encryption method), where the email is generated by a Perl script calling sendmail? Any help is greatly appreciated. Thanks, Michael Walker ------------------------------------------------------------------- Michael Walker + Balance Infosystems + Pentacles Music + WarmPond - IT Programmer ABN : 42 885 500 249 Mobile : (+61) 0413 273 435 E-mail : michaelw@cyberone.com.au WWW : http://www.wildfire-music.com.au/djnektie ICQ : 66056756 ------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Mon Jun 26 21:41:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18138 for ; Mon, 26 Jun 2000 21:41:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28060 for ietf-openpgp-bks; Mon, 26 Jun 2000 18:23:02 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA28055 for ; Mon, 26 Jun 2000 18:22:59 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A4CC159A018C; Tue, 27 Jun 2000 09:22:36 0800 Message-Id: <4.3.0.20000627090631.00b3b6b0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Jun 2000 09:13:29 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: OpenPGP should be called ClosedPGP Cc: Werner Koch In-Reply-To: <20000626174619.F26051@djebel.gnupg.de> References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <4.3.0.20000625121620.00ba26c0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner, > > other project directors so we can develop the OpenPGP standard and not get > > bogged down cryptanalysing the 2440 document into plain text! > >I think Jon did a fine job as editor of this document and to me it is >an easy to understand specification. I also think Jon did a fine job on the document, however for a newcomer to implement PGP, something else is needed - it can be a challenge to "put it together" when you have no experience with PGP at all :) As I am understanding the 2440bis, I am also creating another document that could possibly be useful to others like me in the future. Thanks for the reply. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jun 26 21:45:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19012 for ; Mon, 26 Jun 2000 21:45:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28155 for ietf-openpgp-bks; Mon, 26 Jun 2000 18:25:40 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA28151 for ; Mon, 26 Jun 2000 18:25:38 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5751617018C; Tue, 27 Jun 2000 09:25:25 0800 Message-Id: <4.3.0.20000627091415.00ba1270@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Jun 2000 09:16:18 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: OpenPGP should be called ClosedPGP Cc: Thomas Roessler In-Reply-To: <20000626180022.B10751@sobolev.does-not-exist.org> References: <20000626174619.F26051@djebel.gnupg.de> <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas, At 18:00 26/06/00 +0200, Thomas Roessler wrote: >On 2000-06-26 17:46:19 +0200, Werner Koch wrote: > > > PGP is around for nearly a decade now. OpenPGP is just > > an enhancement on the PGP 2 data formats. > >Actually, it might be instructive to first try to >understand the considerably simpler PGP 2 data formats as >documented in the pgformat.doc file which comes with PGP >2. That document was very informative and certainly helped me gain a better understanding of PGP. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jun 26 22:51:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20419 for ; Mon, 26 Jun 2000 22:51:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA01231 for ietf-openpgp-bks; Mon, 26 Jun 2000 19:34:00 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA01226 for ; Mon, 26 Jun 2000 19:33:58 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 21344 invoked from network); 27 Jun 2000 02:28:55 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 27 Jun 2000 02:28:55 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000626174619.F26051@djebel.gnupg.de> References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000627113432B.1001@eccosys.com> Date: Tue, 27 Jun 2000 11:34:32 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Mon, 26 Jun 2000 17:46:19 +0200 Message-ID: <20000626174619.F26051@djebel.gnupg.de> > And there are at least 3 implementations which you can consult to > check how a detail is actually done. regarding this point, i don't think it is good to suggest this in general because of potential problems if the potential implementor wants to create an independent implementation. or do you think this is an unnecessary precaution? From owner-ietf-openpgp@mail.imc.org Wed Jun 28 05:58:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17375 for ; Wed, 28 Jun 2000 05:58:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA19990 for ietf-openpgp-bks; Wed, 28 Jun 2000 01:35:51 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19986 for ; Wed, 28 Jun 2000 01:35:49 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 137DY2-0008KB-00; Wed, 28 Jun 2000 10:50:18 +0200 Date: Wed, 28 Jun 2000 10:50:18 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000628105018.T26051@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000627113432B.1001@eccosys.com>; from sen_ml@eccosys.com on Tue, Jun 27, 2000 at 11:34:32AM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 27 Jun 2000, sen_ml@eccosys.com wrote: > > And there are at least 3 implementations which you can consult to > > check how a detail is actually done. > > regarding this point, i don't think it is good to suggest this in > general because of potential problems if the potential implementor > wants to create an independent implementation. or do you think this Well, I have not looked at any other implemenation for writing GnuPG; becuase the GNU coding standards demands this and it may have caused legal problems with NAI. However, you can ask someone other to analyze the behaviour of one implemenation and write a report on this. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Wed Jun 28 06:57:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18021 for ; Wed, 28 Jun 2000 06:57:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA26370 for ietf-openpgp-bks; Wed, 28 Jun 2000 03:43:07 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA26366 for ; Wed, 28 Jun 2000 03:43:05 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17505 invoked from network); 28 Jun 2000 10:44:02 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Jun 2000 10:44:02 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000628105018.T26051@djebel.gnupg.de> References: <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000628194342Q.1001@eccosys.com> Date: Wed, 28 Jun 2000 19:43:42 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 52 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Wed, 28 Jun 2000 10:50:18 +0200 Message-ID: <20000628105018.T26051@djebel.gnupg.de> > On Tue, 27 Jun 2000, sen_ml@eccosys.com wrote: > > > > And there are at least 3 implementations which you can consult to > > > check how a detail is actually done. > > > > regarding this point, i don't think it is good to suggest this in > > general because of potential problems if the potential implementor > > wants to create an independent implementation. or do you think this > > Well, I have not looked at any other implemenation for writing GnuPG; > becuase the GNU coding standards demands this and it may have caused > legal problems with NAI. right, this could happen w/ other implementations as well if people are not careful. if it wasn't already obvious, i really really really appreciate your work on gnupg! besides being a user, i am glad that there are multiple implementations of openpgp (speaking of which, would it be possible to list urls for existing implementations on the page for the working group at: http://www.imc.org/ietf-openpgp/ ?) > However, you can ask someone other to analyze the behaviour of one > implemenation and write a report on this. that's true, but i think that may likely take more time than is actually necessary -- what are standards for afterall? however, i agree that the method you suggest can be useful. imo, open standard documents should be made clear and easy to understand, particular those dealing w/ security since misunderstandings can have serious consequences -- e.g. misimplementations. i did not find the openpgp document to be particularly easy to understand (e.g. wording, order of introducing terms, etc.). i do not intend this as an attack on any of the authors or editors so i hope people will not take it as such. i just want to voice my opinion as someone who has read (and who rereads) the document. i would be quite happy to go through the document and offer suggestions on wording and such toward the end of making it easier to digest. From owner-ietf-openpgp@mail.imc.org Wed Jun 28 21:05:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07094 for ; Wed, 28 Jun 2000 21:05:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19250 for ietf-openpgp-bks; Wed, 28 Jun 2000 17:49:23 -0700 (PDT) Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19242 for ; Wed, 28 Jun 2000 17:49:18 -0700 (PDT) Received: from localhost (ppp11418.qc.bellglobal.com [206.172.147.131]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id UAA17573; Wed, 28 Jun 2000 20:54:05 -0400 (EDT) Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 137Qrb-0000PT-00; Wed, 28 Jun 2000 19:03:23 -0400 Date: Wed, 28 Jun 2000 19:03:23 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000628190322.A1351@rho> References: <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> <20000628194342Q.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000628194342Q.1001@eccosys.com>; from sen_ml@eccosys.com on Wed, Jun 28, 2000 at 07:43:42PM +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 28, 2000 at 07:43:42PM +0900, sen_ml@eccosys.com wrote: > i did not find the openpgp document to be particularly easy to > understand (e.g. wording, order of introducing terms, etc.). i do not > intend this as an attack on any of the authors or editors so i hope > people will not take it as such. i just want to voice my opinion as > someone who has read (and who rereads) the document. I have to agree with this. I started working on my implementation while OpenPGP was still a draft, and it would have been impossible to write it with only the information in the OpenPGP document. The situation has improved a bit, but there are a lot of problems left. From owner-ietf-openpgp@mail.imc.org Thu Jun 29 05:56:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24850 for ; Thu, 29 Jun 2000 05:56:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA03492 for ietf-openpgp-bks; Thu, 29 Jun 2000 02:16:59 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03487 for ; Thu, 29 Jun 2000 02:16:57 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 137afr-00012J-00; Thu, 29 Jun 2000 11:31:55 +0200 Date: Thu, 29 Jun 2000 11:31:55 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000629113155.C3610@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <20000628190322.A1351@rho>; from ulf@fitug.de on Wed, Jun 28, 2000 at 07:03:23PM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 28 Jun 2000, Ulf Möller wrote: > while OpenPGP was still a draft, and it would have been impossible > to write it with only the information in the OpenPGP document. The As stated in rfc2440, it is based on rfc1991 which is much simpler becuase it describes the protocol used by PGP 2. As Thomas already mentioned, it is advisable to read other (cited) texts too. Especially I think it is impossible to write an implemention without the HAC or similiar information. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Thu Jun 29 07:10:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25804 for ; Thu, 29 Jun 2000 07:10:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA07842 for ietf-openpgp-bks; Thu, 29 Jun 2000 03:45:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07837 for ; Thu, 29 Jun 2000 03:45:54 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2940 invoked from network); 29 Jun 2000 10:46:54 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 29 Jun 2000 10:46:54 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000629113155.C3610@djebel.gnupg.de> References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20000629194636M.1001@eccosys.com> Date: Thu, 29 Jun 2000 19:46:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA07839 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Thu, 29 Jun 2000 11:31:55 +0200 Message-ID: <20000629113155.C3610@djebel.gnupg.de> > On Wed, 28 Jun 2000, Ulf Möller wrote: > > > while OpenPGP was still a draft, and it would have been impossible > > to write it with only the information in the OpenPGP document. The > > As stated in rfc2440, it is based on rfc1991 which is much simpler > becuase it describes the protocol used by PGP 2. As Thomas already > mentioned, it is advisable to read other (cited) texts too. it's probably up to ulf to clarify what he meant, but from the quoted context in his post, i did not interpret his statement to mean that one should be able to implement openpgp w/o looking at the references mentioned in the openpgp document. i think the point is that some people feel that the existing document can be improved in certain ways. i'd like to work on improving the existing document so that it is clearer and easier to understand. is the working group amenable to this? From owner-ietf-openpgp@mail.imc.org Thu Jun 29 09:54:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07938 for ; Thu, 29 Jun 2000 09:54:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA11177 for ietf-openpgp-bks; Thu, 29 Jun 2000 06:26:21 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11173 for ; Thu, 29 Jun 2000 06:26:19 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 137eZD-0001C4-00; Thu, 29 Jun 2000 15:41:19 +0200 Date: Thu, 29 Jun 2000 15:41:19 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000629154119.H3610@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000629194636M.1001@eccosys.com>; from sen_ml@eccosys.com on Thu, Jun 29, 2000 at 07:46:36PM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jun 2000, sen_ml@eccosys.com wrote: > i'd like to work on improving the existing document so that it is > clearer and easier to understand. is the working group amenable to > this? IMHO it is more important to "proceed" with ineroperability test, so that we can move to draft standard ... Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Thu Jun 29 10:29:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08870 for ; Thu, 29 Jun 2000 10:29:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA12020 for ietf-openpgp-bks; Thu, 29 Jun 2000 07:12:02 -0700 (PDT) Received: from sting.siteprotect.com ([64.26.0.89]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12014 for ; Thu, 29 Jun 2000 07:12:00 -0700 (PDT) Received: from mercury.infoguardian.net (cc584525-a.wlgrv1.pa.home.com [24.3.103.116]) by sting.siteprotect.com (8.9.3/8.9.3) with ESMTP id JAA30881 for ; Thu, 29 Jun 2000 09:15:21 -0500 Message-Id: <4.3.2.7.0.20000629101155.00be4540@wheresmymailserver.com> X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jun 2000 10:14:07 -0400 To: ietf-openpgp@imc.org From: Andrea Liles Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000628194342Q.1001@eccosys.com> References: <20000628105018.T26051@djebel.gnupg.de> <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 07:43 PM 6/28/00 +0900, you wrote: From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Wed, 28 Jun 2000 10:50:18 +0200 Message-ID: <20000628105018.T26051@djebel.gnupg.de> ... >right, this could happen w/ other implementations as well if people >are not careful. >if it wasn't already obvious, i really really really appreciate your >work on gnupg! besides being a user, i am glad that there are >multiple implementations of openpgp (speaking of which, would it be >possible to list urls for existing implementations on the page for the >working group at: http://www.imc.org/ietf-openpgp/ >?) ... I would find it quite useful to have a comprehensive list of existing implementations. If there is another location please advise. Thank you, Andrea . . . . . . . . . . . . . . . . . . . . . . . . Andrea Liles Director Information Guardian International, Ltd. 3000 Technology Campus, The Valley, Anguilla TV1 02P British West Indies Public Keys at: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x46914066 http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0xD6D84395 http://horowitz.surfnet.nl:11371/pks/lookup?op=get&search=0x46914066 http://horowitz.surfnet.nl:11371/pks/lookup?op=get&search=0xD6D84395 RSA 1BE5 856B 4FF7 6E79 7E2B DF01 94FB 58FD DSS CA8F E2B6 9D1B 0699 8DD5 CFE5 29F1 5075 4691 4066 . . . . . . . . . . . . . . . . . . . . . . . . From owner-ietf-openpgp@mail.imc.org Thu Jun 29 20:46:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23774 for ; Thu, 29 Jun 2000 20:46:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA04088 for ietf-openpgp-bks; Thu, 29 Jun 2000 17:27:42 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04084 for ; Thu, 29 Jun 2000 17:27:40 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 25746 invoked from network); 30 Jun 2000 00:28:40 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 30 Jun 2000 00:28:40 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000629154119.H3610@djebel.gnupg.de> References: <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> <20000629154119.H3610@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000630092823C.1001@eccosys.com> Date: Fri, 30 Jun 2000 09:28:23 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Thu, 29 Jun 2000 15:41:19 +0200 Message-ID: <20000629154119.H3610@djebel.gnupg.de> > On Thu, 29 Jun 2000, sen_ml@eccosys.com wrote: > > > i'd like to work on improving the existing document so that it is > > clearer and easier to understand. is the working group amenable to > > this? > > IMHO it is more important to "proceed" with ineroperability test, so > that we can move to draft standard ... that's consistent w/ the impression i get from some other members of the wg (implicitly and explicitly) -- though it may just be all in my head ;-) i have a question regarding moving to draft standard that i hope someone can answer. once that happens, is it possible to make any changes to the specification document? i.e. is it possible to make the kinds of changes that are specifically designed to make the document clearer and easier to understand, and get those changes reflected w/o issuing a new standard? alternatively, is there ever a time that is appropriate for making/suggesting those kinds of changes? From owner-ietf-openpgp@mail.imc.org Thu Jun 29 21:35:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25093 for ; Thu, 29 Jun 2000 21:35:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA05640 for ietf-openpgp-bks; Thu, 29 Jun 2000 18:18:34 -0700 (PDT) Received: from tomts1-srv.bellnexxia.net (tomts1.bellnexxia.net [209.226.175.139]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05636 for ; Thu, 29 Jun 2000 18:18:33 -0700 (PDT) Received: from localhost ([206.172.147.105]) by tomts1-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000630011919.LREE5881.tomts1-srv.bellnexxia.net@localhost>; Thu, 29 Jun 2000 21:19:19 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 137niv-0000Ye-00; Thu, 29 Jun 2000 19:27:57 -0400 Date: Thu, 29 Jun 2000 19:27:57 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000629192756.A2053@rho> References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000629194636M.1001@eccosys.com>; from sen_ml@eccosys.com on Thu, Jun 29, 2000 at 07:46:36PM +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 29, 2000 at 07:46:36PM +0900, sen_ml@eccosys.com wrote: > it's probably up to ulf to clarify what he meant, but from the quoted > context in his post, i did not interpret his statement to mean that > one should be able to implement openpgp w/o looking at the references > mentioned in the openpgp document. Right. I assumed the purpose of references was obvious. :) If a document is supposed to become a standard, it should contain - directly or through references - the information required to build an interoperable implementation. I maintain that that is not the case, the fact that Werner personally didn't look at the PGP source code nonwithstanding. Preferrably the document would also present the information in an easily accessible way, but it would already be a good step if only the issues raised on this list in the past would finally be addressed. From owner-ietf-openpgp@mail.imc.org Thu Jun 29 22:53:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26735 for ; Thu, 29 Jun 2000 22:53:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10158 for ietf-openpgp-bks; Thu, 29 Jun 2000 19:35:32 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA10151 for ; Thu, 29 Jun 2000 19:35:28 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA6A204C0296; Fri, 30 Jun 2000 10:35:38 0800 Message-Id: <4.3.0.20000630095636.00bae460@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 30 Jun 2000 10:26:19 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Implementation doc. Cc: sen_ml@eccosys.com In-Reply-To: <20000629194636M.1001@eccosys.com> References: <20000629113155.C3610@djebel.gnupg.de> <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sen, >i'd like to work on improving the existing document so that it is >clearer and easier to understand. is the working group amenable to >this? Although implementation testing is very important and would require 2440bis to remain reasonably static for the that to happen, it may be possible to also implement a document in parallel that accompanies 2440 and would be basically targeted at the implementor. This doc could provide implementation guidelines in a "summarised" fashion and would refer to 2440 for further understanding. Basically it would be targeted at implementors that are starting from scratch. One possible way to move ahead with this document is to make an FTP site available so that anybody could upload their own "summaries" or implementation notes. From this, we can then consolidate the information and create another doc that is a basic guideline for implementing OpenPGP. If peoples are interested, let me know and I'll set up an FTP site so notes etc etc can be uploaded for others to view for comment. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10158 for ietf-openpgp-bks; Thu, 29 Jun 2000 19:35:32 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA10151 for ; Thu, 29 Jun 2000 19:35:28 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA6A204C0296; Fri, 30 Jun 2000 10:35:38 0800 Message-Id: <4.3.0.20000630095636.00bae460@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 30 Jun 2000 10:26:19 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Implementation doc. Cc: sen_ml@eccosys.com In-Reply-To: <20000629194636M.1001@eccosys.com> References: <20000629113155.C3610@djebel.gnupg.de> <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sen, >i'd like to work on improving the existing document so that it is >clearer and easier to understand. is the working group amenable to >this? Although implementation testing is very important and would require 2440bis to remain reasonably static for the that to happen, it may be possible to also implement a document in parallel that accompanies 2440 and would be basically targeted at the implementor. This doc could provide implementation guidelines in a "summarised" fashion and would refer to 2440 for further understanding. Basically it would be targeted at implementors that are starting from scratch. One possible way to move ahead with this document is to make an FTP site available so that anybody could upload their own "summaries" or implementation notes. From this, we can then consolidate the information and create another doc that is a basic guideline for implementing OpenPGP. If peoples are interested, let me know and I'll set up an FTP site so notes etc etc can be uploaded for others to view for comment. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id SAA05640 for ietf-openpgp-bks; Thu, 29 Jun 2000 18:18:34 -0700 (PDT) Received: from tomts1-srv.bellnexxia.net (tomts1.bellnexxia.net [209.226.175.139]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA05636 for ; Thu, 29 Jun 2000 18:18:33 -0700 (PDT) Received: from localhost ([206.172.147.105]) by tomts1-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000630011919.LREE5881.tomts1-srv.bellnexxia.net@localhost>; Thu, 29 Jun 2000 21:19:19 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 137niv-0000Ye-00; Thu, 29 Jun 2000 19:27:57 -0400 Date: Thu, 29 Jun 2000 19:27:57 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000629192756.A2053@rho> References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000629194636M.1001@eccosys.com>; from sen_ml@eccosys.com on Thu, Jun 29, 2000 at 07:46:36PM +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 29, 2000 at 07:46:36PM +0900, sen_ml@eccosys.com wrote: > it's probably up to ulf to clarify what he meant, but from the quoted > context in his post, i did not interpret his statement to mean that > one should be able to implement openpgp w/o looking at the references > mentioned in the openpgp document. Right. I assumed the purpose of references was obvious. :) If a document is supposed to become a standard, it should contain - directly or through references - the information required to build an interoperable implementation. I maintain that that is not the case, the fact that Werner personally didn't look at the PGP source code nonwithstanding. Preferrably the document would also present the information in an easily accessible way, but it would already be a good step if only the issues raised on this list in the past would finally be addressed. Received: by ns.secondary.com (8.9.3/8.9.3) id RAA04088 for ietf-openpgp-bks; Thu, 29 Jun 2000 17:27:42 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04084 for ; Thu, 29 Jun 2000 17:27:40 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 25746 invoked from network); 30 Jun 2000 00:28:40 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 30 Jun 2000 00:28:40 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000629154119.H3610@djebel.gnupg.de> References: <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> <20000629154119.H3610@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000630092823C.1001@eccosys.com> Date: Fri, 30 Jun 2000 09:28:23 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Thu, 29 Jun 2000 15:41:19 +0200 Message-ID: <20000629154119.H3610@djebel.gnupg.de> > On Thu, 29 Jun 2000, sen_ml@eccosys.com wrote: > > > i'd like to work on improving the existing document so that it is > > clearer and easier to understand. is the working group amenable to > > this? > > IMHO it is more important to "proceed" with ineroperability test, so > that we can move to draft standard ... that's consistent w/ the impression i get from some other members of the wg (implicitly and explicitly) -- though it may just be all in my head ;-) i have a question regarding moving to draft standard that i hope someone can answer. once that happens, is it possible to make any changes to the specification document? i.e. is it possible to make the kinds of changes that are specifically designed to make the document clearer and easier to understand, and get those changes reflected w/o issuing a new standard? alternatively, is there ever a time that is appropriate for making/suggesting those kinds of changes? Received: by ns.secondary.com (8.9.3/8.9.3) id HAA12020 for ietf-openpgp-bks; Thu, 29 Jun 2000 07:12:02 -0700 (PDT) Received: from sting.siteprotect.com ([64.26.0.89]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA12014 for ; Thu, 29 Jun 2000 07:12:00 -0700 (PDT) Received: from mercury.infoguardian.net (cc584525-a.wlgrv1.pa.home.com [24.3.103.116]) by sting.siteprotect.com (8.9.3/8.9.3) with ESMTP id JAA30881 for ; Thu, 29 Jun 2000 09:15:21 -0500 Message-Id: <4.3.2.7.0.20000629101155.00be4540@wheresmymailserver.com> X-Sender: X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 29 Jun 2000 10:14:07 -0400 To: ietf-openpgp@imc.org From: Andrea Liles Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000628194342Q.1001@eccosys.com> References: <20000628105018.T26051@djebel.gnupg.de> <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 07:43 PM 6/28/00 +0900, you wrote: From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Wed, 28 Jun 2000 10:50:18 +0200 Message-ID: <20000628105018.T26051@djebel.gnupg.de> ... >right, this could happen w/ other implementations as well if people >are not careful. >if it wasn't already obvious, i really really really appreciate your >work on gnupg! besides being a user, i am glad that there are >multiple implementations of openpgp (speaking of which, would it be >possible to list urls for existing implementations on the page for the >working group at: http://www.imc.org/ietf-openpgp/ >?) ... I would find it quite useful to have a comprehensive list of existing implementations. If there is another location please advise. Thank you, Andrea . . . . . . . . . . . . . . . . . . . . . . . . Andrea Liles Director Information Guardian International, Ltd. 3000 Technology Campus, The Valley, Anguilla TV1 02P British West Indies Public Keys at: http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0x46914066 http://pgp.ai.mit.edu:11371/pks/lookup?op=get&search=0xD6D84395 http://horowitz.surfnet.nl:11371/pks/lookup?op=get&search=0x46914066 http://horowitz.surfnet.nl:11371/pks/lookup?op=get&search=0xD6D84395 RSA 1BE5 856B 4FF7 6E79 7E2B DF01 94FB 58FD DSS CA8F E2B6 9D1B 0699 8DD5 CFE5 29F1 5075 4691 4066 . . . . . . . . . . . . . . . . . . . . . . . . Received: by ns.secondary.com (8.9.3/8.9.3) id GAA11177 for ietf-openpgp-bks; Thu, 29 Jun 2000 06:26:21 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA11173 for ; Thu, 29 Jun 2000 06:26:19 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 137eZD-0001C4-00; Thu, 29 Jun 2000 15:41:19 +0200 Date: Thu, 29 Jun 2000 15:41:19 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000629154119.H3610@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000629194636M.1001@eccosys.com>; from sen_ml@eccosys.com on Thu, Jun 29, 2000 at 07:46:36PM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 29 Jun 2000, sen_ml@eccosys.com wrote: > i'd like to work on improving the existing document so that it is > clearer and easier to understand. is the working group amenable to > this? IMHO it is more important to "proceed" with ineroperability test, so that we can move to draft standard ... Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id DAA07842 for ietf-openpgp-bks; Thu, 29 Jun 2000 03:45:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07837 for ; Thu, 29 Jun 2000 03:45:54 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2940 invoked from network); 29 Jun 2000 10:46:54 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 29 Jun 2000 10:46:54 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000629113155.C3610@djebel.gnupg.de> References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Message-Id: <20000629194636M.1001@eccosys.com> Date: Thu, 29 Jun 2000 19:46:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id DAA07839 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Thu, 29 Jun 2000 11:31:55 +0200 Message-ID: <20000629113155.C3610@djebel.gnupg.de> > On Wed, 28 Jun 2000, Ulf Möller wrote: > > > while OpenPGP was still a draft, and it would have been impossible > > to write it with only the information in the OpenPGP document. The > > As stated in rfc2440, it is based on rfc1991 which is much simpler > becuase it describes the protocol used by PGP 2. As Thomas already > mentioned, it is advisable to read other (cited) texts too. it's probably up to ulf to clarify what he meant, but from the quoted context in his post, i did not interpret his statement to mean that one should be able to implement openpgp w/o looking at the references mentioned in the openpgp document. i think the point is that some people feel that the existing document can be improved in certain ways. i'd like to work on improving the existing document so that it is clearer and easier to understand. is the working group amenable to this? Received: by ns.secondary.com (8.9.3/8.9.3) id CAA03492 for ietf-openpgp-bks; Thu, 29 Jun 2000 02:16:59 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA03487 for ; Thu, 29 Jun 2000 02:16:57 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 137afr-00012J-00; Thu, 29 Jun 2000 11:31:55 +0200 Date: Thu, 29 Jun 2000 11:31:55 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000629113155.C3610@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <20000628190322.A1351@rho>; from ulf@fitug.de on Wed, Jun 28, 2000 at 07:03:23PM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 28 Jun 2000, Ulf Möller wrote: > while OpenPGP was still a draft, and it would have been impossible > to write it with only the information in the OpenPGP document. The As stated in rfc2440, it is based on rfc1991 which is much simpler becuase it describes the protocol used by PGP 2. As Thomas already mentioned, it is advisable to read other (cited) texts too. Especially I think it is impossible to write an implemention without the HAC or similiar information. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19250 for ietf-openpgp-bks; Wed, 28 Jun 2000 17:49:23 -0700 (PDT) Received: from smtp13.bellglobal.com (smtp13.bellglobal.com [204.101.251.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19242 for ; Wed, 28 Jun 2000 17:49:18 -0700 (PDT) Received: from localhost (ppp11418.qc.bellglobal.com [206.172.147.131]) by smtp13.bellglobal.com (8.8.5/8.8.5) with ESMTP id UAA17573; Wed, 28 Jun 2000 20:54:05 -0400 (EDT) Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 137Qrb-0000PT-00; Wed, 28 Jun 2000 19:03:23 -0400 Date: Wed, 28 Jun 2000 19:03:23 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000628190322.A1351@rho> References: <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> <20000628194342Q.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000628194342Q.1001@eccosys.com>; from sen_ml@eccosys.com on Wed, Jun 28, 2000 at 07:43:42PM +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Jun 28, 2000 at 07:43:42PM +0900, sen_ml@eccosys.com wrote: > i did not find the openpgp document to be particularly easy to > understand (e.g. wording, order of introducing terms, etc.). i do not > intend this as an attack on any of the authors or editors so i hope > people will not take it as such. i just want to voice my opinion as > someone who has read (and who rereads) the document. I have to agree with this. I started working on my implementation while OpenPGP was still a draft, and it would have been impossible to write it with only the information in the OpenPGP document. The situation has improved a bit, but there are a lot of problems left. Received: by ns.secondary.com (8.9.3/8.9.3) id DAA26370 for ietf-openpgp-bks; Wed, 28 Jun 2000 03:43:07 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA26366 for ; Wed, 28 Jun 2000 03:43:05 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17505 invoked from network); 28 Jun 2000 10:44:02 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Jun 2000 10:44:02 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000628105018.T26051@djebel.gnupg.de> References: <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> <20000628105018.T26051@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000628194342Q.1001@eccosys.com> Date: Wed, 28 Jun 2000 19:43:42 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 52 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Wed, 28 Jun 2000 10:50:18 +0200 Message-ID: <20000628105018.T26051@djebel.gnupg.de> > On Tue, 27 Jun 2000, sen_ml@eccosys.com wrote: > > > > And there are at least 3 implementations which you can consult to > > > check how a detail is actually done. > > > > regarding this point, i don't think it is good to suggest this in > > general because of potential problems if the potential implementor > > wants to create an independent implementation. or do you think this > > Well, I have not looked at any other implemenation for writing GnuPG; > becuase the GNU coding standards demands this and it may have caused > legal problems with NAI. right, this could happen w/ other implementations as well if people are not careful. if it wasn't already obvious, i really really really appreciate your work on gnupg! besides being a user, i am glad that there are multiple implementations of openpgp (speaking of which, would it be possible to list urls for existing implementations on the page for the working group at: http://www.imc.org/ietf-openpgp/ ?) > However, you can ask someone other to analyze the behaviour of one > implemenation and write a report on this. that's true, but i think that may likely take more time than is actually necessary -- what are standards for afterall? however, i agree that the method you suggest can be useful. imo, open standard documents should be made clear and easy to understand, particular those dealing w/ security since misunderstandings can have serious consequences -- e.g. misimplementations. i did not find the openpgp document to be particularly easy to understand (e.g. wording, order of introducing terms, etc.). i do not intend this as an attack on any of the authors or editors so i hope people will not take it as such. i just want to voice my opinion as someone who has read (and who rereads) the document. i would be quite happy to go through the document and offer suggestions on wording and such toward the end of making it easier to digest. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA19990 for ietf-openpgp-bks; Wed, 28 Jun 2000 01:35:51 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA19986 for ; Wed, 28 Jun 2000 01:35:49 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 137DY2-0008KB-00; Wed, 28 Jun 2000 10:50:18 +0200 Date: Wed, 28 Jun 2000 10:50:18 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000628105018.T26051@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> <20000627113432B.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000627113432B.1001@eccosys.com>; from sen_ml@eccosys.com on Tue, Jun 27, 2000 at 11:34:32AM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 27 Jun 2000, sen_ml@eccosys.com wrote: > > And there are at least 3 implementations which you can consult to > > check how a detail is actually done. > > regarding this point, i don't think it is good to suggest this in > general because of potential problems if the potential implementor > wants to create an independent implementation. or do you think this Well, I have not looked at any other implemenation for writing GnuPG; becuase the GNU coding standards demands this and it may have caused legal problems with NAI. However, you can ask someone other to analyze the behaviour of one implemenation and write a report on this. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id TAA01231 for ietf-openpgp-bks; Mon, 26 Jun 2000 19:34:00 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA01226 for ; Mon, 26 Jun 2000 19:33:58 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 21344 invoked from network); 27 Jun 2000 02:28:55 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 27 Jun 2000 02:28:55 -0000 To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: <20000626174619.F26051@djebel.gnupg.de> References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> X-Mailer: Mew version 1.94.2 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000627113432B.1001@eccosys.com> Date: Tue, 27 Jun 2000 11:34:32 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: OpenPGP should be called ClosedPGP Date: Mon, 26 Jun 2000 17:46:19 +0200 Message-ID: <20000626174619.F26051@djebel.gnupg.de> > And there are at least 3 implementations which you can consult to > check how a detail is actually done. regarding this point, i don't think it is good to suggest this in general because of potential problems if the potential implementor wants to create an independent implementation. or do you think this is an unnecessary precaution? Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28155 for ietf-openpgp-bks; Mon, 26 Jun 2000 18:25:40 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA28151 for ; Mon, 26 Jun 2000 18:25:38 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5751617018C; Tue, 27 Jun 2000 09:25:25 0800 Message-Id: <4.3.0.20000627091415.00ba1270@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Jun 2000 09:16:18 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: OpenPGP should be called ClosedPGP Cc: Thomas Roessler In-Reply-To: <20000626180022.B10751@sobolev.does-not-exist.org> References: <20000626174619.F26051@djebel.gnupg.de> <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thomas, At 18:00 26/06/00 +0200, Thomas Roessler wrote: >On 2000-06-26 17:46:19 +0200, Werner Koch wrote: > > > PGP is around for nearly a decade now. OpenPGP is just > > an enhancement on the PGP 2 data formats. > >Actually, it might be instructive to first try to >understand the considerably simpler PGP 2 data formats as >documented in the pgformat.doc file which comes with PGP >2. That document was very informative and certainly helped me gain a better understanding of PGP. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id SAA28060 for ietf-openpgp-bks; Mon, 26 Jun 2000 18:23:02 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA28055 for ; Mon, 26 Jun 2000 18:22:59 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A4CC159A018C; Tue, 27 Jun 2000 09:22:36 0800 Message-Id: <4.3.0.20000627090631.00b3b6b0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Jun 2000 09:13:29 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: OpenPGP should be called ClosedPGP Cc: Werner Koch In-Reply-To: <20000626174619.F26051@djebel.gnupg.de> References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <4.3.0.20000625121620.00ba26c0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner, > > other project directors so we can develop the OpenPGP standard and not get > > bogged down cryptanalysing the 2440 document into plain text! > >I think Jon did a fine job as editor of this document and to me it is >an easy to understand specification. I also think Jon did a fine job on the document, however for a newcomer to implement PGP, something else is needed - it can be a challenge to "put it together" when you have no experience with PGP at all :) As I am understanding the 2440bis, I am also creating another document that could possibly be useful to others like me in the future. Thanks for the reply. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25654 for ietf-openpgp-bks; Mon, 26 Jun 2000 16:30:26 -0700 (PDT) Received: from smtp.canberra.net.au (jake.canberra.net.au [203.29.91.119]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25650 for ; Mon, 26 Jun 2000 16:30:23 -0700 (PDT) Received: from Windoze.cyberone.com.au (dialup347.canberra.net.au [203.33.188.219]) by smtp.canberra.net.au (8.9.3/8.9.3) with ESMTP id JAA20426 for ; Tue, 27 Jun 2000 09:30:55 +1000 Message-Id: <4.3.2.20000627093355.00a9d580@pop1.canberra.net.au> X-Sender: michaelw$cyberone.com.au@pop1.canberra.net.au X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 27 Jun 2000 09:34:13 +1000 To: ietf-openpgp@imc.org From: Michael Walker Subject: Perl/CGI integration?? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm fairly new to the OpenPGP concept so please forgive me if I'm ignorant. Is there a way to encrypt an email using OpenPGP (or any other encryption method), where the email is generated by a Perl script calling sendmail? Any help is greatly appreciated. Thanks, Michael Walker ------------------------------------------------------------------- Michael Walker + Balance Infosystems + Pentacles Music + WarmPond - IT Programmer ABN : 42 885 500 249 Mobile : (+61) 0413 273 435 E-mail : michaelw@cyberone.com.au WWW : http://www.wildfire-music.com.au/djnektie ICQ : 66056756 ------------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14606 for ietf-openpgp-bks; Mon, 26 Jun 2000 09:04:27 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14601 for ; Mon, 26 Jun 2000 09:04:25 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin141-nt.pg10.frankfurt.nikoma.de [213.54.41.141]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id SAA90171 for ; Mon, 26 Jun 2000 18:04:59 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 952062ED44; Mon, 26 Jun 2000 18:00:22 +0200 (CEST) Date: Mon, 26 Jun 2000 18:00:22 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000626180022.B10751@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> <20000626174619.F26051@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.4i In-Reply-To: <20000626174619.F26051@djebel.gnupg.de>; from wk@gnupg.org on Mon, Jun 26, 2000 at 05:46:19PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-06-26 17:46:19 +0200, Werner Koch wrote: > PGP is around for nearly a decade now. OpenPGP is just > an enhancement on the PGP 2 data formats. Actually, it might be instructive to first try to understand the considerably simpler PGP 2 data formats as documented in the pgformat.doc file which comes with PGP 2. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12824 for ietf-openpgp-bks; Mon, 26 Jun 2000 08:32:21 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12815 for ; Mon, 26 Jun 2000 08:32:19 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 136b5X-0006rN-00; Mon, 26 Jun 2000 17:46:19 +0200 Date: Mon, 26 Jun 2000 17:46:19 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP Message-ID: <20000626174619.F26051@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <4.3.0.20000625121620.00ba26c0@mail.comasp.com>; from ejc@comasp.com on Sun, Jun 25, 2000 at 12:48:32PM +0800 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 25 Jun 2000, Erron Criddle wrote: > After literally many hours of research, I have come across only one > document that explains part of 2440 in a understandable format and that is: OpenPGP is quite complex (but not as complex as some other protocols), so it takes a while to understand all the details. A lot of things have been explained on this mailing list here more than one time. Have a look at the archives. And there are at least 3 implementations which you can consult to check how a detail is actually done. > Come on people who are developing this standard - if you want it to take > off, help people and/or make something available to people like me and PGP is around for nearly a decade now. OpenPGP is just an enhancement on the PGP 2 data formats. > other project directors so we can develop the OpenPGP standard and not get > bogged down cryptanalysing the 2440 document into plain text! I think Jon did a fine job as editor of this document and to me it is an easy to understand specification. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id VAA17728 for ietf-openpgp-bks; Sat, 24 Jun 2000 21:57:59 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA17719 for ; Sat, 24 Jun 2000 21:57:55 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A42C3150024A; Sun, 25 Jun 2000 12:57:32 0800 Message-Id: <4.3.0.20000625121620.00ba26c0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sun, 25 Jun 2000 12:48:32 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: OpenPGP should be called ClosedPGP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all that can (well most): Just e-mailing to say that I am appalled at the helpfulness of this list; I have been involved with the Internet for six years now and have also been involved with other standards, lists and discussion forums and this is the most "closed" list I have ever come across! After literally many hours of research, I have come across only one document that explains part of 2440 in a understandable format and that is: http://www.openpgp.net/pgpemail_toc.html I have also noticed there is a book called: OpenPGP Specification & Sample Code; ISBN: 1583680144; by Jon Callas... however, upon e-mailing the author for instructions on how to obtain the book and visits to www.cryptography.org and www.pibooks.com to purchase it (found URL's in openpgp archives), I am still left wondering whether the book actually exists! Come on people who are developing this standard - if you want it to take off, help people and/or make something available to people like me and other project directors so we can develop the OpenPGP standard and not get bogged down cryptanalysing the 2440 document into plain text! PS: Thanks to those who have responded to my e-mails - it certainly has confirmed many things I was unsure of regarding OpenPGP. PSS: Ignore this message if the MITM is blocking everyone's answers to my e-mails :) Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12420 for ietf-openpgp-bks; Fri, 23 Jun 2000 05:32:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA12413 for ; Fri, 23 Jun 2000 05:32:54 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 22347 invoked from network); 23 Jun 2000 12:27:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Jun 2000 12:27:45 -0000 To: ietf-openpgp@imc.org Subject: Re: V4 signature Q In-Reply-To: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> References: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000623213312C.1001@eccosys.com> Date: Fri, 23 Jun 2000 21:33:12 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 33 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: V4 signature Q Date: Fri, 23 Jun 2000 18:03:40 +0800 Message-ID: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> > Regarding a V4 signature; > > 5.2.3 states that the third octec of a signature contains the public key > algorithm. Would it be correct for me to say that the values of the 3rd > octec of a signature packet can contain either: > > 1 - RSA (Encrypt or sign) > 3 - RSA (sign only) > 17 - DSA > 20 - ElGamal (encrypt or sign) > > I'm trying to work out where the digital signature algorithm is specified > in the signature and this is the only place I can see it fitting. the location looks correct to me for specifying the public key algorithm portion of specifying the method of computation of the digital signature. i think the hash algorithm is also relevant as it is also part of the process of computing a signature...but it's the next octet over anyway ;-) note the comment in section 12.4 regarding rsa sign-only keys that says: There are algorithm types for RSA-signature-only, and RSA-encrypt- only keys. These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, and generalizes it to all algorithms. An implementation SHOULD NOT create such a key, but MAY interpret it. Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05829 for ietf-openpgp-bks; Fri, 23 Jun 2000 03:13:10 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA05817 for ; Fri, 23 Jun 2000 03:13:04 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB03696024A; Fri, 23 Jun 2000 18:12:35 0800 Message-Id: <4.3.0.20000623175605.00ba0aa0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 23 Jun 2000 18:03:40 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: V4 signature Q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I was wondering if someone could please clarify something (again :) : Regarding a V4 signature; 5.2.3 states that the third octec of a signature contains the public key algorithm. Would it be correct for me to say that the values of the 3rd octec of a signature packet can contain either: 1 - RSA (Encrypt or sign) 3 - RSA (sign only) 17 - DSA 20 - ElGamal (encrypt or sign) I'm trying to work out where the digital signature algorithm is specified in the signature and this is the only place I can see it fitting. thank you in advance for any answers... Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id AAA26778 for ietf-openpgp-bks; Fri, 23 Jun 2000 00:21:29 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA26773 for ; Fri, 23 Jun 2000 00:21:28 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA03289; Fri, 23 Jun 2000 00:08:09 -0700 Date: Fri, 23 Jun 2000 00:07:57 -0700 (PDT) From: "L. Sassaman" To: Bodo Moeller cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <20000623075954.A4134@epsilon> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 23 Jun 2000, Bodo Moeller wrote: > On Thu, Jun 22, 2000 at 01:37:49PM -0700, L. Sassaman wrote: > > On Mon, 19 Jun 2000, Bodo Moeller wrote: > >> L. Sassaman : > > >>> [...] Expanding from the right is less natural to users whose language > >>> reads from left to right, in my opinion. > > >> Have you used a telephone lately? > > > That's a non sequitor if I have ever seen one... > > Dialing certain postfixes of a given phone number can work, dialing > any prefix won't. That is, phone numbers expand from the right. > I haven't yet heard of anyone complaing about this on the grounds that > thear language reads from left to right. That's an invalid analogy. Telephone prefixes exist so that phone numbers can be grouped seperately. There is no such grouping with OpenPGP key ideas -- all key ids are members of one group. In a left to right most-significant-bit key id expansion, if the 32 or 64 bits you provided weren't enough, you could keep adding more until a match was found. In a left to right least-signification-bit expansion, you would have to start over with the new information. This is all academic, however, since I think we decided that changing this now would be worse than leaving it the way it is. __ L. Sassaman System Administrator | "If you chose not to decide, Technology Consultant | you still have made a choice" icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Rush -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5UwzZPYrxsgmsCmoRAiE9AKDQSEgF2hMJlE1Niwdb3oL+X1Q5VQCg/AA3 rMeJBPdynBM7rI6CrWSB7TU= =W8Or -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id XAA24400 for ietf-openpgp-bks; Thu, 22 Jun 2000 23:01:20 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA24392 for ; Thu, 22 Jun 2000 23:01:18 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id IAA19294; Fri, 23 Jun 2000 08:00:45 +0200 (MET DST) Received: from ppp343.stud.tu-darmstadt.de (ppp343.stud.tu-darmstadt.de [130.83.176.94]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id IAA10066; Fri, 23 Jun 2000 08:01:28 +0200 (MET DST) Received: id ; Fri, 23 Jun 2000 07:59:55 +0200 (CEST) Date: Fri, 23 Jun 2000 07:59:55 +0200 From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: "L. Sassaman" Cc: Bodo Moeller , ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000623075954.A4134@epsilon> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from rabbi@quickie.net on Thu, Jun 22, 2000 at 01:37:49PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 22, 2000 at 01:37:49PM -0700, L. Sassaman wrote: > On Mon, 19 Jun 2000, Bodo Moeller wrote: >> L. Sassaman : >>> [...] Expanding from the right is less natural to users whose language >>> reads from left to right, in my opinion. >> Have you used a telephone lately? > That's a non sequitor if I have ever seen one... Dialing certain postfixes of a given phone number can work, dialing any prefix won't. That is, phone numbers expand from the right. I haven't yet heard of anyone complaing about this on the grounds that thear language reads from left to right. Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10907 for ietf-openpgp-bks; Thu, 22 Jun 2000 19:16:12 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA10901 for ; Thu, 22 Jun 2000 19:16:10 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10367 invoked from network); 23 Jun 2000 02:11:00 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 Jun 2000 02:11:00 -0000 To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: References: X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000623111625T.1001@eccosys.com> Date: Fri, 23 Jun 2000 11:16:25 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: "L. Sassaman" Subject: Re: KeyID as left vs right substring of fingerprint Date: Thu, 22 Jun 2000 13:37:49 -0700 (PDT) Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 19 Jun 2000, Bodo Moeller wrote: > > > L. Sassaman : > > > > > [...] Expanding from the right is less natural to users whose language > > > reads from left to right, in my opinion. > > > > Have you used a telephone lately? > > That's a non sequitor if I have ever seen one... i didn't understand the remark about the telephone. does it have to do w/ a touch pad or display or numbers on a screen? perhaps the original poster could elaborate? Received: by ns.secondary.com (8.9.3/8.9.3) id NAA27353 for ietf-openpgp-bks; Thu, 22 Jun 2000 13:56:06 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA27348 for ; Thu, 22 Jun 2000 13:56:05 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id NAA31903; Thu, 22 Jun 2000 13:38:02 -0700 Date: Thu, 22 Jun 2000 13:37:49 -0700 (PDT) From: "L. Sassaman" To: Bodo Moeller cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 19 Jun 2000, Bodo Moeller wrote: > L. Sassaman : > > > [...] Expanding from the right is less natural to users whose language > > reads from left to right, in my opinion. > > Have you used a telephone lately? That's a non sequitor if I have ever seen one... __ L. Sassaman System Administrator | "If you chose not to decide, Technology Consultant | you still have made a choice" icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Rush -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5UnkmPYrxsgmsCmoRArMBAJ4tqPqkwGNp5a2ggFcGDz3/l15R2QCg9EQ5 14IcTnfJiTJw6NDSF8jXExA= =co+4 -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA24883 for ietf-openpgp-bks; Thu, 22 Jun 2000 11:31:23 -0700 (PDT) Received: from snipe.prod.itd.earthlink.net (snipe.prod.itd.earthlink.net [207.217.120.62]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA24879 for ; Thu, 22 Jun 2000 11:31:22 -0700 (PDT) Received: from mwyoung.transarc.com (1Cust204.tnt8.lax3.da.uu.net [63.23.75.204]) by snipe.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id LAA21165 for ; Thu, 22 Jun 2000 11:31:37 -0700 (PDT) Message-ID: <001801bfdc77$b075eac0$cc4b173f@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: Revised MDC packet spec Date: Thu, 22 Jun 2000 14:28:35 -0400 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.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >Or maybe we should just do the sync anyway. I would normally be in favor maintaining the traditional resync, since it's code any implementation has to have anyway, but here it would open up a huge hole. An attacker could easily convert a new SEIP data packet into an old SE data packet by replacing the header+version and tearing off the known-sized MDC packet at the end. Depending on the difference in resync mode alone doesn't feel good to me, though. Perhaps Hal could elaborate on the internal discussions that motivate including the block+2 pad in the hash. If you don't need the block+2 pad in the hash, then you could just use another level of nested packet, something like: Symmetrically-Encrypted-Packet { block+2 pad MDC-packet { arbitrary-packet // compressed or literal hash } } I would find another nesting level much easier to implement in a pipelined receiver. To implement the latest (non-nested) proposal, an inner packet-parsing loop would need access to context from the outer reading logic, which is not nearly as natural. Looking through the archive, I see Tom Zerucha proposed bracketing with two new packets, but I haven't seen this nested approach mentioned. It's quite possible I've just missed it -- there's been a lot for me to catch up on -- so if it's been discussed, can someone point me at the messages? Received: by ns.secondary.com (8.9.3/8.9.3) id TAA09026 for ietf-openpgp-bks; Tue, 20 Jun 2000 19:52:00 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA09013 for ; Tue, 20 Jun 2000 19:51:57 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20815 invoked from network); 21 Jun 2000 02:46:42 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 21 Jun 2000 02:46:42 -0000 To: ietf-openpgp@imc.org Subject: Re: Do sigs. on encoded data confirm to OpenPGP? In-Reply-To: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> References: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000621115201G.1001@eccosys.com> Date: Wed, 21 Jun 2000 11:52:01 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: Do sigs. on encoded data confirm to OpenPGP? Date: Tue, 20 Jun 2000 17:06:51 +0800 Message-ID: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> > Has anyone thought about this: > > If I am to produce a signature on a 100 MByte file (for example), unless I > produce the signature from the encrypted (and encoded?) file, the receiver > would have to decrypt the entire 100MByte file just to verify a signature > that may be invalid! i'm a little fuzzy at this time of day, but isn't there some sort of attack that's possible if you sign some encrypted data? perhaps someone else who is more awake can confirm ;-) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA05793 for ietf-openpgp-bks; Tue, 20 Jun 2000 06:41:29 -0700 (PDT) Received: from alcove.wittsend.com (IDENT:root@alcove.wittsend.com [130.205.0.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA05789 for ; Tue, 20 Jun 2000 06:41:27 -0700 (PDT) Received: (from mhw@localhost) by alcove.wittsend.com (8.9.3/8.9.3) id IAA04974; Tue, 20 Jun 2000 08:41:05 -0400 Date: Tue, 20 Jun 2000 08:41:05 -0400 From: "Michael H. Warfield" To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: Quick Triple-DES Q Message-ID: <20000620084105.A2730@alcove.wittsend.com> References: <4.3.0.20000605122801.00b96b10@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i In-Reply-To: <4.3.0.20000605122801.00b96b10@mail.comasp.com>; from ejc@comasp.com on Mon, Jun 05, 2000 at 12:30:59PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jun 05, 2000 at 12:30:59PM +0800, Erron Criddle wrote: > To all, > Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for > use in the OpenPGP standard? AFAIK, RSA has no IP encumberances on DES or 3-DES what so ever. The patent on the RSA algorithm expires in a few months at which time RSA labs loses their IP encumberance on that. > TIA. > Regards > Erron Criddle > Comasp Ltd. > ACN: 089 468 682 > Level 2, 45 Stirling Hwy > NEDLANDS WA 6009 > Australia > > Fax: +61 8 9386 9473 > Tel: +61 8 9386 9534 > Mob: +414/0414 800 888 > > ejc@comasp.com > http://www.comasp.com > > -- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it! Received: by ns.secondary.com (8.9.3/8.9.3) id GAA03956 for ietf-openpgp-bks; Tue, 20 Jun 2000 06:10:49 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA03947 for ; Tue, 20 Jun 2000 06:10:45 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 134Nmb-0002Ui-00 for ietf-openpgp@imc.org; Tue, 20 Jun 2000 15:09:37 +0200 To: ietf-openpgp@imc.org Subject: Signature subpacket clarification From: Florian Weimer Date: 20 Jun 2000 15:09:37 +0200 Message-ID: Lines: 38 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The phrase "MUST be present in the hashed area." has to be added to the following sections: 5.2.3.4. Signature creation time 5.2.3.6. Key expiration time 5.2.3.10. Signature expiration time 5.2.3.12. Revocable 5.2.3.13. Trust signature 5.2.3.14. Regular expression 5.2.3.15. Revocation key 5.2.3.17. Key server preferences 5.2.3.19. Primary user id 5.2.3.21. Key Flags 5.2.3.22. Signer's User ID 5.2.3.23. Reason for Revocation I'm not sure about the following (GnuPG puts them into the hashed area): 5.2.3.7. Preferred symmetric algorithms 5.2.3.8. Preferred hash algorithms 5.2.3.9. Preferred compression algorithms Hash protection is obviously not needed for: 5.2.3.5. Issuer 5.2.3.11. Exportable Certification 5.2.3.18. Preferred key server (resolving URLs isn't secure anyway) 5.2.3.20. Policy URL (ditto) Whether notation data has to be put into the hashed area depends on that data, of course. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 Received: by ns.secondary.com (8.9.3/8.9.3) id CAA15968 for ietf-openpgp-bks; Tue, 20 Jun 2000 02:16:18 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA15962 for ; Tue, 20 Jun 2000 02:16:15 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A925662020C; Tue, 20 Jun 2000 17:15:33 0800 Message-Id: <4.3.0.20000620154136.00b9e2b0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Jun 2000 17:06:51 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Do sigs. on encoded data confirm to OpenPGP? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Has anyone thought about this: If I am to produce a signature on a 100 MByte file (for example), unless I produce the signature from the encrypted (and encoded?) file, the receiver would have to decrypt the entire 100MByte file just to verify a signature that may be invalid! Would it be possible (to alleviate this situation), to: 1) Compress Plaintext 2) Encrypt Plaintext 3) Encode the file (if necessary) 4) Produce Signature 5) Encrypt Signature (using same session key as in 2?) 6) Encrypt session key using receiver's public key. Detached signatures are mentioned in 10.3 from 2440 that may address this situation, however there are no specific details on this methodology. When the e-mail is received, the following would occur: 1) Decryption of session key (using private key) 2) Decryption of signature (using private key) 3) Run hashing algorithm and DSA over the encrypted/encoded data 4) Compare sigs and either discard or decrypt to the original plaintext. This way, the receiver doesn't have to decrypt a 100 MByte file just to verify a signature that may be invalid! I know you can use a single pass signature to speed up the process of decryption etc, however you still have to decrypt to the original plain-text and that seems to be a waste of time if the sigs don't match. If someone could advise on a solution they may have come across whereby you do not have to decrypt/decode just to verify a signature, it would be much appreciated. TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id SAA07664 for ietf-openpgp-bks; Mon, 19 Jun 2000 18:30:22 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA07654 for ; Mon, 19 Jun 2000 18:30:19 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ABEF2560204; Tue, 20 Jun 2000 09:29:35 0800 Message-Id: <4.3.0.20000620091941.00b43240@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 20 Jun 2000 09:20:57 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Open-PGP Q re DSA and keys > 1024 bit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Upon reading 2440bis re DSA and a ElGamal key length limit of 1024 bits, I was wondering what the Open-PGP group recommends for signing if you use ElGamal keys > 1024 bits? If you do use ElGamal Keys > 1024 bits, should you have another set of keys <=1024 bits for signing or is there a standard way to reduce 2048 bit PGP keys down to 1024 bits suitable for the DSA signature algorithm? TIA for any info. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28005 for ietf-openpgp-bks; Mon, 19 Jun 2000 14:39:14 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28000 for ; Mon, 19 Jun 2000 14:39:11 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id XAA25275 for ; Mon, 19 Jun 2000 23:38:31 +0200 (MET DST) Received: from ppp62.stud.tu-darmstadt.de (ppp62.stud.tu-darmstadt.de [130.83.177.62]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id XAA23811 for ; Mon, 19 Jun 2000 23:39:04 +0200 (MET DST) Received: id ; Mon, 19 Jun 2000 16:45:48 +0200 (CEST) Message-Id: Date: Mon, 19 Jun 2000 16:45:48 +0200 (CEST) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: References: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: L. Sassaman : > [...] Expanding from the right is less natural to users whose language > reads from left to right, in my opinion. Have you used a telephone lately? Received: by ns.secondary.com (8.9.3/8.9.3) id WAA01373 for ietf-openpgp-bks; Fri, 16 Jun 2000 22:25:47 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA01368 for ; Fri, 16 Jun 2000 22:25:46 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id BAA00906; Sat, 17 Jun 2000 01:25:33 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id BAA18954; Sat, 17 Jun 2000 01:25:24 -0400 Date: Sat, 17 Jun 2000 01:25:24 -0400 From: Tom Zerucha To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Revised MDC packet spec Message-ID: <20000617012524.A18894@deimos.mw.mediaone.net> References: <200006162140.OAA08433@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jon@callas.org on Fri, Jun 16, 2000 at 05:38:28PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 16, 2000 at 05:38:28PM -0700, Jon Callas wrote: > Or maybe we should just do the sync anyway. > > It's one thing to not be standard, but it's another to not be consistent. > The only thing that one can complain about PGP-CFB for is that it's not > standard CFB. I don't see that as an issue. > > Other systems, like CMS, use CBC mode not CFB at all, so we're no less > different even if we switch. > > I would prefer to keep one encryption mode and use it everywhere. The one > to use, is of course PGP-CFB. However, if we're going to change it, we > should discuss using CBC mode. I agree with this since I separate the operators from the core, though cfb mode is one of the standard calls in openssl. For all else I have a cfbomatic routine. However wasn't there something about NOT resetting if the block length for the cipher was over 9 bytes in length? Let me bring up another consideration (while looking for the above). 3.6.2.1... These are followed by an 8-octet Initial Vector for the decryption of the secret values, if they are encrypted, and then the secret key values themselves. 5.5.3... - [Optional] If secret data is encrypted, eight-octet Initial Vector (IV). and With V3 keys, the MPI bit count prefix (i.e., the first two octets) is not encrypted. Only the MPI non- prefix data is encrypted. Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, so that the CFB block bou The symmetric ciphers are used more than one place - one is for unlocking secret keys, and we have resyncs here. So what happens for secret keys using a cipher with a 128 bit block size? Do we use 16 octet IVs? Do we resync on mpi boundaries for a V3 key (is this possible - I don't see anywhere in the spec where it says you MUST use IDEA to encrypt V3 secret key material)? (Actually I have a problem in my current opgp implementation since I don't support block sizes other than 8 bytes (no, I refuse to always use "octet"), but as soon as I can get the new algorithms going I know where and how to fix it). Received: by ns.secondary.com (8.9.3/8.9.3) id RAA26531 for ietf-openpgp-bks; Fri, 16 Jun 2000 17:56:42 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26527 for ; Fri, 16 Jun 2000 17:56:41 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA09930 for ; Fri, 16 Jun 2000 17:55:58 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA09926 for ; Fri, 16 Jun 2000 17:55:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200006162140.OAA08433@finney.org> References: <200006162140.OAA08433@finney.org> Date: Fri, 16 Jun 2000 17:38:28 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Revised MDC packet spec Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Or maybe we should just do the sync anyway. It's one thing to not be standard, but it's another to not be consistent. The only thing that one can complain about PGP-CFB for is that it's not standard CFB. I don't see that as an issue. Other systems, like CMS, use CBC mode not CFB at all, so we're no less different even if we switch. I would prefer to keep one encryption mode and use it everywhere. The one to use, is of course PGP-CFB. However, if we're going to change it, we should discuss using CBC mode. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id OAA24689 for ietf-openpgp-bks; Fri, 16 Jun 2000 14:40:22 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA24685 for ; Fri, 16 Jun 2000 14:40:21 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id OAA08433; Fri, 16 Jun 2000 14:40:07 -0700 Date: Fri, 16 Jun 2000 14:40:07 -0700 Message-Id: <200006162140.OAA08433@finney.org> To: ietf-openpgp@imc.org, tz@execpc.com Subject: Re: Revised MDC packet spec Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Tom writes, quoting Werner: > > One suggestion: Add a note that the old PGP sync mode is not used with > > the wew packet 18. > > Did I miss something? The description of the new type 18 packet > indicates a prefix that looks like the PGP-sync prefix used elsewhere. > > But I didn't see the resync operation that is done everywhere else (I > didn't read that carefully). > > So if I understand correctly, we are going to use the prefix but NOT > going to do the resync? That's correct. This is for two reasons: one is that the sync is nonstandard and has caused problems. Perhaps someday we can deprecate the old symmetric encryption packet and eliminate the sync altogether. The second reason is to make the encrypted data in these packets more different from the data in the old packets, making it less likely that an attacker could turn a new packet into an old one. Maybe as Werner said the spec should have an explicit note confirming that the sync is not done in this packet. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24199 for ietf-openpgp-bks; Fri, 16 Jun 2000 13:53:29 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA24195 for ; Fri, 16 Jun 2000 13:53:27 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c66-230.mw.mediaone.net [24.30.66.230]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id QAA04999 for ; Fri, 16 Jun 2000 16:53:12 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id QAA16185 for ietf-openpgp@imc.org; Fri, 16 Jun 2000 16:53:10 -0400 Date: Fri, 16 Jun 2000 16:53:09 -0400 From: Tom Zerucha To: ietf-openpgp@imc.org Subject: Re: Revised MDC packet spec Message-ID: <20000616165309.A16176@deimos.mw.mediaone.net> References: <200006152228.PAA05145@finney.org> <20000616094234.F2464@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000616094234.F2464@djebel.gnupg.de>; from wk@gnupg.org on Fri, Jun 16, 2000 at 09:42:34AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Jun 16, 2000 at 09:42:34AM +0200, Werner Koch wrote: > Hi, > > On Thu, 15 Jun 2000, hal@finney.org wrote: > > > Based on internal discussions we would like to make a small change to > > the Symmetrically Encrypted Integrity Protected Data Packet format. > > This is fine with me. > > One suggestion: Add a note that the old PGP sync mode is not used with > the wew packet 18. Did I miss something? The description of the new type 18 packet indicates a prefix that looks like the PGP-sync prefix used elsewhere. But I didn't see the resync operation that is done everywhere else (I didn't read that carefully). So if I understand correctly, we are going to use the prefix but NOT going to do the resync? Received: by ns.secondary.com (8.9.3/8.9.3) id AAA18544 for ietf-openpgp-bks; Fri, 16 Jun 2000 00:31:40 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA18531 for ; Fri, 16 Jun 2000 00:31:37 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 132qlu-0000el-00; Fri, 16 Jun 2000 09:42:34 +0200 Date: Fri, 16 Jun 2000 09:42:34 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Revised MDC packet spec Message-ID: <20000616094234.F2464@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200006152228.PAA05145@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <200006152228.PAA05145@finney.org>; from hal@finney.org on Thu, Jun 15, 2000 at 03:28:08PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, On Thu, 15 Jun 2000, hal@finney.org wrote: > Based on internal discussions we would like to make a small change to > the Symmetrically Encrypted Integrity Protected Data Packet format. This is fine with me. One suggestion: Add a note that the old PGP sync mode is not used with the wew packet 18. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA05383 for ietf-openpgp-bks; Thu, 15 Jun 2000 15:28:30 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA05378 for ; Thu, 15 Jun 2000 15:28:28 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA05145 for ietf-openpgp@imc.org; Thu, 15 Jun 2000 15:28:08 -0700 Date: Thu, 15 Jun 2000 15:28:08 -0700 Message-Id: <200006152228.PAA05145@finney.org> To: ietf-openpgp@imc.org Subject: Revised MDC packet spec Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Based on internal discussions we would like to make a small change to the Symmetrically Encrypted Integrity Protected Data Packet format. We would like to include the random bytes which precede the plaintext in the hash. This will make the hash value less predictable and would make an attacker's job harder. It is also somewhat simpler conceptually because now the material which is hashed is the same as the material which is encrypted, except for the last 20 bytes. Also Werner pointed out a typo in the previous draft, the 0xD0 value should be 0xD3 to match the MDC packet CTB. The revised draft follows. Hal Finney PGP.COM ============ 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18) The Symmetrically Encrypted Integrity Protected Data packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The last such decrypted packet must be a Modification Detection Code packet. The body of this packet consists of: - A one-octet version number. The only currently defined value is 1. - Encrypted data, the output of the selected symmetric-key cipher operating in Cipher Feedback mode with shift amount equal to the block size of the cipher (CFB-n where n is the block size). The symmetric cipher used MUST be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data Packet. In either case, the cipher algorithm octet is prefixed to the session key before it is encrypted. The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes an octet string to the data before it is encrypted. The length of the octet string equals the block size of the cipher in octets, plus two. The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet. For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectivelly. Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data. The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. Specifically, the input to the hash function includes the prefix octet string described above (equal in length to the cipher block size, plus two octets), followed by all of the plaintext, and then also two octets of values 0xD3, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets. The resulting hash value is stored in a Modification Detection Code packet which MUST use the two octet encoding just given to represent its tag and length field. The body of the MDC packet is the 20 octet output of the SHA-1 hash. The Modification Detection Code packet is appended to the plaintext and encrypted along with the plaintext using the same CFB context. During decryption, the decrypted data should be hashed with SHA-1, including the prefix octet string, the plaintext itself and also the packet tag and length field of the Modification Detection Code packet. The body of the MDC packet, upon decryption, should be compared with the result of the SHA-1 hash. Any difference in hash values is an indication that the message has been modified and SHOULD be reported to the user. Likewise, the absence of an MDC packet, or an MDC packet in any position other than the end of the plaintext, also represent message modifications and SHOULD also be reported. Note: future designs of new versions of this packet should consider rollback attacks since it will be possible for an attacker to change the version back to 1. 5.Y Modification Detection Code Packet (Tag 19) The Modification Detection Code packet contains a SHA-1 hash of plaintext data which is used to detect message modification. It is only used in the context of a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data which is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place. A Modification Detection Code packet MUST have a length of 20 octets. The body of this packet consists of: - A 20-octet SHA-1 hash of the preceding plaintext data of the Symmetrically Encrypted Integrity Protected Data packet, not including prefix data but including the tag and length byte of the Modification Detection Code packet. Note that the Modification Detection Code packet MUST always use a new-format encoding of the packet tag, and a one-octet encoding of the packet length. (These requirements are already imposed by the rules for tag and length encoding.) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA03911 for ietf-openpgp-bks; Thu, 15 Jun 2000 14:04:41 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA03907 for ; Thu, 15 Jun 2000 14:04:38 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 7357 invoked from network); 15 Jun 2000 20:59:13 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2000 20:59:13 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <200006152052.NAA04662@finney.org> References: <200006152052.NAA04662@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000616060416X.1001@eccosys.com> Date: Fri, 16 Jun 2000 06:04:16 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 46 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Thu, 15 Jun 2000 13:52:59 -0700 Message-ID: <200006152052.NAA04662@finney.org> > > > So far in this thread, two methods of encrypting headers have been > > > discussed: encapsulating a complete message in a message/rfc822 and > > > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > > > encryption and the first probably inter-operates quite well amongst > > > existing PGP/MIME or S/MIME clients. > > > > at this point, i'd like to see the methods mentioned/referred to in > > some specification so i can point mail client developers at such a > > document for the purposes of having them work on implementations that > > will interoperate. > > I don't see what any of this has to do with OpenPGP. Modifying SMTP > is clearly out of our scope, and message/rfc822 is already defined in > the MIME spec. We don't have anything to do with this, and IMO this > discussion should be transferred elsewhere. i think an important point is that if you look at the openpgp/mime spec or the openpgp spec as they stand now, they don't explicitly mention either of the methods for protecting header information of messages. at least i didn't notice any mention of them...perhaps i miseed something? last i checked, the headers are part of the message -- if one of the goals of openpgp/mime is to protect message confidentiality, then i think it's relevant to at least mention the aforementioned methods in one of the openpgp specs. how many mail clients claim pgp/mime compatibility? http://www.cryptorights.org/pgp-users/pgp-mail-clients.html how many of those protect message headers? there may be a few, but i have yet to encouter one. i think this is a problem that could be addressed by placing a disucssion of the issue in an existing spec or to create a new spec for that purpose. it is far more likely for header protection to be implemented that way. we may disagree about how important header protection is, but it seems pretty related to openpgp (at least openpgp/mime) to me. Received: by ns.secondary.com (8.9.3/8.9.3) id NAA03625 for ietf-openpgp-bks; Thu, 15 Jun 2000 13:53:21 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA03621 for ; Thu, 15 Jun 2000 13:53:19 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id NAA04662; Thu, 15 Jun 2000 13:52:59 -0700 Date: Thu, 15 Jun 2000 13:52:59 -0700 Message-Id: <200006152052.NAA04662@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > So far in this thread, two methods of encrypting headers have been > > discussed: encapsulating a complete message in a message/rfc822 and > > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > > encryption and the first probably inter-operates quite well amongst > > existing PGP/MIME or S/MIME clients. > > at this point, i'd like to see the methods mentioned/referred to in > some specification so i can point mail client developers at such a > document for the purposes of having them work on implementations that > will interoperate. I don't see what any of this has to do with OpenPGP. Modifying SMTP is clearly out of our scope, and message/rfc822 is already defined in the MIME spec. We don't have anything to do with this, and IMO this discussion should be transferred elsewhere. Hal Finney Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00977 for ietf-openpgp-bks; Thu, 15 Jun 2000 12:47:01 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00973 for ; Thu, 15 Jun 2000 12:46:59 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 6040 invoked from network); 15 Jun 2000 19:41:34 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2000 19:41:34 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000616044636N.1001@eccosys.com> Date: Fri, 16 Jun 2000 04:46:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ian Bell Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Fri, 9 Jun 2000 13:55:44 +0100 Message-ID: > On Fri, 2 Jun 2000, Ian BROWN wrote: > >This is a really important thing we need to sort out. There was extensive > >discussion of it almost two years ago (!) but I don't know if that resulted in > >anything in the PGP/MIME draft. > > > >Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last > >e-mail on the subject, but you can read the discussion in the archives at > >www.imc.org > > So far in this thread, two methods of encrypting headers have been > discussed: encapsulating a complete message in a message/rfc822 and > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > encryption and the first probably inter-operates quite well amongst > existing PGP/MIME or S/MIME clients. at this point, i'd like to see the methods mentioned/referred to in some specification so i can point mail client developers at such a document for the purposes of having them work on implementations that will interoperate. even w/ some kind of endorsement in the form of being present in a specification, it may take a while for header (and/or envelope) protection to be implemented at the user-level -- i.e. there is a single command a user can use to create such header-protected messages. so, any plans or takers on this point? Received: by ns.secondary.com (8.9.3/8.9.3) id MAA00903 for ietf-openpgp-bks; Thu, 15 Jun 2000 12:43:09 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA00899 for ; Thu, 15 Jun 2000 12:43:07 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 5987 invoked from network); 15 Jun 2000 19:37:41 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 15 Jun 2000 19:37:41 -0000 To: ietf-openpgp@imc.org Subject: Re: Is there a fully searchable Open-PGP Archive? In-Reply-To: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> References: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000616044243R.1001@eccosys.com> Date: Fri, 16 Jun 2000 04:42:43 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 15 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: Is there a fully searchable Open-PGP Archive? Date: Thu, 15 Jun 2000 10:14:25 +0800 Message-ID: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> > Does anyone know of a fully searchable Open-PGP archive? i don't know of one. i'd be glad to be informed of one. in the mean time, i suppose the "entire archive" (perhaps it's in two pieces now?) mentioned at: http://www.imc.org/ietf-openpgp/ can be downloaded and searched locally... Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08411 for ietf-openpgp-bks; Wed, 14 Jun 2000 19:24:04 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA08396 for ; Wed, 14 Jun 2000 19:23:59 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0CBC66027A; Thu, 15 Jun 2000 10:22:19 PDT Message-Id: <4.3.0.20000615095055.00b3acb0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Thu, 15 Jun 2000 10:14:25 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Is there a fully searchable Open-PGP Archive? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Does anyone know of a fully searchable Open-PGP archive? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id XAA27336 for ietf-openpgp-bks; Mon, 12 Jun 2000 23:52:03 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA27326 for ; Mon, 12 Jun 2000 23:51:58 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AC8237AB0298; Tue, 13 Jun 2000 14:49:54 PDT Message-Id: <4.3.0.20000613142845.00b5ef00@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 13 Jun 2000 14:42:07 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Open-PGP Q re DSA and keys > 1024 bit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Upon reading 2440bis re DSA and a PGP key length limit of 1024 bits, I was wondering what the Open-PGP group recommends for signing if you use PGP keys > 1024 bits? If you do use PGP Keys > 1024 bits, should you have another set of keys <=1024 bits for signing or is there a standard way to reduce 2048 bit PGP keys down to 1024 bits suitable for the DSA signature algorithm? TIA for any info. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id HAA03235 for ietf-openpgp-bks; Mon, 12 Jun 2000 07:39:04 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA03231 for ; Mon, 12 Jun 2000 07:39:02 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQitgs04238; Mon, 12 Jun 2000 14:38:12 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA27156; Mon, 12 Jun 00 10:34:35 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA04839; Mon, 12 Jun 2000 10:38:11 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14660.62930.973835.485437@xedia.com> Date: Mon, 12 Jun 2000 10:38:10 -0400 (EDT) To: ejc@comasp.com Cc: ietf-openpgp@imc.org Subject: Re: Hidden session key generation & storage References: <4.3.0.20000612103737.00b404f0@mail.comasp.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Erron" == Erron Criddle writes: Erron> To all, This is only slightly related to PGP, however: Erron> I was wondering if there is some "standard" out there that Erron> defines how a session key is stored/saved/hidden after a file Erron> is encrypted and stored on a computer system using the same Erron> key. Ideally, the only thing that *should* be able to decrypt Erron> the file is the same computer program that generated the key. No. Done correctly, the only way to decrypt the file is for the human who owns the key to supply that key. That is the PGP way... Erron> You can play around with binary files, the XOR function, CRC Erron> checks, Hashing algorithms and a host of other "tricks" to Erron> "make life very difficult" for the reverse engineer, however Erron> is there a 100% secure way for an executable to encrypt and Erron> store data (to be decrypted later on by the same program)? No, there is not. That's why programs that offer real security DO NOT DO THIS. If you see a program that does do this -- i.e., can decrypt your encrypted file without asking you for the key -- then it is by definition insecure and should be thrown in the garbage can. paul Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12057 for ietf-openpgp-bks; Sun, 11 Jun 2000 19:57:22 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA12053 for ; Sun, 11 Jun 2000 19:57:19 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A40611C80298; Mon, 12 Jun 2000 10:55:18 PDT Message-Id: <4.3.0.20000612103737.00b404f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 12 Jun 2000 10:47:37 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Hidden session key generation & storage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, This is only slightly related to PGP, however: I was wondering if there is some "standard" out there that defines how a session key is stored/saved/hidden after a file is encrypted and stored on a computer system using the same key. Ideally, the only thing that *should* be able to decrypt the file is the same computer program that generated the key. You can play around with binary files, the XOR function, CRC checks, Hashing algorithms and a host of other "tricks" to "make life very difficult" for the reverse engineer, however is there a 100% secure way for an executable to encrypt and store data (to be decrypted later on by the same program)? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id TAA08350 for ietf-openpgp-bks; Sun, 11 Jun 2000 19:29:25 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA08346 for ; Sun, 11 Jun 2000 19:29:23 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQHKG7A3OG000E2F@mauve.mrochek.com> for ietf-openpgp@imc.org; Sun, 11 Jun 2000 19:28:42 -0700 (PDT) Date: Sun, 11 Jun 2000 19:26:42 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Mon, 12 Jun 2000 10:15:49 +0900" <20000612101549S.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQHKWZDEDI000E2F@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQC5NHEOFM0009XA@mauve.mrochek.com> <20000609123752V.1001@eccosys.com> <01JQDIJWZ2LC0009XA@mauve.mrochek.com> <01JQDIJWZ2LC0009XA@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > There are a bunch, although many of them are likely not in full compliance > > with the RFC, which specifies support for certain aspects of ESMTP. > > Remember, the entire BITNET network was implemented using BSMTP to get > > around the 8X8 address limit of NJE. In its heyday BITNET amounted to > > several thousand systems running on a variety of hardware and software > > platforms. > i was an email-only user (i.e. not a user w/ administrative knowledge) > when i was using bitnet, so i cannot claim to have any in-depth > knowledge. thanks for the explanation though. > > One implementation that is up to date is the one in PMDF, which is descended > > from our BITNET handling code. The same code is also in SIMS. > thank you very much for the pointers. > > I also doubt if we would have written the specification had we not had an > > actual implementation in hand. The BITNET experience showed that turning an > > interactive protocol into a batch protocol has some subtle spots to it. > in your opinion, are those subtle spots adequately and comprehensively > covered in the rfc? Yes they are. Indeed, this was the entire point of writing the RFC -- to explain how this can be done and what the issues are with doing it. > i ask because if bsmtp encapsulation is to become > widely used (assuming here that it isn't at the moment), it seems to > me that there may have to be a few more implementations. Frankly, I doubt if it will ever be widely used. But writing the document seemed to be useful given that there have been a fair number of implementations in the past and they didn't get it right without a specification. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id SAA02108 for ietf-openpgp-bks; Sun, 11 Jun 2000 18:41:25 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA02097 for ; Sun, 11 Jun 2000 18:41:23 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 8101 invoked from network); 12 Jun 2000 01:35:49 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 12 Jun 2000 01:35:49 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000612104040U.1001@eccosys.com> Date: Mon, 12 Jun 2000 10:40:40 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 58 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ian Bell Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Fri, 9 Jun 2000 13:55:44 +0100 Message-ID: > So far in this thread, two methods of encrypting headers have been > discussed: encapsulating a complete message in a message/rfc822 and > encapsulating an SMTP session in BSMTP. Both can be used for end-to-end > encryption and the first probably inter-operates quite well amongst > existing PGP/MIME or S/MIME clients. > > However, encrypting message headers could also be potentially useful for > protecting stored messages as well, but here the message/rfc822 solution > is not so useful (and BSMTP not appropriate at all). i used to think this might be a good idea, but i started thinking that encrypting filesystems or directories where the messages are stored (on the server end in your imap example) might be a better solution. on the other hand, messages are sometimes stored w/in databases...unless most databases support the notion of encrypting records, i guess this could be problematic in that case, but may be databases should support encryption/decryption. > For instance, an IMAP client may want to allow its users to encrypt all > messages being archived on an IMAP server in order to protect the user > against any server security event. right, so you can protect against having the message contents revealed and w/ signing against message content being tampered w/. not to say this idea isn't useful, but i don't know how to protect against deletion. > It could do this by encapsulating existing messages in a > message/rfc822 and holding the resulting encrypted message in a > vanilla outer message header (e.g. no subject, all addressees set to > the user themselves etc...). > > However if this is done to lots of messages, the problem arises that the > user won't be able to distinguish between messages without the client > downloading and decrypting all messages (including bodies) first! another approach: encrypted messages a user receives could initially be decrypted on the client end, modified to a decrypted form and placed again on the server (whether they replace the original messages could be a policy decision). the server could implement confidentiality services through local store (e.g. filesystem, directory, etc.) encryption -- a key for decryption could be requested from the user during imap authentication (or computed using authentication info). all messages for a given user on the server end could then be protected using this key. before imap (or pop) processing occurs, messages are decrypted. when the processing is complete (e.g. imap session ends), messages are encrypted. Received: by ns.secondary.com (8.9.3/8.9.3) id SAA26999 for ietf-openpgp-bks; Sun, 11 Jun 2000 18:07:11 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA26988 for ; Sun, 11 Jun 2000 18:07:09 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 7728 invoked from network); 12 Jun 2000 01:10:56 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 12 Jun 2000 01:10:56 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQDIJWZ2LC0009XA@mauve.mrochek.com> References: <01JQC5NHEOFM0009XA@mauve.mrochek.com> <20000609123752V.1001@eccosys.com> <01JQDIJWZ2LC0009XA@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000612101549S.1001@eccosys.com> Date: Mon, 12 Jun 2000 10:15:49 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 33 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Thu, 08 Jun 2000 21:27:45 -0700 (PDT) Message-ID: <01JQDIJWZ2LC0009XA@mauve.mrochek.com> ... > > p.s. does anyone know of any bsmtp processor implementations? > > There are a bunch, although many of them are likely not in full compliance > with the RFC, which specifies support for certain aspects of ESMTP. > Remember, the entire BITNET network was implemented using BSMTP to get > around the 8X8 address limit of NJE. In its heyday BITNET amounted to > several thousand systems running on a variety of hardware and software > platforms. i was an email-only user (i.e. not a user w/ administrative knowledge) when i was using bitnet, so i cannot claim to have any in-depth knowledge. thanks for the explanation though. > One implementation that is up to date is the one in PMDF, which is descended > from our BITNET handling code. The same code is also in SIMS. thank you very much for the pointers. > I also doubt if we would have written the specification had we not had an > actual implementation in hand. The BITNET experience showed that turning an > interactive protocol into a batch protocol has some subtle spots to it. in your opinion, are those subtle spots adequately and comprehensively covered in the rfc? i ask because if bsmtp encapsulation is to become widely used (assuming here that it isn't at the moment), it seems to me that there may have to be a few more implementations. Received: by ns.secondary.com (8.9.3/8.9.3) id FAA13639 for ietf-openpgp-bks; Fri, 9 Jun 2000 05:49:40 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA13635 for ; Fri, 9 Jun 2000 05:49:38 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id NAA13232; Fri, 9 Jun 2000 13:58:06 +0100 (BST) Message-ID: Date: Fri, 9 Jun 2000 13:55:44 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> In-Reply-To: <515.959941721@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 2 Jun 2000, Ian BROWN wrote: >This is a really important thing we need to sort out. There was extensive >discussion of it almost two years ago (!) but I don't know if that resulted in >anything in the PGP/MIME draft. > >Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last >e-mail on the subject, but you can read the discussion in the archives at >www.imc.org So far in this thread, two methods of encrypting headers have been discussed: encapsulating a complete message in a message/rfc822 and encapsulating an SMTP session in BSMTP. Both can be used for end-to-end encryption and the first probably inter-operates quite well amongst existing PGP/MIME or S/MIME clients. However, encrypting message headers could also be potentially useful for protecting stored messages as well, but here the message/rfc822 solution is not so useful (and BSMTP not appropriate at all). For instance, an IMAP client may want to allow its users to encrypt all messages being archived on an IMAP server in order to protect the user against any server security event. It could do this by encapsulating existing messages in a message/rfc822 and holding the resulting encrypted message in a vanilla outer message header (e.g. no subject, all addressees set to the user themselves etc...). However if this is done to lots of messages, the problem arises that the user won't be able to distinguish between messages without the client downloading and decrypting all messages (including bodies) first! Two things seem to be needed to usefully support this sort of stored message encryption: the ability of a client to know that there are some replacement headers in an encrypted message and the ability of the client to decrypt those headers independently of the body. This could be accomplished using an unencrypted multipart message, where the first part could hold the headers (text/rfc822-headers, encrypted using PGP/MIME or S/MIME) and the second part could hold the body (again encrypted). If a new type were defined (multipart/rfc822?), an IMAP client could recognize the top level Content-Type, download and decrypt the secure headers and thereafter display the decrypted header information to the user. Just an idea, but without something like this, re-encrypting messages for storage involves either making the user enter alternative header details, or not securing the headers in the first place. -- Ian Bell T U R N P I K E Ltd Received: by ns.secondary.com (8.9.3/8.9.3) id VAA10731 for ietf-openpgp-bks; Thu, 8 Jun 2000 21:29:20 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA10723 for ; Thu, 8 Jun 2000 21:29:19 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQBUZBCTDC0009XA@mauve.mrochek.com> for ietf-openpgp@imc.org; Thu, 08 Jun 2000 21:37:44 -0700 (PDT) Date: Thu, 08 Jun 2000 21:27:45 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Fri, 09 Jun 2000 12:37:52 +0900" <20000609123752V.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQDIJWZ2LC0009XA@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> <20000608134840J.1001@eccosys.com> <01JQC5NHEOFM0009XA@mauve.mrochek.com> <01JQC5NHEOFM0009XA@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: ned.freed@innosoft.com > Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? > Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT) > Message-ID: <01JQC5NHEOFM0009XA@mauve.mrochek.com> > > > for RCPT TO though, the best i've come up w/ so far is to specify an > > > address that forwards received messages to other forwarders or to the > > > ultimate recipient. is it possible to do better than this? > > > > The RCPT TO needs to be the address of the BSMTP processor. > hmm, so making the RCPT TO (of the outer envelope) an address that > will forward to the address of the BSMTP processor won't work? i > don't understand why. what am i missing? Nothing; it can be any address that gets to the processor. Any amount of aliasing or forwarding is fine. But the more actual recipients associated with a single outer address, the better. > p.s. does anyone know of any bsmtp processor implementations? There are a bunch, although many of them are likely not in full compliance with the RFC, which specifies support for certain aspects of ESMTP. Remember, the entire BITNET network was implemented using BSMTP to get around the 8X8 address limit of NJE. In its heyday BITNET amounted to several thousand systems running on a variety of hardware and software platforms. One implementation that is up to date is the one in PMDF, which is descended from our BITNET handling code. The same code is also in SIMS. I also doubt if we would have written the specification had we not had an actual implementation in hand. The BITNET experience showed that turning an interactive protocol into a batch protocol has some subtle spots to it. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06771 for ietf-openpgp-bks; Thu, 8 Jun 2000 20:29:29 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA06755 for ; Thu, 8 Jun 2000 20:29:25 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 18899 invoked from network); 9 Jun 2000 03:33:08 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 9 Jun 2000 03:33:08 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQC5NHEOFM0009XA@mauve.mrochek.com> References: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> <20000608134840J.1001@eccosys.com> <01JQC5NHEOFM0009XA@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000609123752V.1001@eccosys.com> Date: Fri, 09 Jun 2000 12:37:52 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT) Message-ID: <01JQC5NHEOFM0009XA@mauve.mrochek.com> > > for RCPT TO though, the best i've come up w/ so far is to specify an > > address that forwards received messages to other forwarders or to the > > ultimate recipient. is it possible to do better than this? > > The RCPT TO needs to be the address of the BSMTP processor. hmm, so making the RCPT TO (of the outer envelope) an address that will forward to the address of the BSMTP processor won't work? i don't understand why. what am i missing? > You can have a single processor for a large number of individual > users, and if you do this, you cannot tell from the outer envelope > what user is being sent to. Not knowing the specific user makes > traffic analysis a heck of a lot harder. yes, i suppose it does increase the amount of work that must be done -- i guess that amount is related to how much use the bsmtp processor is getting and by how many users. so there should be incentive to use a processor that is heavily used and by a lot of users. i suppose one can place encrypted bsmtp objects inside of bsmtp objects and do chaining of bsmtp processors... thanks very much for the explanations. p.s. does anyone know of any bsmtp processor implementations? Received: by ns.secondary.com (8.9.3/8.9.3) id JAA28648 for ietf-openpgp-bks; Thu, 8 Jun 2000 09:08:38 -0700 (PDT) Received: from mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA28631 for ; Thu, 8 Jun 2000 09:08:29 -0700 (PDT) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3IFA62U@mta5.rcsntx.swbell.net> for ietf-openpgp@imc.org; Thu, 8 Jun 2000 11:05:52 -0500 (CDT) Date: Thu, 08 Jun 2000 11:05:52 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ietf-openpgp@imc.org Message-id: <0FVU00DK7FDP2U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson Received: by ns.secondary.com (8.9.3/8.9.3) id WAA27503 for ietf-openpgp-bks; Wed, 7 Jun 2000 22:09:41 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA27499 for ; Wed, 7 Jun 2000 22:09:40 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQBUZBCTDC0009XA@mauve.mrochek.com> for ietf-openpgp@imc.org; Wed, 07 Jun 2000 22:17:58 -0700 (PDT) Date: Wed, 07 Jun 2000 22:15:09 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Thu, 08 Jun 2000 13:48:40 +0900" <20000608134840J.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQC5NHEOFM0009XA@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQAISQBPXO00088W@mauve.mrochek.com> <20000607103920M.1001@eccosys.com> <01JQAOGAY4ES0007JQ@mauve.mrochek.com> <01JQAOGAY4ES0007JQ@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > i see that the MAIL FROM info for the container message can be made > different from the corresponding information in the bsmtp object w/o > having adverse affects on delivery. > for RCPT TO though, the best i've come up w/ so far is to specify an > address that forwards received messages to other forwarders or to the > ultimate recipient. is it possible to do better than this? The RCPT TO needs to be the address of the BSMTP processor. You can have a single processor for a large number of individual users, and if you do this, you cannot tell from the outer envelope what user is being sent to. Not knowing the specific user makes traffic analysis a heck of a lot harder. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24278 for ietf-openpgp-bks; Wed, 7 Jun 2000 21:40:21 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA24267 for ; Wed, 7 Jun 2000 21:40:19 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 27040 invoked from network); 8 Jun 2000 04:44:00 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 8 Jun 2000 04:43:59 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> References: <01JQAISQBPXO00088W@mauve.mrochek.com> <20000607103920M.1001@eccosys.com> <01JQAOGAY4ES0007JQ@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000608134840J.1001@eccosys.com> Date: Thu, 08 Jun 2000 13:48:40 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Tue, 06 Jun 2000 20:48:38 -0700 (PDT) Message-ID: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> ... > > assuming envelope information is protected using rfc 2442, is there a > > recommended mechanism for actually getting the encapsulated message > > to the receiving end? not anonymous remailers... > > Recommended, no. In practice regular SMTP is often used, in effect creating a > variety of secure tunnel. i see that the MAIL FROM info for the container message can be made different from the corresponding information in the bsmtp object w/o having adverse affects on delivery. for RCPT TO though, the best i've come up w/ so far is to specify an address that forwards received messages to other forwarders or to the ultimate recipient. is it possible to do better than this? what am i missing? thanks for bearing w/ me. p.s. is this an appropriate place to discuss rfc 2442? if not, is there some other place? Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14514 for ietf-openpgp-bks; Wed, 7 Jun 2000 12:35:30 -0700 (PDT) Received: from rgate.ricochet.net (rgate.ricochet.net [204.179.143.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14509 for ; Wed, 7 Jun 2000 12:35:28 -0700 (PDT) Received: from workstation.tillerman.to (mg-20425424-61.ricochet.net [204.254.24.61]) by rgate.ricochet.net (8.9.3/8.9.3) with ESMTP id OAA17798; Wed, 7 Jun 2000 14:41:12 -0500 (CDT) Message-Id: <4.3.2.6.2.20000607123431.00b23ae0@module-two.rwthayer.com> X-Sender: rodney@module-two.rwthayer.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Wed, 07 Jun 2000 12:35:17 -0700 To: Dave Crocker , ietf-openpgp@imc.org From: Rodney Thayer Subject: Re: patents? In-Reply-To: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> References: <4.3.2.6.2.20000531164608.02e00a50@module-two.rwthayer.com> <200005312006.QAA26250@domains.invweb.net> <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, but after the RFC has a number and after there is widespread common use of a technology goes over into the "they never enforced their patent" area. I mostly said what I said to shake any stealth lawyers out of the trees, which seems to not have happened. One can never stop scanning for submarine patents. they pop at the most annoying times... At 05:24 PM 5/31/00 -0700, Dave Crocker wrote: >At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote: >>Being as no evil lawyers from NAI or elsewhere have swooped down on this >>list or on the IETF I'd say it's safe for now. >> >>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >>>Probably just standard boilerplate. They are just putting you on notice >>>that by publishing their source code they are not giving up any rights >>>that the may hold on the code. > >You are both being far too optimistic. While it is possible that you are >correct, it is equally possible -- and many would say more likely -- that >patents are, in fact, held or being prosecuted. > >The IETF has had some patents emerge very late in the process, so the >concern is not academic. > >d/ > > >=-=-=-=-= >Dave Crocker >Brandenburg Consulting >Tel: +1.408.246.8253, Fax: +1.408.273.6464 >675 Spruce Drive, Sunnyvale, CA 94086 USA Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19944 for ietf-openpgp-bks; Tue, 6 Jun 2000 20:46:10 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19926 for ; Tue, 6 Jun 2000 20:46:08 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQANTYB4I80007JQ@mauve.mrochek.com> for ietf-openpgp@imc.org; Tue, 06 Jun 2000 20:54:15 -0700 (PDT) Date: Tue, 06 Jun 2000 20:48:38 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Wed, 07 Jun 2000 10:39:20 +0900" <20000607103920M.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQAOGAY4ES0007JQ@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQ7WIKK0280001I2@mauve.mrochek.com> <20000605140812F.1001@eccosys.com> <01JQAISQBPXO00088W@mauve.mrochek.com> <01JQAISQBPXO00088W@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > thanks for the clarification. > From: ned.freed@innosoft.com > Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? > Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT) > Message-ID: <01JQAISQBPXO00088W@mauve.mrochek.com> > > Two words: traffic analysis. Knowing who's getting a message is > > often enough to tell you something even if the contents are > > obscured. > sure. so the "There are many applications" statement referred to > applications where the traffic analysis of envelope information is > relevant. is that a reasonable interpretation? also, did you have > other things in mind? Signing the envelope also has its applications -- it prevents some forms of envelope tampering that might otherwise be used in some sorts of attacks. > assuming envelope information is protected using rfc 2442, is there a > recommended mechanism for actually getting the encapsulated message > to the receiving end? not anonymous remailers... Recommended, no. In practice regular SMTP is often used, in effect creating a variety of secure tunnel. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id SAA29980 for ietf-openpgp-bks; Tue, 6 Jun 2000 18:31:09 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA29969 for ; Tue, 6 Jun 2000 18:31:06 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 1684 invoked from network); 7 Jun 2000 01:34:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 7 Jun 2000 01:34:45 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQAISQBPXO00088W@mauve.mrochek.com> References: <01JQ7WIKK0280001I2@mauve.mrochek.com> <20000605140812F.1001@eccosys.com> <01JQAISQBPXO00088W@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000607103920M.1001@eccosys.com> Date: Wed, 07 Jun 2000 10:39:20 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 28 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: thanks for the clarification. From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT) Message-ID: <01JQAISQBPXO00088W@mauve.mrochek.com> > Two words: traffic analysis. Knowing who's getting a message is > often enough to tell you something even if the contents are > obscured. sure. so the "There are many applications" statement referred to applications where the traffic analysis of envelope information is relevant. is that a reasonable interpretation? also, did you have other things in mind? assuming envelope information is protected using rfc 2442, is there a recommended mechanism for actually getting the encapsulated message to the receiving end? not anonymous remailers... i suppose one of these days we'll end up seeing all anonymous remailer functionality provided via several standards documents...i think that leaves: splitting messages up into equal size pieces (+ reassembly on the receiving end of course), sending cover traffic, pooling message pieces, making message pieces traverse different paths...am i missing anything? :-) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA24191 for ietf-openpgp-bks; Tue, 6 Jun 2000 18:04:21 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA24182 for ; Tue, 6 Jun 2000 18:04:20 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQADWFKSA800088W@mauve.mrochek.com> for ietf-openpgp@imc.org; Tue, 06 Jun 2000 18:12:28 -0700 (PDT) Date: Tue, 06 Jun 2000 18:11:55 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Mon, 05 Jun 2000 14:08:12 +0900" <20000605140812F.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQAISQBPXO00088W@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <01JQ50WA0ESA0004AW@mauve.mrochek.com> <20000605115419X.1001@eccosys.com> <01JQ7WIKK0280001I2@mauve.mrochek.com> <01JQ7WIKK0280001I2@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: ned.freed@innosoft.com > Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? > Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT) > Message-ID: <01JQ7WIKK0280001I2@mauve.mrochek.com> > ... > > > does that sound about right? > > > > Yes, except that the protection extends to the envelope when you use BSMTP. > > If all you want to protect is the header it is easier to just use a > > message/rfc822 MIME encapsulation. > so to protect the confidentiality of the Subject header: > sending side > 1) create a rfc 822 message (contains Subject) > 2) mime encapsulate the message > 3) encrypt (and optionally sign) > 4) send the message > receiving side > 5) receive the message > 6) decrypt (and optionally verify signature) > 7) extract (recreate) the original message > 8) read as usual (can see the Subject) > right? > if there is no better method yet, imo, it would be a good idea for > this method of protecting headers to receive some kind of > "endorsement" (e.g. mentioned in the openpgp/mime or some other spec > for instance -- a separate document is may be too much, but who > knows). > also, i noticed the following statement in a past (septemeber 17th > 1998) post by you in the archives: > There are many applications where the envelope itself is sensitive and > needs end-to-end protection. > but i did not notice any concrete examples of such applications. would you > mind mentioning a few? Two words: traffic analysis. Knowing who's getting a message is often enough to tell you something even if the contents are obscured. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id CAA18649 for ietf-openpgp-bks; Tue, 6 Jun 2000 02:34:01 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA18645 for ; Tue, 6 Jun 2000 02:33:59 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 18468 invoked from network); 6 Jun 2000 09:37:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jun 2000 09:37:36 -0000 To: ietf-openpgp@imc.org Subject: Re: 3.6.1.3 Clarification In-Reply-To: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> References: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000606184211H.1001@eccosys.com> Date: Tue, 06 Jun 2000 18:42:11 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: 3.6.1.3 Clarification Date: Tue, 06 Jun 2000 15:52:16 +0800 Message-ID: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> > Just to make sure I understand before we code, two options are available > per instance (I am also not taking into consideration multiple instances > when the hash bit count is smaller than the required key length). Consider > the two options: > > 1) A simple salt + iteration: > > count=20 bytes > salt=12 bytes > pass phrase=12 bytes > > from this, we simply do: > > hash (salt + pass phrase) > > where: > > salt=12 bytes > pass phrase=12 bytes this looks correct to me. it fulfills the "has at least one complete salt + passphrase" requirement. > 2) A concatenated salt + iteration: > > count=40 bytes > salt=12 bytes > pass phrase=12 bytes > > from this, we simply do: > > hash(salt(0) + pp(0) + salt(1) + pp(1)) > > where: > > salt(0)=12 bytes > pass phrase (0)=12 bytes > salt (1)=12 bytes > pass phrase(1)=left 4 bytes of the 12 byte pass phrase this looks correct to me as well. it fulfills the "assuming at least one complete salt + passphrase will be hashed, hash exactly count bytes" requirement. for reference, there was discussion of this area of the rfc recently, and i submitted candidate alternate phrasing for this section. you can find that at: http://www.imc.org/ietf-openpgp/mail-archive/msg03156.html Received: by ns.secondary.com (8.9.3/8.9.3) id AAA13212 for ietf-openpgp-bks; Tue, 6 Jun 2000 00:52:51 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA13208 for ; Tue, 6 Jun 2000 00:52:48 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A25515DB0292; Tue, 06 Jun 2000 15:59:33 0800 Message-Id: <4.3.0.20000606153401.00b9e8e0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Tue, 06 Jun 2000 15:52:16 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 3.6.1.3 Clarification Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Just to make sure I understand before we code, two options are available per instance (I am also not taking into consideration multiple instances when the hash bit count is smaller than the required key length). Consider the two options: 1) A simple salt + iteration: count=20 bytes salt=12 bytes pass phrase=12 bytes from this, we simply do: hash (salt + pass phrase) where: salt=12 bytes pass phrase=12 bytes 2) A concatenated salt + iteration: count=40 bytes salt=12 bytes pass phrase=12 bytes from this, we simply do: hash(salt(0) + pp(0) + salt(1) + pp(1)) where: salt(0)=12 bytes pass phrase (0)=12 bytes salt (1)=12 bytes pass phrase(1)=left 4 bytes of the 12 byte pass phrase Is this correct, or have I got it wrong? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09886 for ietf-openpgp-bks; Mon, 5 Jun 2000 04:33:36 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09882 for ; Mon, 5 Jun 2000 04:33:35 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12yvFU-0001YC-00; Mon, 05 Jun 2000 13:40:52 +0200 To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: <200005312321.QAA13118@finney.org> From: Florian Weimer Date: 05 Jun 2000 13:40:52 +0200 In-Reply-To: hal@finney.org's message of "Wed, 31 May 2000 16:21:12 -0700" Message-ID: Lines: 53 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org writes: > The purpose of Alice's signature was to identify Bob, not to say that > he is trustworthy. I am the one who made that latter determination. > Given that Alice at one time certified Bob's identity, the fact that her > certification has expired doesn't change the fact that I still trust him. If a certification grants access to some resource, access should certainly be denied if the certification expires. (Perhaps this is a bad example, because this is quite easy to enforce during implementation because it only affects the "server" side, not the "client" side, where many OpenPGP implementations might coexist, while there's only one server protecting that specific resource.) A better example: the CA of an organization signs the public key of one of its members, knowing the member will perhaps leave the organization in, say, 6 months. So the CA lets the signature expire in 6 months. (If he's still around at that time, his key will get just another certificate.) According to the CA policy, a key certification implies the statement that the key owner is a member of said organization. If the signature expires and doesn't become invalid automatically, the CA still has to issue a revocation certificate to ensure that it's really invalid on all clients. If the organization has got a considerable member fluctuation, this will result in a quickly growing certificate revocation list (CRL) which mainly contains redundant information (the signatures are expired anyway). > In at least some cases, then, it might be reasonable to continue to use > expired signatures in trust calculation. But the user has to be notified that an expired signature was involved at some point. I don't it's a good idea to hide this fact. On the other hand, the user should be able to verify a signature which was made some time ago, and some links in the chain of trust to the signing key have expired since. (Internally, we call this the "time-travel" feature.) If the user trusts the signer not to issue bogus signatures, this feature is very helpful, even though OpenPGP doesn't provide safe timestamps. I think we can agree that the decision whether expired certificates should be part of validity calculations or not cannot be decided mechanically. Since the message format specification shouldn't assume interactive implementations, we have to make a decision here. My instincts say the safe alternative (i.e. expired certificates are ignored) should be chosen. (And our CRL wouldn't grow as fast as it would without this additional requirement. ;) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00145 for ietf-openpgp-bks; Sun, 4 Jun 2000 22:57:03 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA00139 for ; Sun, 4 Jun 2000 22:57:00 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5AE79C02A4; Mon, 05 Jun 2000 14:03:42 0800 Message-Id: <4.3.0.20000605135243.00b94ee0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 05 Jun 2000 13:57:54 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: Quick Triple-DES Q In-Reply-To: References: <4.3.0.20000605122801.00b96b10@mail.comasp.com> <4.3.0.20000605122801.00b96b10@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 22:06 4/06/00 -0700, Jon Callas wrote: >At 12:30 PM +0800 6/5/00, Erron Criddle wrote: > >To all, > > > >Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for > >use in the OpenPGP standard? > > > >No, they haven't. On the other hand, since they have utterly nothing to do >with Triple-DES, there's no need for them to. Triple-DES is a completely >open algorithm, which is why OpenPGP, as well as many other IETF standards, >use it. Oh, sorry... I remember reading somewhere about RSA providing payment/royalty free access one of their algorithms and I thought it was for OpenPGP... Must have been something else :) As for linking Triple-DES with RSA - well, I certainly don't know where that came from :) Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28468 for ietf-openpgp-bks; Sun, 4 Jun 2000 22:00:08 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA28463 for ; Sun, 4 Jun 2000 22:00:06 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20591 invoked from network); 5 Jun 2000 05:03:42 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 5 Jun 2000 05:03:42 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQ7WIKK0280001I2@mauve.mrochek.com> References: <01JQ50WA0ESA0004AW@mauve.mrochek.com> <20000605115419X.1001@eccosys.com> <01JQ7WIKK0280001I2@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000605140812F.1001@eccosys.com> Date: Mon, 05 Jun 2000 14:08:12 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 47 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT) Message-ID: <01JQ7WIKK0280001I2@mauve.mrochek.com> ... > > does that sound about right? > > Yes, except that the protection extends to the envelope when you use BSMTP. > If all you want to protect is the header it is easier to just use a > message/rfc822 MIME encapsulation. so to protect the confidentiality of the Subject header: sending side 1) create a rfc 822 message (contains Subject) 2) mime encapsulate the message 3) encrypt (and optionally sign) 4) send the message receiving side 5) receive the message 6) decrypt (and optionally verify signature) 7) extract (recreate) the original message 8) read as usual (can see the Subject) right? if there is no better method yet, imo, it would be a good idea for this method of protecting headers to receive some kind of "endorsement" (e.g. mentioned in the openpgp/mime or some other spec for instance -- a separate document is may be too much, but who knows). also, i noticed the following statement in a past (septemeber 17th 1998) post by you in the archives: There are many applications where the envelope itself is sensitive and needs end-to-end protection. but i did not notice any concrete examples of such applications. would you mind mentioning a few? http://www.imc.org/ietf-open-pgp/mail-archive/msg01941.html Received: by ns.secondary.com (8.9.3/8.9.3) id VAA28424 for ietf-openpgp-bks; Sun, 4 Jun 2000 21:58:47 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA28420 for ; Sun, 4 Jun 2000 21:58:45 -0700 (PDT) Received: from [63.73.97.184] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0); Sun, 4 Jun 2000 22:06:47 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.0.20000605122801.00b96b10@mail.comasp.com> References: <4.3.0.20000605122801.00b96b10@mail.comasp.com> Date: Sun, 4 Jun 2000 22:06:45 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Quick Triple-DES Q Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:30 PM +0800 6/5/00, Erron Criddle wrote: >To all, > >Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for >use in the OpenPGP standard? > No, they haven't. On the other hand, since they have utterly nothing to do with Triple-DES, there's no need for them to. Triple-DES is a completely open algorithm, which is why OpenPGP, as well as many other IETF standards, use it. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id VAA28099 for ietf-openpgp-bks; Sun, 4 Jun 2000 21:30:07 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA28094 for ; Sun, 4 Jun 2000 21:30:05 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A14E17E301FC; Mon, 05 Jun 2000 12:36:46 0800 Message-Id: <4.3.0.20000605122801.00b96b10@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 05 Jun 2000 12:30:59 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Quick Triple-DES Q Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, Has RSA allowed a royalty/payment free use of the Triple-DES algorithm for use in the OpenPGP standard? TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id VAA27886 for ietf-openpgp-bks; Sun, 4 Jun 2000 21:05:02 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA27882 for ; Sun, 4 Jun 2000 21:05:00 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQ7WFK047K0001I2@mauve.mrochek.com> for ietf-openpgp@imc.org; Sun, 04 Jun 2000 21:12:45 -0700 (PDT) Date: Sun, 04 Jun 2000 21:11:38 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Mon, 05 Jun 2000 11:54:19 +0900" <20000605115419X.1001@eccosys.com> To: sen_ml@eccosys.com Cc: ietf-openpgp@imc.org Message-id: <01JQ7WIKK0280001I2@mauve.mrochek.com> MIME-version: 1.0 Content-type: Text/Plain; charset=us-ascii References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> <01JQ50WA0ESA0004AW@mauve.mrochek.com> <01JQ50WA0ESA0004AW@mauve.mrochek.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > Please note that since this discussion the BSMTP document has come out as > > RFC 2442. > so, if i understand the idea correctly, header protection can be had > by having mail clients support bsmtp processing: > sending side > 1) create a message > 2) create a bsmtp object out of the message (encapsulate) > 3) encrypt (and optionally sign) > 4) send the message > receiving side > 4) receive the message > 5) decrypt (and optionally verify signature) > 6) extract (recreate) the original message from the bsmtp object > 7) read as usual > does that sound about right? Yes, except that the protection extends to the envelope when you use BSMTP. If all you want to protect is the header it is easier to just use a message/rfc822 MIME encapsulation. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id TAA21156 for ietf-openpgp-bks; Sun, 4 Jun 2000 19:46:16 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA21152 for ; Sun, 4 Jun 2000 19:46:14 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17770 invoked from network); 5 Jun 2000 02:49:48 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 5 Jun 2000 02:49:48 -0000 To: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-Reply-To: <01JQ50WA0ESA0004AW@mauve.mrochek.com> References: <20000602181611R.1001@eccosys.com> <515.959941721@cs.ucl.ac.uk> <01JQ50WA0ESA0004AW@mauve.mrochek.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000605115419X.1001@eccosys.com> Date: Mon, 05 Jun 2000 11:54:19 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: ned.freed@innosoft.com Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? Date: Fri, 02 Jun 2000 19:44:26 -0700 (PDT) Message-ID: <01JQ50WA0ESA0004AW@mauve.mrochek.com> > Please note that since this discussion the BSMTP document has come out as > RFC 2442. so, if i understand the idea correctly, header protection can be had by having mail clients support bsmtp processing: sending side 1) create a message 2) create a bsmtp object out of the message (encapsulate) 3) encrypt (and optionally sign) 4) send the message receiving side 4) receive the message 5) decrypt (and optionally verify signature) 6) extract (recreate) the original message from the bsmtp object 7) read as usual does that sound about right? Received: by ns.secondary.com (8.9.3/8.9.3) id BAA14223 for ietf-openpgp-bks; Sun, 4 Jun 2000 01:34:10 -0700 (PDT) Received: from thetis.deor.org ([207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA14219 for ; Sun, 4 Jun 2000 01:34:06 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id BAA09512; Sun, 4 Jun 2000 01:42:01 -0700 Date: Sun, 4 Jun 2000 01:41:53 -0700 (PDT) From: "L. Sassaman" To: "William H. Geiger III" cc: ietf-openpgp@imc.org Subject: Re: Packet Numbers In-Reply-To: <200006031409.KAA13351@domains.invweb.net> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think this is an excellent idea. However, a few comments: On Sat, 3 Jun 2000, William H. Geiger III wrote: > Hi, > > I would like to propose to the list that we reserve a block of packet > numbers for future use by NAI's PGP & GNUPG. We'll need to propose a method for adding other implementations in the future as well. > This would eliminate problems of either of these vendors grabbing packet > numbers to use for new packets for production level software (PhotoID > packet is a good example). > > I also propose that in exchange for providing these vendors with a block > of packet numbers that they agree to document the packet formats within a > time after using them in production level software (six months sound > good?). 6 months sounds good. The documentation should be a supplimentary RFC. There is no reason to have to rewrite the OpenPGP standard each time. > Any packets that a vendor wishes to keep proprietary should stay in the > +100 range reserved for experimental packets. I would also propose that packet 100 be assigned to X.509 certificates, provided NAI documents this format, and the experimental block be moved to 101 --> 110. I also propose that no implementation should use an experimental packet in a production state (these should be for testing only!) - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5OhZYPYrxsgmsCmoRAiyPAJ4xwGoqwhIH5cGdhCRdWAQLI4EIJwCglrTz k99dQtFPKxtK2WWT0LACZlo= =Il53 -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21694 for ietf-openpgp-bks; Sat, 3 Jun 2000 07:01:12 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21689 for ; Sat, 3 Jun 2000 07:01:10 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id KAA13351 for ; Sat, 3 Jun 2000 10:09:10 -0400 Message-Id: <200006031409.KAA13351@domains.invweb.net> From: "William H. Geiger III" Date: Sat, 03 Jun 2000 08:56:32 -0500 To: ietf-openpgp@imc.org Subject: Packet Numbers X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, I would like to propose to the list that we reserve a block of packet numbers for future use by NAI's PGP & GNUPG. This would eliminate problems of either of these vendors grabbing packet numbers to use for new packets for production level software (PhotoID packet is a good example). I also propose that in exchange for providing these vendors with a block of packet numbers that they agree to document the packet formats within a time after using them in production level software (six months sound good?). Any packets that a vendor wishes to keep proprietary should stay in the +100 range reserved for experimental packets. tks, -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id VAA23170 for ietf-openpgp-bks; Fri, 2 Jun 2000 21:20:20 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA23166 for ; Fri, 2 Jun 2000 21:20:19 -0700 (PDT) Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id VAA16139; Fri, 2 Jun 2000 21:28:16 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.7.0.20000602212423.00c71540@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 Jun 2000 21:28:13 -0700 To: "William H. Geiger III" From: Dave Crocker Subject: Re: patents? Cc: ietf-openpgp@imc.org In-Reply-To: <200006011849.OAA30158@domains.invweb.net> References: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:08 PM 6/1/00 -0500, William H. Geiger III wrote: >In <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net>, on 05/31/00 > at 06:24 PM, Dave Crocker said: > >You are both being far too optimistic. While it is possible that you are > > correct, it is equally possible -- and many would say more likely -- > >that patents are, in fact, held or being prosecuted. > >Well Dave I know several of the people in the PGP group at NAI and I don't >think that they would allow something like this. And, of course, I was not trying to claim that NAI has any plans or would take such action. For that matter the entire history of PGP leads to the expectation that no such patent action would be taken. However the question was about possibilities and implications, particularly with respect to the import of being late in the standards process. That is, the important piece of information is that there is nothing that *forces* NAI (or any other participant) to disclose patent intent, and there is already some precedent (small pseudo-legal pun intended) for late-stage surfacing. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA Received: by ns.secondary.com (8.9.3/8.9.3) id TAA15018 for ietf-openpgp-bks; Fri, 2 Jun 2000 19:38:23 -0700 (PDT) Received: from mauve.mrochek.com (DSL107-055.brandx.net [209.55.107.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA15011 for ; Fri, 2 Jun 2000 19:38:22 -0700 (PDT) From: ned.freed@innosoft.com Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01JQ4YP668LC0004AW@mauve.mrochek.com> for ietf-openpgp@imc.org; Fri, 02 Jun 2000 19:45:58 -0700 (PDT) Date: Fri, 02 Jun 2000 19:44:26 -0700 (PDT) Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: "Your message dated Fri, 02 Jun 2000 11:28:41 +0100" <515.959941721@cs.ucl.ac.uk> To: Ian BROWN Cc: sen_ml@eccosys.com, ietf-openpgp@imc.org Message-id: <01JQ50WA0ESA0004AW@mauve.mrochek.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii References: <20000602181611R.1001@eccosys.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > This is a really important thing we need to sort out. There was extensive > discussion of it almost two years ago (!) but I don't know if that resulted in > anything in the PGP/MIME draft. > Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last > e-mail on the subject, but you can read the discussion in the archives at > www.imc.org Please note that since this discussion the BSMTP document has come out as RFC 2442. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id DAA07415 for ietf-openpgp-bks; Fri, 2 Jun 2000 03:29:25 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA07410 for ; Fri, 2 Jun 2000 03:29:23 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 4474 invoked from network); 2 Jun 2000 10:32:53 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 2 Jun 2000 10:32:53 -0000 To: ietf-openpgp@imc.org Subject: Re: easy to understand openpgp book/doc? In-Reply-To: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> References: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000602193715H.1001@eccosys.com> Date: Fri, 02 Jun 2000 19:37:15 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 13 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: easy to understand openpgp book/doc? Date: Fri, 02 Jun 2000 17:40:34 +0800 Message-ID: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> > I was wondering if there is a book/document available that basically > translates the 2440/2440bis documents into an understandable format. that would be nice to have :-) assuming there isn't one, i'd be interested in participating in creating something along those lines. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA07003 for ietf-openpgp-bks; Fri, 2 Jun 2000 03:21:03 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA06998 for ; Fri, 2 Jun 2000 03:21:01 -0700 (PDT) Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Jun 2000 11:28:43 +0100 X-Mailer: exmh version 2.0.2 To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: confidential subject lines -> use content description field w/ pgp/mime? In-reply-to: Your message of "Fri, 02 Jun 2000 18:16:11 +0900." <20000602181611R.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 02 Jun 2000 11:28:41 +0100 Message-ID: <515.959941721@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a really important thing we need to sort out. There was extensive discussion of it almost two years ago (!) but I don't know if that resulted in anything in the PGP/MIME draft. Ned Freed's suggestion seemed to be widely agreed upon: I've attached his last e-mail on the subject, but you can read the discussion in the archives at www.imc.org Ian :) -- Date: Thu, 17 Sep 1998 11:04:15 -0700 (PDT) From: Ned Freed Subject: Re: Encrypting RFC822 headers in S/MIME or PGP/MIME messages To: Ian Bell Cc: ietf-open-pgp@imc.org, ietf-smime@imc.org > (Apologies if this has been done to death in the past - I can imagine > Ned sighing about protracted discussions prior to RFC1847 - but I > couldn't find any discussion in the archives) > RFC2311 (SMIME) and RFC1847 (upon which PGP/MIME has been based) only > allow MIME headers to be protected by the encryption process. Was there > any discussion during the preparation of RFC1847 about the possibility / > desirability / feasibility of allowing general RFC822 headers to be > included in the encrypted part of the message? There were extensive discussions of this. I probably have several hundred messages archived on this topic, and there were also WG discussions and several private meetings where the design team covered this area exhaustively. The basic conclusion was (and is) that this dog doesn't hunt and cannot be made to hunt. The problem is that message headers are routinely rewritten by intervening MTAs as messages are transferred via SMTP. They are refolded, reordered, addresses are converted from one form to another, encoded words are added or removed, entire fields are added or deleted. And all these activities are the rule, not the exception. And it is far more likely to happen to fields it makes sense to sign, such as subject, to/cc/bcc, comments, etc. than to any others. In short, if you want to keep the transports from modifying things, you cannot put them in the primary header. You either have to put them in the body. And given this, MIME provides the obvious means to do this if that's what you're after -- nested messages. > The most obvious candidates for headers to be encrypted along with the > MIME headers would be Subject: and Disposition-Notification-To: (the > subject the sender may have intended to use may be too sensitive to use > as the subject of the open message: the sender may want any MDN to be > sent only when the message is decrypted), though cases could probably be > made for just about any RFC822 header. > Could (and should) any replacements for RFC2015 and RFC2311 be amended > to allow RFC822 headers to be sent encrypted, and for the decryption > process to swap any encrypted headers found with the corresponding > headers in the actual message? There is no need to do this. All you need to do is use MIME encapsulation to put the real headers into the body of the message. One thing that would be nice is if there was a way to say in the signature information that the inner message is actually supposed to replace the outer container message. (This could also be done as a parameter to message/rfc822 if need be, although there are arguments for doing it in the signature. There is one other thing that is missing, however, and that is a means of encapsulating the entire message including the envelope. There are many applications where the envelope itself is sensitive and needs end-to-end protection. And there is a proposal on the table to deal with this: draft-freed-bsmtp-02.txt. This defines envelope encapsulation and the semantics that necessarily follow from doing it. > As availability of encryption software becomes more widespread, many > end-users may find SMIME/PGP most useful as simply a transport security > mechanism rather than a way of securely storing messages. In any case, > MUAs implementing PGP or S/MIME probably already allow the user to save > the decrypted version of a message. Sure. > It would be good if there were an interoperable way of making the > stored, decrypted message reflect the message the author would have > liked to send in the first place. It would be particularly nice if the > author could transmit the intended subject of a message when this may be > too sensitive to put in the open message headers. See above. Ned Received: by ns.secondary.com (8.9.3/8.9.3) id CAA01643 for ietf-openpgp-bks; Fri, 2 Jun 2000 02:39:50 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA01635 for ; Fri, 2 Jun 2000 02:39:48 -0700 (PDT) Received: from proxy.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A554E1F01C8; Fri, 02 Jun 2000 17:46:12 0800 Message-Id: <4.3.0.20000602173502.00ba5d70@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Fri, 02 Jun 2000 17:40:34 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: easy to understand openpgp book/doc? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, I was wondering if there is a book/document available that basically translates the 2440/2440bis documents into an understandable format. PS: I have an electronic engineering background and extensive experience with Internet protocols, so please, no derogatory remarks :) TIA. Regards Erron Criddle Comasp Ltd. ACN: 089 468 682 Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: +61 8 9386 9534 Mob: +414/0414 800 888 ejc@comasp.com http://www.comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00667 for ietf-openpgp-bks; Fri, 2 Jun 2000 02:08:26 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA00663 for ; Fri, 2 Jun 2000 02:08:24 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 3097 invoked from network); 2 Jun 2000 09:11:50 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 2 Jun 2000 09:11:50 -0000 To: ietf-openpgp@imc.org Subject: confidential subject lines -> use content description field w/ pgp/mime? X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000602181611R.1001@eccosys.com> Date: Fri, 02 Jun 2000 18:16:11 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 71 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: problem ------- imo, as the number of messages using pgp (or pgp/mime) for a user increases, the need for a mechanism for protecting the confidentiality of subject lines (i.e. what a user sees as a subject in a mail client) becomes greater. important information is often stored in the subject line and not having a meaningful subject which was specified by the author of the message can be a serious inconvenience to users (e.g. searching, referring to past messages in communication, etc.) -- which may likely lead to a decision on the user's part to go ahead and place sensitive information in the subject line. suggestion ---------- i think it would be a good idea to address this by defining a common specification. afaik, there isn't one yet -- please tell me if you know of one already. i've asked around on a few mailing lists for ideas about this, and, imho, the most promising one i heard was to give meaning to the Content-Description field for a particular mime part. the basic idea is to store the information which would normally be the value of a Subject header as the value of a Content-Description header which is placed in a "to-be-encrypted" text message part. Example: From: Michael Elkins To: Michael Elkins Subject: encrypted in CD: 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 & Content-Type: text/plain & Content-Description: this is the subject the user will see & & here is some message text & & :-) --foo-- where, as in the (open)pgp/mime specification, the ampersands indicate which portion of the text is encrypted. upon/after decryption, mail clients would make an effort to display the contents of the aforementioned Content-Description field in relevant user interface portions (e.g. title of a message window, where subject text might be displayed in a view that listed information about a collection of message [one message per line], etc.). mail clients might also make use of these Content-Description values for the purposes of searching and filtering. how does the basic idea sound? p.s. this idea was originally suggested by Kazu Yamamoto . Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05879 for ietf-openpgp-bks; Thu, 1 Jun 2000 11:42:04 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05873 for ; Thu, 1 Jun 2000 11:42:02 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id OAA30158; Thu, 1 Jun 2000 14:49:46 -0400 Message-Id: <200006011849.OAA30158@domains.invweb.net> From: "William H. Geiger III" Date: Thu, 01 Jun 2000 13:08:35 -0500 To: Dave Crocker In-Reply-To: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> Cc: ietf-openpgp@imc.org Subject: Re: patents? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net>, on 05/31/00 at 06:24 PM, Dave Crocker said: >At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote: >>Being as no evil lawyers from NAI or elsewhere have swooped down on this >>list or on the IETF I'd say it's safe for now. >> >>At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >>>Probably just standard boilerplate. They are just putting you on notice >>>that by publishing their source code they are not giving up any rights >>>that the may hold on the code. >You are both being far too optimistic. While it is possible that you are > correct, it is equally possible -- and many would say more likely -- >that patents are, in fact, held or being prosecuted. >The IETF has had some patents emerge very late in the process, so the >concern is not academic. Well Dave I know several of the people in the PGP group at NAI and I don't think that they would allow something like this. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html ---------------------------------------------------------------