From owner-ietf-openpgp@mail.imc.org Fri Jan 4 18:31:21 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16060 for ; Fri, 4 Jan 2002 18:31:21 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04N2Fv23768 for ietf-openpgp-bks; Fri, 4 Jan 2002 15:02:15 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04N2D323764 for ; Fri, 4 Jan 2002 15:02:14 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 4 Jan 2002 15:01:59 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20011227193337.F685@akamai.com> References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> <20011227193337.F685@akamai.com> Date: Fri, 4 Jan 2002 14:58:47 -0800 To: David Shaw , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Text canonicalization Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:33 PM -0500 12/27/01, David Shaw wrote: >This sounds very good, but what about detached signatures? A detached >signature doesn't carry the text with it, so wouldn't the the text >(presumably delivered via http or ftp, which can change line endings) >need to be re-canonicalized for signature verification? To a certain >degree this applies to a clearsigned document as well. > The point of what I'm suggesting is that generating or verifying a signature is always (or almost always) just hashing the data and going on with it, no matter what the mode. Text mode comes in when the processing program can guarantee that the signed data is in canonicalized text. So most detached sigs must be in binary mode, unless the implementation wants to transform the text, or otherwise knows that it's in that format. That's what I mean by it being an assurance. The cryptography is always the same. Text mode means that if you use a well-defined transform from canonical form, it will be in the right character set etc. >Email delivery of the text is a whole other can of worms, though it >could be argued that if it's email, it should be PGP/MIME. I suppose that can be argued, but I argue otherwise. I and many other people delete PGP/MIME without reading, but that's another discussion. (I've actually been planning such a rant, and was composing it in my head. Thanks for the opening.) With regard to text vs. binary, the rule I'm saying is that when you create a signature, and when you verify it, you process the actual bits in a data packet, no matter where that data packet is. The crypto sections of an OpenPGP system ignore the mode. The interesting problem comes, as I understand it, comes from this scenario: Alice puts on an FTP server a text file, foo.txt, and a detached signature, foo.sig. Bob FTPs both files, foo.txt in text mode, and foo.sig in binary mode, and the line ends get changed as part of FTPing the file. Consequently, the signature doesn't verify. I can think of several answers to this scenario: (1) Don't do that, you'll hurt yourself. Come on, digital signatures are fragile and brittle. Text mode operations, be they OpenPGP's, FTP's, or anyone else's, alter text, and that's going to cause problems. (a) Alice puts the file on her system in some well-known format that the right thing will be done with. Examples of this include ZIP files, .tar.gz, .gz, .Z, .sit, etc. The signature is over the container. Bob FTPs them both in binary mode, verifies the signature and unpacks foo.txt. (b) Bob FTPs both files in binary mode and verifies the signature. Then he translates foo.txt, or re-FTPs it in text mode. (c) Bob's OpenPGP program could tell him that the file seems not to be in "canonical text" and that this may be the reason why it didn't verify. This is arguably something of a copout, as it can be irritating to have a program tell you something didn't work, and here's why. I know I always mutter to the system, "You're the computer, if it's that easy, fix it." (2) Bob's OpenPGP program has a heuristic to try to compensate for a text translation. Note that I said try. There are many, many ways this can fail. But there are many ways it can work correctly. If an OpenPGP program (or a wrapper around one -- this is a perfect place to use a perl script) tries the straightforward thing of converting line ends to CRLF, it will probably work just fine. If it tries the next simple attempt -- assume that the text is in ISO Latin-1, and convert it to UTF-8, it will probably get most of the rest. Certainly most mail things will work right with these. (3) Put the text file in an OpenPGP clearsigned message. I suppose this really ought to be (1)(d), as it's another "don't do that" solution. But it works. If the problem is that you have a file that you want to be both directly readable as text and signed, clearsigning is a way to go. I realize that this brings the implementer into a subset of the text heuristic because line ends might flipped around. But it *should* already be put into canonical UTF-8, and thus the problem of figuring out how to verify it is much easier. Jon From owner-ietf-openpgp@mail.imc.org Sat Jan 5 14:23:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06677 for ; Sat, 5 Jan 2002 14:23:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g05J2mE12097 for ietf-openpgp-bks; Sat, 5 Jan 2002 11:02:48 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g05J2l312093 for ; Sat, 5 Jan 2002 11:02:47 -0800 (PST) Received: from softhome.net ([209.6.136.56]) (AUTH: PLAIN jkane89@softhome.net) by softhome.net with esmtp; Sat, 05 Jan 2002 11:47:30 -0700 Message-ID: <3C374B93.A3EBCF85@softhome.net> Date: Sat, 05 Jan 2002 13:53:09 -0500 From: John Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF-OpenPGP CC: jwn2@qualcomm.com Subject: new patent app conflicts with pgp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Someone has applied for a US patent on the technique of using a symmetric session key on a document, and then using multiple public keys to encrypt the session key to multiple recipients. Newton Hammet newton(at)hammet.net brought this to our attention. http://appft1.uspto.gov/netahtml/PTO/srchnum.html (search for 20010055396) http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html He cites RSA as prior art, but not RFC1991/RFC2440. This seems to be in the context of a business model where a server allows secure access to a symmetrically-encrypted document by allowing the author to upload multiple public-key headers for multiple recipients, and to repost both amended PKI access lists and amended updates of the document (potentially re-using the orig.sess key). However: [0024] As another example, encrypted decryption keys could be bundled into the message and the single message with the encrypted decryption keys could be broadcast to all recipients without compromising the security of the mechanism. -- John Kane Stratham, NH (USA) From owner-ietf-openpgp@mail.imc.org Sun Jan 6 11:32:41 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24474 for ; Sun, 6 Jan 2002 11:32:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g06G1OO29094 for ietf-openpgp-bks; Sun, 6 Jan 2002 08:01:24 -0800 (PST) Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g06G1N329090 for ; Sun, 6 Jan 2002 08:01:23 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g06G0r309529 for ietf-openpgp@imc.org; Sun, 6 Jan 2002 11:00:53 -0500 Date: Sun, 6 Jan 2002 11:00:53 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Text canonicalization Message-ID: <20020106110053.A9308@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> <20011227193337.F685@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vedaal@hotmail.com on Fri, Dec 28, 2001 at 08:15:07AM -0500 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Crescent (45% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Dec 28, 2001 at 08:15:07AM -0500, vedaal wrote: > > This sounds very good, but what about detached signatures? A detached > > signature doesn't carry the text with it, so wouldn't the the text > > (presumably delivered via http or ftp, which can change line endings) > > need to be re-canonicalized for signature verification? To a certain > > degree this applies to a clearsigned document as well. > ... > also applies somewhat to GnuPG signed and encrypted messages when signed > with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key, > PGP interprets it as a 'detached' signature, > and 'searches' (unsuccessfully) for the file trying to verify it. > {not the case with v4 rsa sigs, which seem to act differently} This is a slightly different problem - GnuPG would never make a non-clear or non-detached signature with v3 keys that PGP 6 or 7 liked. I fixed this a few days ago, and it works properly now. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Mon Jan 7 12:05:04 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20761 for ; Mon, 7 Jan 2002 12:05:04 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g07Ge6J28699 for ietf-openpgp-bks; Mon, 7 Jan 2002 08:40:06 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Ge5328695 for ; Mon, 7 Jan 2002 08:40:05 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA18046; Mon, 7 Jan 2002 11:45:10 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018031; Mon, 7 Jan 02 11:44:45 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07GdUl29792 for ietf-openpgp@imc.org; Mon, 7 Jan 2002 11:39:30 -0500 (EST) Date: Mon, 7 Jan 2002 11:39:30 -0500 (EST) Message-Id: <200201071639.g07GdUl29792@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-openpgp@imc.org Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. From owner-ietf-openpgp@mail.imc.org Mon Jan 7 16:52:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29001 for ; Mon, 7 Jan 2002 16:52:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07LNDr06636 for ietf-openpgp-bks; Mon, 7 Jan 2002 13:23:13 -0800 (PST) Received: from wanda.ch (adsl-73-116-basel1.tiscalinet.ch [212.254.73.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07LNB306632 for ; Mon, 7 Jan 2002 13:23:11 -0800 (PST) Received: from wanda.ch (wanda.ch [212.254.73.116]) by wanda.ch (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g07LMqx06514; Mon, 7 Jan 2002 22:22:52 +0100 Message-ID: <3C3A11AB.4050501@wanda.ch> Date: Mon, 07 Jan 2002 22:22:51 +0100 From: Marcel Waldvogel Organization: WandA -- The Waldvogel and Aschwanden Family User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: de, en-us MIME-Version: 1.0 To: John Kane CC: IETF-OpenPGP , jwn2@qualcomm.com Subject: Re: new patent app conflicts with pgp References: <3C374B93.A3EBCF85@softhome.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John, It seems to me that PGP is clear prior art in itself to the relevant claims, so I don't think we should need to worry. -Marcel John Kane wrote: >Someone has applied for a US patent on the technique of >using a symmetric session key on a document, and then using >multiple public keys to encrypt the session key to multiple >recipients. Newton Hammet newton(at)hammet.net brought >this to our attention. > > http://appft1.uspto.gov/netahtml/PTO/srchnum.html > (search for 20010055396) >http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html >http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html > >He cites RSA as prior art, but not RFC1991/RFC2440. >This seems to be in the context of a business model where >a server allows secure access to a symmetrically-encrypted >document by allowing the author to upload multiple >public-key headers for multiple recipients, and to repost >both amended PKI access lists and amended updates of >the document (potentially re-using the orig.sess key). > >However: > [0024] As another example, encrypted decryption keys could > be bundled into the message and the single message with the > encrypted decryption keys could be broadcast to all recipients > without compromising the security of the mechanism. > >-- >John Kane >Stratham, NH (USA) > > > > From owner-ietf-openpgp@mail.imc.org Mon Jan 7 18:18:37 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00633 for ; Mon, 7 Jan 2002 18:18:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g07MuZk09052 for ietf-openpgp-bks; Mon, 7 Jan 2002 14:56:35 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07MuY309048 for ; Mon, 7 Jan 2002 14:56:34 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g07MuTV08102 for ietf-openpgp@imc.org; Mon, 7 Jan 2002 17:56:29 -0500 Date: Mon, 7 Jan 2002 17:56:29 -0500 From: David Shaw To: IETF-OpenPGP Subject: Re: new patent app conflicts with pgp Message-ID: <20020107175629.D2997@akamai.com> Mail-Followup-To: IETF-OpenPGP References: <3C374B93.A3EBCF85@softhome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C374B93.A3EBCF85@softhome.net>; from jkane89@softhome.net on Sat, Jan 05, 2002 at 01:53:09PM -0500 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Crescent (32% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 05, 2002 at 01:53:09PM -0500, John Kane wrote: > > Someone has applied for a US patent on the technique of > using a symmetric session key on a document, and then using > multiple public keys to encrypt the session key to multiple > recipients. Newton Hammet newton(at)hammet.net brought > this to our attention. > > http://appft1.uspto.gov/netahtml/PTO/srchnum.html > (search for 20010055396) > http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html > http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html > > He cites RSA as prior art, but not RFC1991/RFC2440. I've not read the patent, but if there really is a prior art conflict with PGP: http://www.uspto.gov/web/menu/helpfaq.htm#a50 #50 How does one file protest on patents that are pending? Protests by a member of the public against pending applications will be referred to the examiner having charge of the subject matter involved. A protest specifically identifying the application to which the protest is directed will be entered in the application file if: (1) The protest is submitted prior to the publication of the application or the mailing of a notice of allowance under rule 1.311, whichever occurs first; and (2) The protest is either served upon the applicant in accordance with rule 1.248, or filed with the Office in duplicate in the event service is not possible. For more detailed information on protesting a patent, you may visit our Web site at http://www.uspto.gov/web/offices/pac/mpep/mpep.htm for the Manual of Patent Examining Procedure (MPEP) Chapter 1900. The specific document referred to is at http://www.uspto.gov/web/offices/pac/mpep/mpep_e8_1900.pdf David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From subs-reminder@imc.org Mon Jan 7 19:49:26 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01950 for ; Mon, 7 Jan 2002 19:49:25 -0500 (EST) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g080nN926908; Mon, 7 Jan 2002 16:49:23 -0800 (PST) Date: Mon, 7 Jan 2002 16:49:23 -0800 (PST) Message-Id: <200201080049.g080nN926908@above.proper.com> To: openpgp-archive@ietf.org Subject: [[759368132]] Subscription to ietf-openpgp for openpgp-archive@lists.ietf.org Greetings. This message is a periodic reminder that openpgp-archive@lists.ietf.org is subscribed to the ietf-openpgp mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openpgp mailing list, you do not need to do anything. On the other hand, if you want to unsubscribe from this list, go to the following link: You can also unsubscribe by email. To do so, you can respond to this message and I will unsubscribe you by hand in the next few days. Alternatively, you can send a plain-text message to: ietf-openpgp-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "openpgp-archive@lists.ietf.org". If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openpgp@mail.imc.org Tue Jan 8 09:32:07 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23202 for ; Tue, 8 Jan 2002 09:32:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08E2o702030 for ietf-openpgp-bks; Tue, 8 Jan 2002 06:02:50 -0800 (PST) Received: from hotmail.com (oe41.law3.hotmail.com [209.185.240.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08E2n302026 for ; Tue, 8 Jan 2002 06:02:49 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Jan 2002 06:02:42 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: Re: new patent app conflicts with pgp Date: Tue, 8 Jan 2002 09:00:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 08 Jan 2002 14:02:42.0185 (UTC) FILETIME=[23B1E790:01C1984D] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Sat, Jan 05, 2002 at 01:53:09PM -0500, John Kane wrote: > > Someone has applied for a US patent on the technique of > using a symmetric session key on a document, and then using > multiple public keys to encrypt the session key to multiple > recipients I forwarded the message with the url to a patent attorney who also happens to be an avid pgp/gpg user, and on several of the pgp mailing lists, {but not this one}, and am listing his response below: Vedaal, please forward this message to the IETF list and anywhere else you think appropriate. Below are some facts to ponder. As a patent agent registered to practice before the U.S. Patent Office, I do advise clients about patentability of their inventions. Indeed, if a client came to me with this pending application, I would be in a position to counsel him or her as to whether I thought it wise to pursue it. However, I do not provide such advice to anyone but a client in a professional relationship (see disclaimer), so the legal conclusions of these facts are left to the reader or his or her legal counsel. Also, please note that the scope of my practice does *not* extend to analyzing the effect of issued patents, as that is a matter before the courts and not the Patent Office. Now on to the facts... [A] The independent claims of the Jevans application, as published, are copied below. All other published claims are dependent on one of these two, and are thus no broader in scope than these two. I've broken claim 1 into sections for easier reading. 1. A method for transmitting a message, comprising the steps of - - encrypting said message to develop an encrypted message, - - said encrypted message being decryptable using a first decryption key; - - encrypting said first decryption key with encryption keys of a plurality of target recipients, to develop a plurality of encrypted decryption keys; and - - transmitting said encrypted message and said encrypted decryption keys to said target recipients. 22. Apparatus including at least one computer readable storage medium, said apparatus carrying data comprising: an encrypted message, said encrypted message being decryptable using a first decryption key; and a plurality of encrypted decryption keys stored in conjunction with said encrypted message, each of said encrypted decryption keys including said first decryption key encrypted with an encryption key of a respective target recipient of said message. [B] The application claims priority of a provisional application filed Feb. 24, 2000. Assuming that provisional application fully supports the pending claims (and that shouldn't be taken for granted), any patent or "printed publication" that (1) was available to the interested public more than one year before the provisional's filing date, i.e., before Fed. 24, 1999, and (2) "discloses, either expressly or inherently, all of the limitations [i.e., elements] of the claim[s]" would anticipate the claims and render them unpatentable. Note that the definition of "printed publication" likely includes RFCs, which are easily found on any search engine and are publicly available (i.e., "Distribution of this memo is unlimited"). Even if a reference does not discloses all limitations of a claim, a claim can be rejected as obvious over a reference or combination of references, coupled with a clear suggestion in the art (prior published literature, patents, etc.) that the reference(s) can or should be combined or modified to arrive at the claimed invention. [C] According to a web page I located, RFC1991 was published August 1996 and includes the following text: >"A pgp file consists of three components: a message component, a signature >(optional), and a session key component (optional)." [5.2] . . . >"The session key component includes the encrypted session key and the >identifier of the recipients public key used by the sender to encrypt the >session key. The session key component consists of a single >public-key-encrypted packet for each recipient of the message." [5.2.3] [D] According to another web page I located, RFC2440 was published November 1998 and includes the following text: > A Public-Key Encrypted Session Key packet holds the session key used > to encrypt a message. Zero or more Encrypted Session Key packets > (either Public-Key or Symmetric-Key) may precede a Symmetrically > Encrypted Data Packet, which holds an encrypted message. The message > is encrypted with the session key, and the session key is itself > encrypted and stored in the Encrypted Session Key packet(s). The > Symmetrically Encrypted Data Packet is preceded by one Public-Key > Encrypted Session Key packet for each OpenPGP key to which the > message is encrypted. The recipient of the message finds a session > key that is encrypted to their public key, decrypts the session key, > and then uses the session key to decrypt the message. . . . > Note that when an implementation forms several PKESKs with one > session key, forming a message that can be decrypted by several keys, > the implementation MUST make new PKCS-1 padding for each key. > > An implementation MAY accept or use a Key ID of zero as a "wild card" > or "speculative" Key ID. In this case, the receiving implementation > would try all available private keys, checking for a valid decrypted > session key. This format helps reduce traffic analysis of messages. > [5.1] [E] During pendency of their applications, a patent applicant and his or her representatives are legally bound to disclose to the Patent Examiner any materials they consider "material to patentability" of the application. This includes materials sent to them from third parties after they have filed (and published) the application. Sometimes the submitted materials are devastating, and the application goes abandoned. Other times submitting the materials actually winds up helping strengthen the eventual patent because the Examiner considered the worst "prior art" and still allowed the claims to issue -- there's a presumption that the Examiner did his or her job correctly. So don't try this at home, at least not without specific professional advice. I hope this info provides some illumination for your continued discussions. I don't subscribe to the list, so feel free to CC: me if you wish. Ed Suominen Registered Patent Agent (http://eepatents.com) Independent Inventor of Electrical Engineering Technology U.S. Patents 5,926,513; 5,937,341*; 6,052,748*; 6,069,913; additional patents pending* (*Available for licensing) < Nothing in this message is to be construed as legal advice or the opinion of my firm or any client. > -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: { Acts of Kindness better the World, and protect the Soul } Comment: KeyID: 0x6A05A0B785306D25 Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA iQEVAwUBPDr7QmoFoLeFMG0lAQPQ8gf+Ikdie+OpuAkwAzPKD6xHTQxK0v680GFm 2ZEGYpQ7tEveS7ntCdR74IBtiJj9rwTV0vx/Eu6YGOEe7oKCHxWrx8bxLG+O5YUj chTFOFL1YWdGxYdKzSidUGQl6YkKc+DP2Abh4cMGRUNI7V1NxzvjRB3T8QH/TitL ld2xoLfhvv3iLoKN3lJkHWBxQ0o+fJFroSDTDjvdYrXlNo6tygQ6Sf+qNZh4Whtw qZ/ZVMkPIxRkbGu2kCPZ2rtVRoP+pr74LHA5n50qW2NEtDB2+y80Lgedu8wq4OvS UQV/kWOWzCn80RRKKECr6GUGk371BG51iKA6H5q8R3KlW4KwLSMS7A== =6ahh -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jan 8 13:12:15 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03108 for ; Tue, 8 Jan 2002 13:12:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08Hfdd10975 for ietf-openpgp-bks; Tue, 8 Jan 2002 09:41:39 -0800 (PST) Received: from smtp.tiscali.de (mx0.12move.de [62.26.124.140]) by above.proper.com (8.11.6/8.11.3) with SMTP id g08Hfb310970 for ; Tue, 8 Jan 2002 09:41:37 -0800 (PST) Received: (qmail 65541 invoked from network); 8 Jan 2002 17:41:32 -0000 Received: from unknown (HELO sobolev.does-not-exist.org) (62.27.238.11) by smtp0.tiscali.de with SMTP; 8 Jan 2002 17:41:32 -0000 Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 6AEEA2ED15; Tue, 8 Jan 2002 16:58:19 +0100 (CET) Date: Tue, 8 Jan 2002 16:58:19 +0100 From: Thomas Roessler To: vedaal Cc: ietf-openpgp@imc.org Subject: Re: new patent app conflicts with pgp Message-ID: <20020108155819.GE24528@sobolev.does-not-exist.org> Mail-Followup-To: vedaal , ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Face: Oxq^+Q$NuUQ-&J#F14uCyP4}v%$5{ZGnS}PX;zoxOQ%*`#dkJ'qx$w}\Z;m.e*,_K0V8mii$qU(|l Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-01-08 09:00:42 -0500, vedaal wrote: >[C] According to a web page I located, RFC1991 was published August 1996 >and includes the following text: See also Schneier, Applied Cryptography 2nd ed, p. 51, for a slightly more abstract description. This is from 1996, too. -- Thomas Roessler http://log.does-not-exist.org/ From owner-ietf-openpgp@mail.imc.org Tue Jan 8 22:44:11 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19306 for ; Tue, 8 Jan 2002 22:44:10 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g093Kw200174 for ietf-openpgp-bks; Tue, 8 Jan 2002 19:20:58 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g093Km300167 for ; Tue, 8 Jan 2002 19:20:56 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA24899; Wed, 9 Jan 2002 16:20:33 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA146637; Wed, 9 Jan 2002 16:20:32 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 9 Jan 2002 16:20:32 +1300 (NZDT) Message-ID: <200201090320.QAA146637@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: roessler@does-not-exist.org, vedaal@hotmail.com Subject: Re: new patent app conflicts with pgp Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >On 2002-01-08 09:00:42 -0500, vedaal wrote: >>[C] According to a web page I located, RFC1991 was published August 1996 >>and includes the following text: > >See also Schneier, Applied Cryptography 2nd ed, p. 51, for a slightly more >abstract description. This is from 1996, too. If you really want go go back to old stuff, there's the PEM RFCs starting in 1987, OSI (who?) work from the mid 1980's, and assorted conference papers and research work on secure mail from the same time frame. Peter. From owner-ietf-openpgp@mail.imc.org Thu Jan 17 02:10:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09452 for ; Thu, 17 Jan 2002 02:10:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0H6qr001074 for ietf-openpgp-bks; Wed, 16 Jan 2002 22:52:53 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc233.dialup.uoi.gr [195.130.119.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0H6qh301064 for ; Wed, 16 Jan 2002 22:52:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16R6OS-0000TF-00 for ; Thu, 17 Jan 2002 08:51:24 +0200 Date: Thu, 17 Jan 2002 08:51:14 +0200 From: Nikos Mavroyanopoulos To: ietf-openpgp@imc.org Subject: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020117085114.3854af79.nmav@hellug.gr> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello, Some days ago I posted to ietf-tls WG mailing list, a modification of the draft-ietf-tls-openpgp-01. Since this is about openpgp, I decided to post it here too. The original post: I wanted to use openpgp certificates with TLS, but draft-ietf-tls-openpgp-01 is expired, and had some properties that I did not like. Here I modified the tls-openpgp draft in a way that: * no new cipher suites need to be defined, in order to use openpgp keys * does not use keyIDs but key fingerprints I'd appreciate any comments on this. 2. Certificates The X.509v3 [X509] certificates recommended for use with TLS will not be used in conjunction with OpenPGP keys. An implementation SHOULD be able to support both TLS with X509 and TLS with OpenPGP keys. It is NOT REQUIRED that an implementation support both. The "peer certificate" in the session state of TLS MAY refer to either X509 or OpenPGP. 3. Changes to the Handshake Message Contents This section describes the changes to the TLS handshake message contents when OpenPGP keys are to be used for authentication. 3.1 Hello Messages 3.1.1 Extension Type A new value, "cert_type(7)", has been added to the enumerated ExtensionType, defined in [TLSEXT]. This value is used as the extension number for the extensions in both the client hello message and the server hello message. This value was chosen based on the version of defined in [TLSEXT] that was current at the time of writing, so may be changed in future. 3.1.2 The Client Hello Message An extension of type CertificateTypeExtension is appended to the standard client hello message using the client hello extension mechanism defined in [TLSEXT]. This extension carries a list of supported Certificate types the client can use. This extension SHOULD NOT be used if the client supports only X.509 Certificates. enum { client, server } ClientOrServerExtension; enum { X.509(0), OpenPGP(1), (255) } CertificateType; struct { select(ClientOrServerExtension) { case client: CertificateType certificate_type<1..2^8-1>; case server: CertificateType certificate_type; } } CertificateTypeExtension; 3.1.3 Server Hello The certificate type selected by the server (certificate_type), is appended to the server hello message using the hello extension mechanism defined in [TLSEXT]. The certificate type selected by the server (certificate_type), is encoded in an CertificateTypeExtension structure, which is sent in an extended server hello message, using an extension of type "cert_type". The CertificateTypeExtension structure may be omited if the server only supports X.509 certificates. 3.2 Server certificate The contents of the certificate message sent from server to client and vice versa are determined by the negotiated certificate type and the cipher suite. In case OpenPGP certificate type is negotiated then it is required to present an OpenPGP key in the Certificate message. A OpenPGP key appearing in the Certificate message will be sent in binary OpenPGP format. The Certificate message includes an OpenPGP key where the X.509 certificate would normally appear. The option is also available to send an OpenPGP fingerprint, instead of sending the entire key. The generation of fingerprints is defined in [OpenPGP]. The client will respond with a fatal alert unsupported_certificate if the key with the given fingerprint cannot be found. If the key is not valid, expired, revoked, corrupt, the appropriate fatal alert message is sent from section A.3 of the TLS specification. If a key is valid and neither expired nor revoked, it is accepted by the protocol. A particular OpenPGP compatible TLS implementation MAY wish to allow users to designate certain keys specifically as Trusted Server Keys. This is a local matter outside the scope of this document. enum { key (0), key_fingerprint (1), (255) } PGPKeyDescriptorType; opaque PGPFingerprint<20>; opaque PGPKey<1..2^24-1> struct { PGPKeyDescriptorType descriptorType; select (descriptorType) { case key_fingerprint: PGPFingerprint; case key: PGPKey; } } Certificate; 3.3 Certificate Request The server is allowed to request a client certificate from the client. The meaning of this message is essentially unchanged to allow OpenPGP keys. The rsa_sign and dss_sign certificate types may be requested in conjunction with OpenPGP keys. The ClientCertificateType field is used identically to the TLS specification. The subsequent DistinguishedName field is NOT included when using OpenPGP keys. The Client Certificate message is sent using the same formatting as the server Certificate message in response to the Certificate Request message. If no OpenPGP key is available from the client, then an empty certificate is returned. The server MAY then respond with a fatal alert if appropriate. This transaction follows the TLS specification. 3.4 Server Key Exchange When using ephemeral Diffie-Hellman, the Server Key Exchange message is sent to pass the Diffie-Hellman public value to the client. The client and server then use this value to establish the shared secret. This is identical to the operation of standard TLS. 3.5 Certificate Verify The Certificate Verify message for OpenPGP key types is identical to the specification. The signature is made using either DSS or RSA depending on the Cipher Suite. 3.6 Finished The Finished message for OpenPGP key types is identical to the description in the specification. 4. Supported Key Exchange Algorithms OpenPGP certificates can be used with the following key exchange algorithms: Key Exchange Algorithm Certificate Key Type RSA RSA public key; the certificate must allow the key to be used for encryption. DHE_DSS DSS public key. DHE_RSA RSA public key which can be used for signing. The above key exchange algorithms are defined in [TLS]. 5. Cipher Suites No new Cipher Suites are required, in order to use OpenPGP certificates, but some additional Cipher Suites are defined here in order to support algorithms defined in [OpenPGP] but are not present in [TLS]. CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_SHA = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_SHA = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_CAST_CBC_SHA = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_CAST_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x?? }; All of the above Cipher Suites use either the CAST, AES, or TripleDES block ciphers in CBC mode. The choice of hash is either SHA-1 or RIPEMD-160. "Export" algorithms also MAY NOT be used with OpenPGP keys. Implementations are not required to support the above cipher suites. 6. References [TLS] T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [OpenPGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "TLS Extensions", draft-ietf-tls-extensions-02 (work in progress), June 2001. [X509] CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988. -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr From owner-ietf-openpgp@mail.imc.org Thu Jan 17 11:21:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20620 for ; Thu, 17 Jan 2002 11:21:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HEqaV14974 for ietf-openpgp-bks; Thu, 17 Jan 2002 06:52:36 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HEqX314970 for ; Thu, 17 Jan 2002 06:52:33 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA09505; Thu, 17 Jan 2002 09:52:32 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA22199; Thu, 17 Jan 2002 09:52:28 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA14213; Thu, 17 Jan 2002 09:52:25 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA24717; Thu, 17 Jan 2002 09:52:24 -0500 (EST) To: Nikos Mavroyanopoulos Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> From: Derek Atkins Date: 17 Jan 2002 09:52:24 -0500 In-Reply-To: <20020117085114.3854af79.nmav@hellug.gr> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikos Mavroyanopoulos writes: > Hello, > Some days ago I posted to ietf-tls WG mailing list, a modification > of the draft-ietf-tls-openpgp-01. Since this is about openpgp, > I decided to post it here too. > > The original post: > > I wanted to use openpgp certificates with TLS, but > draft-ietf-tls-openpgp-01 is expired, and had some properties that I did > not like. Here I modified the tls-openpgp draft in a way that: > * no new cipher suites need to be defined, in order to use openpgp keys > * does not use keyIDs but key fingerprints > > I'd appreciate any comments on this. You probably do not want to assume that the fingerprint is 20 octets long; fingerprints on v3 RSA keys are only 16 octets long. So, your definition of PGPFingerprint<20> wont work with all OpenPGP keys. Since you're already assuming DSS keys by your 20-octet fingerprint, it should be noted that the v4 (DSS) keyID is just the lower 64-bits of the fingerprint. (RFC2440: 11.2) You probably want to send along the keyID as well as the fingerprint. Most implementations can only lookup a key based on the keyID. As a result, you wont be able to easily lookup v3 RSA keys if you only send the fingerprint. I would recommend you change the definition to: opaque PGPKeyID<8> opaque PGPFingerprintV3<16> opaque PGPFingerprintV4<20> struct { PGPKeyVersion keyVersion; select (keyVersion) { case v3: PGPFingerprintV3; case v4: PGPFingerprintV4; } PGPKeyID; } PGPKeyDescriptor; And then use the PGPKeyDescriptor in your Certificate structure. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jan 17 12:23:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27207 for ; Thu, 17 Jan 2002 12:23:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HH9Pr19339 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:09:25 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc223.dialup.uoi.gr [195.130.119.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HH9I319332 for ; Thu, 17 Jan 2002 09:09:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RG16-0007vm-00; Thu, 17 Jan 2002 19:07:56 +0200 Date: Thu, 17 Jan 2002 18:55:29 +0200 From: Nikos Mavroyanopoulos To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020117185529.42cdf46d.nmav@hellug.gr> In-Reply-To: References: <20020117085114.3854af79.nmav@hellug.gr> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 17 Jan 2002 09:52:24 -0500 Derek Atkins wrote: Derek, thank you for your comments, > You probably do not want to assume that the fingerprint is 20 octets > long; fingerprints on v3 RSA keys are only 16 octets long. So, your > definition of PGPFingerprint<20> wont work with all OpenPGP keys. > Since you're already assuming DSS keys by your 20-octet fingerprint, > it should be noted that the v4 (DSS) keyID is just the lower 64-bits > of the fingerprint. (RFC2440: 11.2) the notation <20> means an upper limit of 20 bytes in TLS (used in RFC2246), so v3 fingerprints can be used. (the specified data are encoded with the size). > You probably want to send along the keyID as well as the fingerprint. > Most implementations can only lookup a key based on the keyID. As a > result, you wont be able to easily lookup v3 RSA keys if you only send > the fingerprint. I would recommend you change the definition to: I'm not quite familiar with OpenPGP, and I had the impression that v3 keys were only defined for backwards compatibility. If v3 keys are still in use I could use something like: > opaque PGPKeyID<8> > opaque PGPFingerprint<20> > > struct { > PGPKeyID pgp_key_id; > PGPFingerprint pgp_fingerprint; > } PGPKeyDescriptor; or > opaque PGPKeyID<8> > opaque PGPFingerprint<20> > enum { v3, v4 } PGPKeyVersion; > > struct { > PGPFingerprint pgp_fingerprint; > PGPKeyVersion keyVersion; > select (PGPKeyVersion) { > case v3: PGPKeyID; > case v4: {}; > } > } PGPKeyDescriptor; The first version always sends the keyID (which is redundant in v4 keys). The second version is a bit complicated, but sends the keyID only for v3 keys. I don't really like it because (at least since today) TLS did not have to know about X.509 certificates' version explicitly. I think it's better to be that way for OpenPGP keys too. > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr From owner-ietf-openpgp@mail.imc.org Thu Jan 17 12:26:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27311 for ; Thu, 17 Jan 2002 12:26:38 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HHEBU19554 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:14:11 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHE8319549 for ; Thu, 17 Jan 2002 09:14:09 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RGXa-0007Oe-00; Thu, 17 Jan 2002 18:41:30 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RG4l-0008B6-00; Thu, 17 Jan 2002 18:11:43 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 18:11:43 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 09:52:24 -0500") Message-ID: <87u1tkoqb4.fsf@alberti.gnupg.de> Lines: 27 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 09:52:24 -0500, Derek Atkins said: > You probably do not want to assume that the fingerprint is 20 octets > long; fingerprints on v3 RSA keys are only 16 octets long. So, your Left pad them with zeroes and store the fingerprint as meta data with the keys or index a DB using the fingerprint. It might even be easier to require the use of v4 keys. > You probably want to send along the keyID as well as the fingerprint. Frankly, I suggested to drop the keyID because the few extra bytes for a fingerprint are not an issue and it makes the code easier if we only have to lookup by fingerprint. > Most implementations can only lookup a key based on the keyID. As a Then they should be fixed. To lookup by keyID you have to calculate the fingerprint anyway for v4 keys. And there won't be many v3 keys in use with TLS. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Thu Jan 17 12:35:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27638 for ; Thu, 17 Jan 2002 12:35:00 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HHO5v20023 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:24:05 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHO3320018 for ; Thu, 17 Jan 2002 09:24:04 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13457; Thu, 17 Jan 2002 12:24:05 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA21162; Thu, 17 Jan 2002 12:24:04 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17041; Thu, 17 Jan 2002 12:24:03 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA00139; Thu, 17 Jan 2002 12:24:03 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 12:24:03 -0500 In-Reply-To: <87u1tkoqb4.fsf@alberti.gnupg.de> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > > You probably want to send along the keyID as well as the fingerprint. > > Frankly, I suggested to drop the keyID because the few extra bytes for > a fingerprint are not an issue and it makes the code easier if we only > have to lookup by fingerprint. Sure, it's redundant for v4 keys but it's required for v3 keys. > > Most implementations can only lookup a key based on the keyID. As a > > Then they should be fixed. To lookup by keyID you have to calculate > the fingerprint anyway for v4 keys. And there won't be many v3 keys > in use with TLS. I don't think that's a reasonable assumption to make. Worse, if you have _ANY_ v3 keys then you need to ship the keyID. Perhaps there is some way that if keyID == lower_part(fingerprint) then we only send the fingerprint, but send keyID if it's !=? > Werner -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jan 17 12:37:09 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27692 for ; Thu, 17 Jan 2002 12:37:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HHLSj19863 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:21:28 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHLQ319858 for ; Thu, 17 Jan 2002 09:21:26 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08343; Thu, 17 Jan 2002 12:21:27 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20662; Thu, 17 Jan 2002 12:21:27 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA15968; Thu, 17 Jan 2002 12:21:27 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA00127; Thu, 17 Jan 2002 12:21:26 -0500 (EST) To: Nikos Mavroyanopoulos Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <20020117185529.42cdf46d.nmav@hellug.gr> From: Derek Atkins Date: 17 Jan 2002 12:21:26 -0500 In-Reply-To: <20020117185529.42cdf46d.nmav@hellug.gr> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikos Mavroyanopoulos writes: > the notation <20> means an upper limit of 20 bytes in TLS (used in > RFC2246), so v3 fingerprints can be used. (the specified data are > encoded with the size). Ok. I am unfamilar with the TLS spec, so thank you for clearing this up. > > You probably want to send along the keyID as well as the fingerprint. > > Most implementations can only lookup a key based on the keyID. As a > > result, you wont be able to easily lookup v3 RSA keys if you only send > > the fingerprint. I would recommend you change the definition to: > > I'm not quite familiar with OpenPGP, and I had the impression that v3 > keys were only defined for backwards compatibility. If v3 keys are still > in use I could use something like: That's ok -- I am. I'm afraid that yes, v3 keys are still in wide use. Anyone who generated their key using PGP 2.x and is still using PGP with that key is de facto using a v3 key. I, personally, am one such user. It is more than just backwards compatibility (IMHO). > > opaque PGPKeyID<8> > > opaque PGPFingerprint<20> > > > > struct { > > PGPKeyID pgp_key_id; > > PGPFingerprint pgp_fingerprint; > > } PGPKeyDescriptor; > > The first version always sends the keyID (which is redundant in v4 keys). I'm willing to live with 8 bytes of redundancy. It's still better than X.509 ;) > The second version is a bit complicated, but sends the keyID only for v3 > keys. I don't really like it because (at least since today) TLS did not > have to know about X.509 certificates' version explicitly. I think it's > better to be that way for OpenPGP keys too. I agree.. Go with the former and always send the extra 8 bytes of keyID. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jan 17 12:47:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28006 for ; Thu, 17 Jan 2002 12:47:44 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HHa5A20658 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:36:05 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHa3320649 for ; Thu, 17 Jan 2002 09:36:03 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RGst-0007s4-00; Thu, 17 Jan 2002 19:03:31 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RGPk-0008DW-00; Thu, 17 Jan 2002 18:33:24 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 18:33:24 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 12:24:03 -0500") Message-ID: <87lmewopaz.fsf@alberti.gnupg.de> Lines: 28 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 12:24:03 -0500, Derek Atkins said: > I don't think that's a reasonable assumption to make. Worse, if you > have _ANY_ v3 keys then you need to ship the keyID. Perhaps there is Why? Because the HKP keyservers are not able to search by fingerprint? Hopefully this will be fixed and the modern key servers support such a lookup (well, not checked but easy to add). I can't imagine that anyone will use an old v3 key for TLS authentication - TLS is always used on a networked machine (surprise) and as such this machine is much more exposed to attacks than the secure boxes we all use to handle or secret keys ;-). If TLS is configured somewhere, a new key should be used for this and this key can in turn be signed by certification key. Using PGP keys with TLS is a new thing and we don't have to take backwards compatibility into account. Ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Thu Jan 17 12:56:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28332 for ; Thu, 17 Jan 2002 12:56:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HHiXV21060 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:44:33 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHiU321049 for ; Thu, 17 Jan 2002 09:44:31 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17212; Thu, 17 Jan 2002 12:44:32 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25796; Thu, 17 Jan 2002 12:44:32 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13032; Thu, 17 Jan 2002 12:44:30 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA00174; Thu, 17 Jan 2002 12:44:30 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 12:44:30 -0500 In-Reply-To: <87lmewopaz.fsf@alberti.gnupg.de> Message-ID: Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Keep in mind that TLS can use "user certificates" too... Are you implying that users with v3 certs have to generate a new key in order to use them in TLS? -derek Werner Koch writes: > On 17 Jan 2002 12:24:03 -0500, Derek Atkins said: > > > I don't think that's a reasonable assumption to make. Worse, if you > > have _ANY_ v3 keys then you need to ship the keyID. Perhaps there is > > Why? Because the HKP keyservers are not able to search by > fingerprint? Hopefully this will be fixed and the modern key servers > support such a lookup (well, not checked but easy to add). > > I can't imagine that anyone will use an old v3 key for TLS > authentication - TLS is always used on a networked machine (surprise) > and as such this machine is much more exposed to attacks than the > secure boxes we all use to handle or secret keys ;-). If TLS is > configured somewhere, a new key should be used for this and this key > can in turn be signed by certification key. > > Using PGP keys with TLS is a new thing and we don't have to take > backwards compatibility into account. > > Ciao, > > Werner > > > -- > Werner Koch Omnis enim res, quae dando non deficit, dum habetur > g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. > Privacy Solutions -- Augustinus > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jan 17 13:15:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28926 for ; Thu, 17 Jan 2002 13:15:26 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HI45E21888 for ietf-openpgp-bks; Thu, 17 Jan 2002 10:04:05 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HI43321884 for ; Thu, 17 Jan 2002 10:04:03 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RHJz-0008Sp-00; Thu, 17 Jan 2002 19:31:31 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RGqm-0008GB-00; Thu, 17 Jan 2002 19:01:20 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 19:01:20 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 12:44:30 -0500") Message-ID: <87hepkoo0f.fsf@alberti.gnupg.de> Lines: 17 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 12:44:30 -0500, Derek Atkins said: > Keep in mind that TLS can use "user certificates" too... Are you > implying that users with v3 certs have to generate a new key > in order to use them in TLS? Yes, for the same reasons as for servers. The majority of keys is v4 for quite a long time now. I know only a few people insisting on using the old keys - even Ted T'so has a v4 key now. And I still don't see a reason why a keyID is needed in TLS. We need the keyIDs to lookup signing keys but this has nothing to do with TLS. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Thu Jan 17 13:19:52 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29053 for ; Thu, 17 Jan 2002 13:19:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HI7mE22029 for ietf-openpgp-bks; Thu, 17 Jan 2002 10:07:48 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HI7j322025 for ; Thu, 17 Jan 2002 10:07:45 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25611; Thu, 17 Jan 2002 13:07:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01513; Thu, 17 Jan 2002 13:07:44 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA07923; Thu, 17 Jan 2002 13:07:44 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA00224; Thu, 17 Jan 2002 13:07:43 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 13:07:43 -0500 In-Reply-To: <87hepkoo0f.fsf@alberti.gnupg.de> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On 17 Jan 2002 12:44:30 -0500, Derek Atkins said: > > > Keep in mind that TLS can use "user certificates" too... Are you > > implying that users with v3 certs have to generate a new key > > in order to use them in TLS? > > Yes, for the same reasons as for servers. The majority of keys is v4 I disagree that these reasons are valid... But that's not important right now.. > And I still don't see a reason why a keyID is needed in TLS. We need > the keyIDs to lookup signing keys but this has nothing to do with TLS. Ok, perhaps I am confused. Could you please explain how the fingerprint would get used the TLS protocol? I thought it was being used to present an "I can use this key" message to the other side, which implies (to me) that the remote end would need to lookup a key based on that number. Could you please explain how this "identifier" is meant to be used within TLS? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jan 17 14:33:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02172 for ; Thu, 17 Jan 2002 14:33:36 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJ86x24086 for ietf-openpgp-bks; Thu, 17 Jan 2002 11:08:06 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJ84324081 for ; Thu, 17 Jan 2002 11:08:04 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RIJw-0001JH-00; Thu, 17 Jan 2002 20:35:32 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RHps-0008LH-00; Thu, 17 Jan 2002 20:04:28 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 20:04:28 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 13:07:43 -0500") Message-ID: <87d708ol37.fsf@alberti.gnupg.de> Lines: 34 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 13:07:43 -0500, Derek Atkins said: > used to present an "I can use this key" message to the other side, > which implies (to me) that the remote end would need to lookup a key > based on that number. Could you please explain how this "identifier" That is also my understanding. The point is whether it is possible lookup a key based on the fingerprint. I say yes because for a local lookup you should index you keyring anyway (think about a server and millions of users) and then it doesn't matter whether to lookup by fingerprint or keyID. There is even no reasonable high overhead when inserting a new key: Most keys are v4 and to get a keyID you need to calculate the fingerprint anyway. For the few v3 keys (cf. dtype.org for keyserver statistics) you can avoid the fingerprint calculation but really this doesn't matter anymore. For a lookup via keyserver there is probably a problem with the HKS type servers but they have so many problems that they have to replaced anyway. I am pretty sure that the NAI certserver is able to do a lookup by fingerprint and to add this to the ALMI and cryptnet servers will only take a few hours. So why not using _only_ the fingerprint in TLS. IIRC we had a discussion a long time ago to allow the use of fingerprint in the next version of signature packets. My point is that the fingerprint is the correct way to identify a key and that there is no need for backward compatibilty when a new protocol is designed. Let's avoid the X.509 problem of not knowing how to cleany identify a key. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Thu Jan 17 15:09:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06894 for ; Thu, 17 Jan 2002 15:09:55 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0HJqII25264 for ietf-openpgp-bks; Thu, 17 Jan 2002 11:52:18 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJqD325259 for ; Thu, 17 Jan 2002 11:52:14 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA09525; Thu, 17 Jan 2002 14:52:13 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA28143; Thu, 17 Jan 2002 14:52:10 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id OAA20905; Thu, 17 Jan 2002 14:52:10 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id OAA00567; Thu, 17 Jan 2002 14:52:09 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 14:52:09 -0500 In-Reply-To: <87d708ol37.fsf@alberti.gnupg.de> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > Let's avoid the X.509 > problem of not knowing how to cleany identify a key. Why not add 8 more bytes and you still get this functionality and backwards compatibility? Keep in mind that lack-of-backwards-compatibility is what got us where we are today, a fragmented community of people. It all started with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP. Backwards compatibility is a Good Thing, in particular when talking about long-lived identity keys. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jan 17 19:58:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16560 for ; Thu, 17 Jan 2002 19:58:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0I0dSP04374 for ietf-openpgp-bks; Thu, 17 Jan 2002 16:39:28 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I0dQ304370 for ; Thu, 17 Jan 2002 16:39:27 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ41OR00.8G3; Thu, 17 Jan 2002 17:34:03 -0800 Message-ID: <3C476EB8.65DC0295@cyphers.net> Date: Thu, 17 Jan 2002 16:39:20 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: ietf-tls@lists.certicom.com Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another important point about backwards compatibility: the current OpenPGP/TLS draft already has well over a million deployed clients. Every PGP client since I believe 6.0.0 (September 1998) supports PGPtls as described in the draft, and every PGP Keyserver since that time period also supports PGPtls. PGPtls can be used for split key network reconstitution, normal key searches on keyservers, client authentication to keyservers for the purpose of deleting or disabling keys, and a whole host of other things in various products from NAI and others. While PGPtls in the PGPsdk was the first implementation (for which source code is currently available at the pgp website, and part of every source release we've done for the last few years), I know others have mentioned other implementations as well to me over the last year or so. In addition to ignoring all the fielded uses and implementations of OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency problem on the TLSEXT draft, and the Fingerprint/KeyID confusion which I've previously detailed on the ietf-tls list. It would be a huge mistake to adopt the proposed changes. Derek Atkins wrote: > > Werner Koch writes: > > > Let's avoid the X.509 > > problem of not knowing how to cleany identify a key. > > Why not add 8 more bytes and you still get this functionality and > backwards compatibility? > > Keep in mind that lack-of-backwards-compatibility is what got us > where we are today, a fragmented community of people. It all > started with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP. > > Backwards compatibility is a Good Thing, in particular when talking > about long-lived identity keys. - - -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEdufKy7FkvPc+xMEQJ6FQCfStNGaVZH3v00PfvlC+K/OKF0fNEAniX7 HwmnVYqVPtvH3TEmFWstFLd/ =L7x2 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jan 17 22:13:27 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19444 for ; Thu, 17 Jan 2002 22:13:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I314T07187 for ietf-openpgp-bks; Thu, 17 Jan 2002 19:01:04 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I312307183 for ; Thu, 17 Jan 2002 19:01:02 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ488Q00.8G6; Thu, 17 Jan 2002 19:55:38 -0800 Message-ID: <3C478FE8.9BF9BE08@cyphers.net> Date: Thu, 17 Jan 2002 19:00:56 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF Transport Layer Security WG CC: ietf-openpgp@imc.org Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > Will Price writes: > > Another important point about backwards compatibility: the > > current OpenPGP/TLS draft already has well over a million > > deployed clients. Every PGP client since I believe 6.0.0 > > (September 1998) supports PGPtls as described in the draft, and > > every PGP Keyserver since that time period also supports PGPtls. > I don't find this argument very convincing. You implement things > that are Internet-Drafts at your own risk. That's why every I-D > has a disclaimer at the top. If popularity were the criterion > for standardization, we could disband the IETF and just wait > for Microsoft to tell us what the standard was. We published the draft, then we implemented, then we published code. This is standard procedure for anybody in the IETF. Implementations and implementation experience are critical factors in the WG, and if they could be ignored then TLS/SSL would be quite different today I'm sure you'll admit. > > In addition to ignoring all the fielded uses and implementations > > of OpenPGP/TLS, Nikos' proposed changes also suffer from the > > dependency problem on the TLSEXT draft, > This is a feature not a bug. Definitely seems like a bug to me. When I originally designed this, it was clear that TLS should have had a standard way of choosing a certificate type much like IKE does. I believe I raised this issue on the list at the time and the response of the list was IIRC muted agreement, but there were no plans for a new version of the TLS draft so it wasn't a discussion that was going to go anywhere. The others I spoke with in the WG felt that using the cipher suite field was the way to go. Writing a draft for a new certificate type which defines an impromptu technique for how to negotiate an OpenPGP certificate type is clearly not the way to go. TLS should always have had a certificate type field built-in. Were TLS to have such a standardized method, the OpenPGP/TLS draft should be modified to adopt that. However, it's not particularly important that such a method be developed. No more than 2 perhaps 3 certificate types will survive into the future, so that doesn't appear to be a serious concern. Worrying about running out of 16 bit space for cipher suites is unnecessary to me. We should now and should always have been conservative about which cipher suites get assigned numbers. No more than 20 cipher suites are in active use today, and going forward into the future I expect those to change but the overall number of actively used cipher suites will get smaller converging on the popular few. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEePtay7FkvPc+xMEQLJ2ACg5/R+TIlgEpWe4hZOQbjjodFNfyYAn0A8 hskbpVu9J97s/Orw23zs3yzB =Kv8s -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jan 17 23:26:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21827 for ; Thu, 17 Jan 2002 23:26:41 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0I4C1v08722 for ietf-openpgp-bks; Thu, 17 Jan 2002 20:12:01 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I4Bv308714 for ; Thu, 17 Jan 2002 20:11:57 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ4BIW00.0H2; Thu, 17 Jan 2002 21:06:32 -0800 Message-ID: <3C47A087.82FD450E@cyphers.net> Date: Thu, 17 Jan 2002 20:11:51 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF Transport Layer Security WG CC: ietf-openpgp@imc.org Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 History shows that is not actually true. For instance, TLS is almost identical to SSL. Why is this? Is it because "implementation experience" showed that SSL was simply the One True Way to write a transport security protocol? No. It's because there was a large SSL installed base of which the TLS designers wanted to take advantage, and thus the more identical the protocol was the more it would be accepted. - From an implementation experience point of view, I would say that the last four years have demonstrated the cipher suite space issue is not an issue, and the "we're going to run out of space" argument is the only one made to defend this negotiation proposal which depends on an extension proposal. Time has demonstrated that particular sky is not going to fall, and thus in the absence of any method in the standard to specify certificate type the cipher suite field remains the correct place to put this. Eric Rescorla wrote: > Implementation experience is an important factor. The existence of > implementations which were written pre-Proposed and which would be > broken by a new specification isn't. If you want to argue that your > implementation experience indicates that this is the right approach > and some other approach is wrong, go ahead. I don't see you arguing > that. Rather, I see you arguing that you (and presumably others) > have implemented a specific approach and would be inconvenienced by > any other approach, regardless of its technical merits. That's not > the basis on which the IETF is supposed to make decisions. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEegfqy7FkvPc+xMEQLzTgCgwo11ZaRZPQxI0Kw7vuEVGnJCIQYAoKqk 0a78Fe7qhgTOT+EqZlvBruk2 =Lurc -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 18 00:24:57 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23067 for ; Fri, 18 Jan 2002 00:24:56 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I5B8q10076 for ietf-openpgp-bks; Thu, 17 Jan 2002 21:11:08 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I5B6310072 for ; Thu, 17 Jan 2002 21:11:06 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ4E9I00.6HF; Thu, 17 Jan 2002 22:05:42 -0800 Message-ID: <3C47AE65.AA25692E@cyphers.net> Date: Thu, 17 Jan 2002 21:11:01 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF Transport Layer Security WG CC: ietf-openpgp@imc.org Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > Will Price writes: > > History shows that is not actually true. For instance, TLS is > > almost identical to SSL. Why is this? Is it because > > "implementation > > experience" showed that SSL was simply the One True Way to write > > a transport security protocol? No. It's because there was a large > > SSL installed base of which the TLS designers wanted to take > > advantage, and thus the more identical the protocol was the more > > it would be accepted. > Funny, I think of the TLS experience the opposite way: Despite > the fact that SSL had an enormous installed base TLS is > incompatible with SSL. > > > - From an implementation experience point of view, I would say > > that the last four years have demonstrated the cipher suite space > > issue is not an issue, and the "we're going to run out of space" > > argument is the only one made to defend this negotiation proposal > > which depends on an extension proposal. > No. Even in the absence of the cipher suite depletion argument, > your approach would be a clumsy hack. Orthogonality is a good > thing. Orthogonality? Like the orthogonality of lumping the cipher type, key length, hash type, key exchange type, and export status into one sixteen bit number? I don't think so. Sorry, that argument doesn't fly in the context of TLS. The Orthogonality to the Nth degree doorway is in the IPsec WG. For TLS 1.0, the cipher suite remains the right place to put this. What we wanted in 1998, and what we still want today is a TLS 1.1 which has a field for the certificate type. I think we both agree in principle that certificate type should have had its own field. The difference is that you're willing ditch backwards compatibility and change OpenPGP/TLS to include its own clumsy hack for specifying the certificate type and depend on yet another draft, whereas we've done things the TLS 1.0 way in TLS 1.0 and would support fixing the protocol itself in a future rev. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEeuHay7FkvPc+xMEQI3rACglfiwns8NBx0Eq0VrCgsemE77rNMAoOdc vqYhnUOI8eod+jgAT5Jmj5zt =rydy -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 18 04:08:13 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04468 for ; Fri, 18 Jan 2002 04:08:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I8kEb29132 for ietf-openpgp-bks; Fri, 18 Jan 2002 00:46:14 -0800 (PST) Received: from hackserv.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0I8k9329117 for ; Fri, 18 Jan 2002 00:46:13 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Fri, 18 Jan 2002 10:41:23 0200 Message-ID: <3C47DFB3.8139C297@saiknes.lv> Date: Fri, 18 Jan 2002 10:41:23 +0200 From: disastry@saiknes.lv Organization: disastry.NO.SPaM.NET X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Werner Koch wrote: > On 17 Jan 2002 09:52:24 -0500, Derek Atkins said: > > > You probably do not want to assume that the fingerprint is 20 octets > > long; fingerprints on v3 RSA keys are only 16 octets long. So, your > > Left pad them with zeroes and store the fingerprint maybe right pad fingerprint with keyid. but there is only space for short 4byte keyid.. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPEfDTjBaTVEuJQxkEQNPdwCg81w2dYiwrZW4/eOgLc3eF9xwYpsAniZu +Y+mULBtyamyoA3YiHoDPInA =zBCL -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jan 18 07:17:01 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07917 for ; Fri, 18 Jan 2002 07:17:01 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IBw9017592 for ietf-openpgp-bks; Fri, 18 Jan 2002 03:58:09 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IBw7317583 for ; Fri, 18 Jan 2002 03:58:07 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RY5X-00053q-00; Fri, 18 Jan 2002 13:25:43 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RXb9-0001NS-00; Fri, 18 Jan 2002 12:54:19 +0100 To: ietf-openpgp@imc.org, ietf-tls@lists.certicom.com Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> <3C476EB8.65DC0295@cyphers.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Fri, 18 Jan 2002 12:54:19 +0100 In-Reply-To: <3C476EB8.65DC0295@cyphers.net> (Will Price's message of "Thu, 17 Jan 2002 16:39:20 -0800") Message-ID: <878zavoowk.fsf@alberti.gnupg.de> Lines: 53 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) 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: [I am not on the tls list, feel free to resend it] On Thu, 17 Jan 2002 16:39:20 -0800, Will Price said: > Another important point about backwards compatibility: the current > OpenPGP/TLS draft already has well over a million deployed clients. This is an expired draft and as such not anymore accessible. And: at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." > Every PGP client since I believe 6.0.0 (September 1998) supports > PGPtls as described in the draft, and every PGP Keyserver since that PGP has a lot of proprietary features which are either in conflict to OpenPGP or not documented at all. NAI folks are talking for years: "We will write up the specification RSN" - I have never seen more than these announcements. Some non-NAI folks reverse engineered the format of the photo ID from actual PGP output, so that David Shaw could implement this in GnuPG but most other stuff is unknown and NAI is even dropping OpenPGP required features (v4 sigs on data) - well may be this is a bug, but those things have happened far too often. > While PGPtls in the PGPsdk was the first implementation (for which > source code is currently available at the pgp website, and part of > every source release we've done for the last few years), I know And since you re-opened the source for >= 7, you use a license which makes the source useless and actual dangerous for a programmer to look at. > In addition to ignoring all the fielded uses and implementations of > OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency There is no documentation on this format - may be PGP implemented that draft but nobody writing TLS or OpenPGP code is able to even check this as there is no usable source. If NAI would have been interested in standard conformace, the draft should be reissued regulary and the extensions to OpenPGP discussed with the OpenPGP WG. The same thing goes for OpenPGP features like MDC and a new transport format for secret keys - NAI seems not to be interested in it anymore. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Fri Jan 18 09:56:39 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13466 for ; Fri, 18 Jan 2002 09:56:38 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0IEf6d25474 for ietf-openpgp-bks; Fri, 18 Jan 2002 06:41:06 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc217.dialup.uoi.gr [195.130.119.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IEf3325470 for ; Fri, 18 Jan 2002 06:41:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RaBA-00033E-00 for ; Fri, 18 Jan 2002 16:39:40 +0200 Date: Fri, 18 Jan 2002 16:18:46 +0200 From: Nikos Mavroyanopoulos To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020118161846.7db5732b.nmav@hellug.gr> In-Reply-To: <87d708ol37.fsf@alberti.gnupg.de> References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 17 Jan 2002 20:04:28 +0100 Werner Koch wrote: > > used to present an "I can use this key" message to the other side, > > which implies (to me) that the remote end would need to lookup a key > > based on that number. Could you please explain how this "identifier" > That is also my understanding. The point is whether it is possible > lookup a key based on the fingerprint. I say yes because for a local > lookup you should index you keyring anyway (think about a server and > millions of users) and then it doesn't matter whether to lookup by > fingerprint or keyID. I should add here that: This identifier is used with 2 purposes: 1. To identify the key 2. To provide equal security with the case where the actual key is sent [0] The reason I replaced keyIDs with Fingerprints is that this identifier is covered by the TLS Finished messages. This means that after the Finished messages are sent, the parties know that the peer got a key which is identified by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify for this. If they should be added, they should be added for backwards compatibility and only for this reason. [0]: This is also discussed in the draft-ietf-tls-extensions-02 in the security considerations chapter (client certificate URL extension). [1]: I don't believe that a hash truncated to 64bits provides any security -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr From owner-ietf-openpgp@mail.imc.org Sat Jan 19 08:36:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18949 for ; Sat, 19 Jan 2002 08:36:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0JDBES24872 for ietf-openpgp-bks; Sat, 19 Jan 2002 05:11:14 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc205.dialup.uoi.gr [195.130.119.205]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0JDBA324868 for ; Sat, 19 Jan 2002 05:11:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RvFk-0000FA-00 for ; Sat, 19 Jan 2002 15:09:48 +0200 Date: Sat, 19 Jan 2002 15:09:47 +0200 From: Nikos Mavroyanopoulos To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020119150947.3da6f42b.nmav@hellug.gr> In-Reply-To: <20020118161846.7db5732b.nmav@hellug.gr> References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> <20020118161846.7db5732b.nmav@hellug.gr> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 18 Jan 2002 16:18:46 +0200 Nikos Mavroyanopoulos wrote: > > That is also my understanding. The point is whether it is possible > > lookup a key based on the fingerprint. I say yes because for a local > > lookup you should index you keyring anyway (think about a server and > > millions of users) and then it doesn't matter whether to lookup by > > fingerprint or keyID. [...] > The reason I replaced keyIDs with Fingerprints is that this identifier > is covered by the TLS Finished messages. This means that after the Finished > messages are sent, the parties know that the peer got a key which is identified > by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify > for this. If they should be added, they should be added for backwards > compatibility and only for this reason. On second thoughts, I think there is not an issue for backwards compatibility, since a client is not required to send the fingerprint (he may send the key). A holder of a v3 key may send the key instead of the fingerprint, in the case he suspects that the server could not retrieve the key. I think this is the most clean solution. If you agree I'll keep the original version. -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr From owner-ietf-openpgp@mail.imc.org Thu Jan 24 15:33:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04892 for ; Thu, 24 Jan 2002 15:33:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OKEqM07674 for ietf-openpgp-bks; Thu, 24 Jan 2002 12:14:52 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OKEp307670 for ; Thu, 24 Jan 2002 12:14:51 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for ; Thu, 24 Jan 2002 12:14:48 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: Date: Thu, 24 Jan 2002 12:14:31 -0800 To: ietf-openpgp@imc.org From: Jon Callas Subject: OpenPGP vs. OpenPGP/MIME Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me state off the bat that I'm taking off any official hat as author/editor/expert I might have. This is my personal opinion as a computer user who uses OpenPGP. I'm distressed by the opinion that I have heard (usually second or more hand) that somehow base OpenPGP in 2440+ is deprecated, uncool, or something, and that the way to go is OpnPGP/MIME. I think this is patently ridiculous. Usually, the way to go is to use base OpenPGP, which for all its flaws, has one major advantage over all other cryptosystems that I've used, including OpenPGP/MIME. That advantage is this: It actually works. Nearly never do I fail to decrypt, verify, etc. an OpenPGP object, and when I do, the problem can be solved by ASCII armoring the output -- which means that the problem is implicit line-end translation that damages the binary. To repeat, this is not a philosophical objection. This is not because I have some horrid dislike for MIME. Well, all right, I do have a horrid dislike for MIME, but I have a horrid dislike for MIME solely because it doesn't work. I'm a practical person. I like any and all technologies that work without my fussing with them. If we waved a magic wand and these things started working, I wouldn't object. I would even start says, "Hey, MIME actually works." But they don't work, and I do dislike them for this lack. MIME does one thing well -- putting in files as attachments, and thus making email a convenient file transfer protocol. This almost always works. The further one strays from this basic function, the less reliable it is. Sending a message in HTML and MIME-attaching pictures works pretty reliably. But by the time you get to doing security multiparts, interoperability mostly sucks. With OpenPGP/MIME, this is particularly frustrating because there is almost always a perfectly good way to do the same thing without MIME that would have worked fine. Using OpenPGP/MIME makes sense when: (1) The operation you were going to do needed to use MIME anyway. For example, you're sending someone an attachment, and you'd like it encrypted. (2) You're using some feature of OpenPGP/MIME that gives you useful things you can't get any other way. Parallel signatures spring to mind. Using OpenPGP/MIME makes no sense when: (1) Whatever you were doing does little take the "-----BEGIN PGP MESSAGE-----" header and prefix it with one that says, "Content type: application/whatever". (2) Protecting a blob of data has nothing whatsoever to do with MIME. For example, I know of a banking system that uses OpenPGP encoded messages. There's no need for MIME here. MIME-coded messages have great uses. But alas, even to this day, there are lots of uses of them that aren't quite ready for prime time. Let's face it -- the majority of mailers don't do MIME correctly, and if I have to pry apart attachments to get to a clearsigned signature just so I can re-assemble the thing in a text editor so I can check the signature, I'm probably not going to do it. It had better be pretty important for me to take five minutes out of my day to bother. If it's encrypted, it's a lot easier for me to decide that the message is more akin to the last chance offers for domain names, offers to buy drugs without prescriptions, and entreaties to skim off some subsarharan money that I get, and treat the message the same way. Jon From owner-ietf-openpgp@mail.imc.org Thu Jan 24 17:00:02 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07468 for ; Thu, 24 Jan 2002 17:00:02 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OLjXI09087 for ietf-openpgp-bks; Thu, 24 Jan 2002 13:45:33 -0800 (PST) Received: from claude.kendall.akamai.com (wirefire.akamai.com [65.202.32.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OLjW309083 for ; Thu, 24 Jan 2002 13:45:32 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g0OLjYx00919 for ietf-openpgp@imc.org; Thu, 24 Jan 2002 16:45:34 -0500 Date: Thu, 24 Jan 2002 16:45:34 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020124214534.GA677@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Gibbous (80% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 24, 2002 at 12:14:31PM -0800, Jon Callas wrote: > > Let me state off the bat that I'm taking off any official hat as > author/editor/expert I might have. This is my personal opinion as a > computer user who uses OpenPGP. > > I'm distressed by the opinion that I have heard (usually second or more > hand) that somehow base OpenPGP in 2440+ is deprecated, uncool, or > something, and that the way to go is OpnPGP/MIME. I think at least some of those opinions are based on section 2.4 in 2440bis: Note that many applications, particularly messaging applications, will want more advanced features as described in the OpenPGP-MIME document, RFC2015. An application that implements OpenPGP for messaging SHOULD implement OpenPGP-MIME. Statements like "many applications, ... will want more advanced..", and "SHOULD" imply (to my eye) "This is what I should use. The other way must not be as good, or the RFC wouldn't have told me I SHOULD use this." > MIME-coded messages have great uses. But alas, even to this day, there are > lots of uses of them that aren't quite ready for prime time. Let's face it > -- the majority of mailers don't do MIME correctly, and if I have to pry > apart attachments to get to a clearsigned signature just so I can > re-assemble the thing in a text editor so I can check the signature, I'm > probably not going to do it. I actually like PGP/MIME quite a lot - it handles painlessly a lot of fussy details that otherwise I'd have to handle. I stopped using it when I found myself in a corporate environment where the majority of people were using various corporate mailers that blew up in various odd ways with it. I'm sure this isn't a PGP/MIME thing - they'd have blown up with any MIME they didn't understand, but while a regular clearsigned signature can be ignored by those people that either don't care or don't use PGP, a PGP/MIME message does not always degrade quite so gracefully. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Thu Jan 24 18:02:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09061 for ; Thu, 24 Jan 2002 18:02:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0OMeeC10130 for ietf-openpgp-bks; Thu, 24 Jan 2002 14:40:40 -0800 (PST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OMeb310125 for ; Thu, 24 Jan 2002 14:40:38 -0800 (PST) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.2/8.12.2) with ESMTP id g0OMe3HJ018979 for ; Thu, 24 Jan 2002 23:40:08 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020124214534.GA677@akamai.com> From: Simon Josefsson In-Reply-To: <20020124214534.GA677@akamai.com> (David Shaw's message of "Thu, 24 Jan 2002 16:45:34 -0500") Date: Thu, 24 Jan 2002 23:38:13 +0100 Message-ID: Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.80 (i686-pc-linux-gnu) 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: David Shaw writes: > I stopped using it when I found myself in a corporate environment > where the majority of people were using various corporate mailers that > blew up in various odd ways with it. I'm sure this isn't a PGP/MIME > thing - they'd have blown up with any MIME they didn't understand, but > while a regular clearsigned signature can be ignored by those people > that either don't care or don't use PGP, a PGP/MIME message does not > always degrade quite so gracefully. I think you just pretty well described what Jon meant by PGP/MIME often not working in practice, whereas OpenPGP usually does work. I agree with Jon's opinion. PGP/MIME interoperability is bad. I believe it is the design of RFC 1847 that makes interoperability low. I'm even considering arguing for the solution chosen by Outlook PGP plugins when it comes to PGP and MIME, just PGP encrypt each MIME part without touching the MIME headers at all. That solution _works_, even though it is ugly and bad and wrong from a engineering point of view. From owner-ietf-openpgp@mail.imc.org Thu Jan 24 19:49:03 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10832 for ; Thu, 24 Jan 2002 19:49:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ONE4U10648 for ietf-openpgp-bks; Thu, 24 Jan 2002 15:14:04 -0800 (PST) Received: from mail.mediacompany.com (postfix@castor.mediacompany.com [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ONE2310643 for ; Thu, 24 Jan 2002 15:14:02 -0800 (PST) Received: from sobolev.does-not-exist.org (unknown [62.144.244.136]) by mail.mediacompany.com (Postfix) with ESMTP id 0E1884805; Fri, 25 Jan 2002 00:13:50 +0100 (CET) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 8D8F02ED15; Thu, 24 Jan 2002 23:46:03 +0100 (CET) Date: Thu, 24 Jan 2002 23:46:03 +0100 From: Thomas Roessler To: Simon Josefsson Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020124224603.GA3429@sobolev.does-not-exist.org> Mail-Followup-To: Simon Josefsson , ietf-openpgp@imc.org References: <20020124214534.GA677@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-01-24 23:38:13 +0100, Simon Josefsson wrote: >I agree with Jon's opinion. PGP/MIME interoperability is bad. Really? It certainly won't get worse than MIME interoperability in general. >I believe it is the design of RFC 1847 that makes interoperability >low. I'm even considering arguing for the solution chosen by >Outlook PGP plugins when it comes to PGP and MIME, just PGP >encrypt each MIME part without touching the MIME headers at all. Funny enough, S/MIME uses RFC 1847 as well, and that one works. -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Thu Jan 24 20:07:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11072 for ; Thu, 24 Jan 2002 20:07:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P0qbL12590 for ietf-openpgp-bks; Thu, 24 Jan 2002 16:52:37 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0P0qa312585 for ; Thu, 24 Jan 2002 16:52:36 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 24 Jan 2002 16:52:34 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20020124224603.GA3429@sobolev.does-not-exist.org> References: <20020124214534.GA677@akamai.com> <20020124224603.GA3429@sobolev.does-not-exist.org> Date: Thu, 24 Jan 2002 16:48:32 -0800 To: Thomas Roessler , Simon Josefsson From: Jon Callas Subject: Re: OpenPGP vs. OpenPGP/MIME Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:46 PM +0100 1/24/02, Thomas Roessler wrote: >On 2002-01-24 23:38:13 +0100, Simon Josefsson wrote: > >>I agree with Jon's opinion. PGP/MIME interoperability is bad. > >Really? It certainly won't get worse than MIME interoperability in >general. > That is precisely my point. It's not a PGP problem, it's a MIME problem. Which means that PGP/MIME is a good thing in theory, but not in practice. Once MIME interoperability starts working, more power to it. >>I believe it is the design of RFC 1847 that makes interoperability >>low. I'm even considering arguing for the solution chosen by >>Outlook PGP plugins when it comes to PGP and MIME, just PGP >>encrypt each MIME part without touching the MIME headers at all. > >Funny enough, S/MIME uses RFC 1847 as well, and that one works. Funny enough, not I nor anyone I know has ever used S/MIME successfully. But I suspect that is cultural more than technical. Jon From owner-ietf-openpgp@mail.imc.org Thu Jan 24 20:30:19 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11374 for ; Thu, 24 Jan 2002 20:30:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P1EXp13659 for ietf-openpgp-bks; Thu, 24 Jan 2002 17:14:33 -0800 (PST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0P1EW313655 for ; Thu, 24 Jan 2002 17:14:32 -0800 (PST) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GQG00E84ZL11G@eListX.com> for ietf-openpgp@imc.org; Thu, 24 Jan 2002 20:17:25 -0500 (EST) Date: Thu, 24 Jan 2002 20:17:12 -0500 (EST) From: James M Galvin Subject: Re: OpenPGP vs. OpenPGP/MIME In-reply-to: X-X-Sender: galvin@two.elistx.com To: Simon Josefsson Cc: ietf-openpgp@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Jan 2002, Simon Josefsson wrote: I believe it is the design of RFC 1847 that makes interoperability low. In what way? Please explain. Jim co-Author of RFC1847 (for which a revision is in progress) -- James M. Galvin From owner-ietf-openpgp@mail.imc.org Thu Jan 24 20:36:56 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11508 for ; Thu, 24 Jan 2002 20:36:55 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P1MV114064 for ietf-openpgp-bks; Thu, 24 Jan 2002 17:22:31 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0P1MU314059 for ; Thu, 24 Jan 2002 17:22:30 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g0P1MSc08889 for ietf-openpgp@imc.org; Thu, 24 Jan 2002 20:22:28 -0500 Date: Thu, 24 Jan 2002 20:22:28 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020125012228.GA8870@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020124214534.GA677@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Gibbous (81% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 24, 2002 at 11:38:13PM +0100, Simon Josefsson wrote: > > David Shaw writes: > > > I stopped using it when I found myself in a corporate environment > > where the majority of people were using various corporate mailers that > > blew up in various odd ways with it. I'm sure this isn't a PGP/MIME > > thing - they'd have blown up with any MIME they didn't understand, but > > while a regular clearsigned signature can be ignored by those people > > that either don't care or don't use PGP, a PGP/MIME message does not > > always degrade quite so gracefully. > > I think you just pretty well described what Jon meant by PGP/MIME > often not working in practice, whereas OpenPGP usually does work. Exactly. I was agreeing with Jon as well (did I accidentally say OpenPGP somewhere where I meant PGP/MIME or vice versa?) In my experience, MIME in general except for two cases too frequently does "interesting" things. Those two good cases are a) the really common stuff (attaching a file and forwarding an email, possibly with its own attachments), and b) the stuff the vendor provides, and therefore tests (S/MIME, etc.) David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Fri Jan 25 07:39:24 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00539 for ; Fri, 25 Jan 2002 07:39:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PCOQT27953 for ietf-openpgp-bks; Fri, 25 Jan 2002 04:24:26 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PCOO327949 for ; Fri, 25 Jan 2002 04:24:24 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA18723; Fri, 25 Jan 2002 21:24:19 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA24532; Fri, 25 Jan 2002 21:24:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA09421; Fri, 25 Jan 2002 21:24:19 +0900 (JST) Date: Fri, 25 Jan 2002 21:25:37 +0900 (JST) Message-Id: <20020125.212537.125101827.kazu@iijlab.net> To: galvin@acm.org, ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: James M Galvin Subject: Re: OpenPGP vs. OpenPGP/MIME > I > believe it is the design of RFC 1847 that makes interoperability > low. > > In what way? Please explain. I think RFC 1847 has several ambiguities: (1) It's not clear whether or not the protocol parameter is case-sensitive. The parameter indicates content type, which is case-insensitive, of a second part. However, the parameter is case-sensitive because RFC 1847 does not mention this explicitly. (2) It's not clear how a receiving MUA should do when the value of the protocol parameter is different from the value of content type (of the first part for encryption and of the second part for signature.) (3) It's not clear how a receiving MUA should do when the value of the micalg parameter is differnt from the value specified in the second part(e.g a PGP packet for PGP/MIME). > co-Author of RFC1847 (for which a revision is in progress) Good news. Where can I find the draft? --Kazu From owner-ietf-openpgp@mail.imc.org Fri Jan 25 08:29:17 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01830 for ; Fri, 25 Jan 2002 08:29:17 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PDITh03040 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:18:29 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDIQ303036 for ; Fri, 25 Jan 2002 05:18:26 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16U6hY-0004Jb-00; Fri, 25 Jan 2002 14:47:32 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16U6CB-0003vc-00; Fri, 25 Jan 2002 14:15:07 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020125.212537.125101827.kazu@iijlab.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Fri, 25 Jan 2002 14:15:06 +0100 In-Reply-To: <20020125.212537.125101827.kazu@iijlab.net> (Kazu Yamamoto's message of "Fri, 25 Jan 2002 21:25:37 +0900 (JST)") Message-ID: <87u1tapo6d.fsf@alberti.gnupg.de> Lines: 25 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Fri, 25 Jan 2002 21:25:37 +0900 (JST), Kazu Yamamoto (³Ü§) said: > (2) It's not clear how a receiving MUA should do when the value of the > protocol parameter is different from the value of content type (of > the first part for encryption and of the second part for How an error is handled is not in the scope of most protocols. Do whatever you see fits. Issue a warning so that such errors don't get unnoticed. > (3) It's not clear how a receiving MUA should do when the value of > the micalg parameter is differnt from the value specified in the > second part(e.g a PGP packet for PGP/MIME). For PGP just ignore it. It does not make sense because you can't just feed the hash into a OpenPGP verifier (there are other informations needed to be hashed along with the message). Well, unless you want to have a big monolithic application which can pass hash contexts around. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Fri Jan 25 08:29:20 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01842 for ; Fri, 25 Jan 2002 08:29:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PDAA702480 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:10:10 -0800 (PST) Received: from slipsten.extundo.com ([195.42.214.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDA7302476 for ; Fri, 25 Jan 2002 05:10:07 -0800 (PST) Received: (from jas@localhost) by slipsten.extundo.com (8.11.6/8.11.6) id g0PD9s215837; Fri, 25 Jan 2002 14:09:54 +0100 From: Simon Josefsson To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020124214534.GA677@akamai.com> <20020124224603.GA3429@sobolev.does-not-exist.org> Date: Fri, 25 Jan 2002 14:09:54 +0100 In-Reply-To: <20020124224603.GA3429@sobolev.does-not-exist.org> (Thomas Roessler's message of "Thu, 24 Jan 2002 23:46:03 +0100") Message-ID: Lines: 21 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu) 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: Thomas Roessler writes: >> I agree with Jon's opinion. PGP/MIME interoperability is bad. > > Really? It certainly won't get worse than MIME interoperability in > general. MIME interop isn't very good, when you beyond the simple features. As an example, my mail server filter multipart/signed. I have no idea why, and of course it is a bug, but the point is that for some reason the deployment of PGP/MIME failed here. >> I believe it is the design of RFC 1847 that makes interoperability >> low. I'm even considering arguing for the solution chosen by Outlook >> PGP plugins when it comes to PGP and MIME, just PGP encrypt each >> MIME part without touching the MIME headers at all. > > Funny enough, S/MIME uses RFC 1847 as well, and that one works. S/MIME doesn't use RFC 1847 for encrypting messages, and S/MIME allows non-RFC 1847 mechanisms when it comes to signed messages as well. From owner-ietf-openpgp@mail.imc.org Fri Jan 25 09:06:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03022 for ; Fri, 25 Jan 2002 09:06:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PDqLK04054 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:52:21 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDqJ304049 for ; Fri, 25 Jan 2002 05:52:20 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id WAA27492 for ; Fri, 25 Jan 2002 22:52:20 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA01587 for ; Fri, 25 Jan 2002 22:52:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA16831 for ; Fri, 25 Jan 2002 22:52:19 +0900 (JST) Date: Fri, 25 Jan 2002 22:53:37 +0900 (JST) Message-Id: <20020125.225337.68541953.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <87u1tapo6d.fsf@alberti.gnupg.de> References: <20020125.212537.125101827.kazu@iijlab.net> <87u1tapo6d.fsf@alberti.gnupg.de> X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Werner Koch Subject: Re: OpenPGP vs. OpenPGP/MIME > > (2) It's not clear how a receiving MUA should do when the value of the > > protocol parameter is different from the value of content type (of > > the first part for encryption and of the second part for > > How an error is handled is not in the scope of most protocols. Do > whatever you see fits. I understand what you mean. And I agree with you in many cases. However, RFC 1847 is to define a signature service. If error handing is implementation dependent, a broken multipart/security is verified as GOOD in some MUAs and it is verified as BAD in other MUAs. This is not good for signature services. > > (3) It's not clear how a receiving MUA should do when the value of > > the micalg parameter is differnt from the value specified in the > > second part(e.g a PGP packet for PGP/MIME). > > For PGP just ignore it. It does not make sense because you can't just > feed the hash into a OpenPGP verifier (there are other informations > needed to be hashed along with the message). Well, unless you want to > have a big monolithic application which can pass hash contexts around. So, why is the micalg parameter a MUST? --Kazu From owner-ietf-openpgp@mail.imc.org Fri Jan 25 09:11:35 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03105 for ; Fri, 25 Jan 2002 09:11:35 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PDvID04205 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:57:18 -0800 (PST) Received: from slipsten.extundo.com ([195.42.214.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDvF304201 for ; Fri, 25 Jan 2002 05:57:16 -0800 (PST) Received: (from jas@localhost) by slipsten.extundo.com (8.11.6/8.11.6) id g0PDvBX15845; Fri, 25 Jan 2002 14:57:11 +0100 From: Simon Josefsson To: James M Galvin Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: Date: Fri, 25 Jan 2002 14:57:11 +0100 In-Reply-To: (James M Galvin's message of "Thu, 24 Jan 2002 20:17:12 -0500 (EST)") Message-ID: Lines: 65 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu) 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: James M Galvin writes: > I believe it is the design of RFC 1847 that makes interoperability > low. > > In what way? Please explain. Here are some of my issues with RFC 1847. I'm not sure a simple revision of RFC 1847 can fix them, but I hope this is of some use during the revision of the document at least. Some of these aren't really technical arguments, but rather rooted in implementation and operational experience. * Assumes that MIME delimiters are immutable. In practice, MIME delimiters are changed in transit. I haven't found anything that explicitly forbids this in MIME, and the design of MIME sort of suggests that decoding and re-encoding the document is OK. Some IMAP servers are designed around this assumption, and I can't say that I blame them. * RFC 1847 assumes that applications have access to the raw transmitted MIME blob, rather than a MIME decoded object. Some mail access protocols, such as IMAP, can decode and split structured MIME objects. * It does not say that multipart/{signed,encrypted} parts (including MIME delimiters) MUST be preserved as-is when MUAs forward them using e.g. message/rfc822. Perhaps it is the odd one out, but the "forward" function in Gnus decodes MIME messages by default, to be able to display them properly in the message editing buffer, and later re-encodes the message. * Not the fault of RFC 1847, but some MIME applications does not follow the MIME recommendation to treat unknown multipart/foo types as multipart/mixed. So the parts are trashed, filtered, or marked as "viruses" or something. This is a implementation problem, but if a protocol can make implementation problems less likely to happen, this should be considered in the design of the protocol IMHO. * The MICALG parameter should be made optional. For some security infrastructures, it isn't applicable. For OpenPGP, it is not clear if the MICALG or the field inside the PGP signature blob should be used. Some mailers (Mutt) have been sending MD5 in the MICALG field and MIC:ing the message with SHA1. Perhaps illustrating is to consider an alternative approach of marrying mail security and MIME: The MIME structure is left as-is, and the body part is altered to include a "security" blob. This path is chosen by some Outlook PGP plugins (surely because the Outlook API is limited, and not by design, I am sure), and in my experience it works better than PGP/MIME -- legacy applications doesn't destroy the security blob and MIME aware message protocols are able to to retrieve just one MIME part and have it be verified/decrypted, everything else being equal. This solution is probably a bit against the spirit of MIME (the Content-Type header should be the sole specifier of how to treat a MIME body), so I'm not seriously advocating it as a standard, but it could be useful to compare the two approaches. One way to make this somewhat more MIME friendly would to add a MIME Content-Type parameter "signed=pgp" on a part that has undergone PGP treatment (and leaving the Content-Type to text/plain, application/msword etc as is). From owner-ietf-openpgp@mail.imc.org Fri Jan 25 09:26:42 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03473 for ; Fri, 25 Jan 2002 09:26:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PE7TL04498 for ietf-openpgp-bks; Fri, 25 Jan 2002 06:07:29 -0800 (PST) Received: from slipsten.extundo.com ([195.42.214.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PE7Q304494 for ; Fri, 25 Jan 2002 06:07:27 -0800 (PST) Received: (from jas@localhost) by slipsten.extundo.com (8.11.6/8.11.6) id g0PE7LT15859; Fri, 25 Jan 2002 15:07:21 +0100 From: Simon Josefsson To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020125.212537.125101827.kazu@iijlab.net> <87u1tapo6d.fsf@alberti.gnupg.de> Date: Fri, 25 Jan 2002 15:07:21 +0100 In-Reply-To: <87u1tapo6d.fsf@alberti.gnupg.de> (Werner Koch's message of "Fri, 25 Jan 2002 14:15:06 +0100") Message-ID: Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: >> (3) It's not clear how a receiving MUA should do when the value of >> the micalg parameter is differnt from the value specified in the >> second part(e.g a PGP packet for PGP/MIME). > > For PGP just ignore it. It does not make sense because you can't just > feed the hash into a OpenPGP verifier (there are other informations > needed to be hashed along with the message). This view isn't consistent with how I read RFC 3156, it seems to require that applications populate the field with the MIC algorithm used to hash the message. Using the wrong micalg value causes problems. IMHO either the micalg parameter should be made optional, or the PGP/MIME spec should suggest using a dummy value ("micalg=pgp") to signal to the application that the algorithm specified in the OpenPGP blob should be used. From owner-ietf-openpgp@mail.imc.org Fri Jan 25 09:36:00 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03760 for ; Fri, 25 Jan 2002 09:36:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PEMIU05064 for ietf-openpgp-bks; Fri, 25 Jan 2002 06:22:18 -0800 (PST) Received: from uranus.telemach.com (ns.interscope.ro [193.226.188.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PEMB305059 for ; Fri, 25 Jan 2002 06:22:13 -0800 (PST) Subject: Please help me! I'm new with OpenPGP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 25 Jan 2002 16:22:04 +0200 Message-ID: Thread-Topic: Please help me! I'm new with OpenPGP Thread-Index: AcGlq71o7f5K/ER5QcyZ8XJv2NxkZw== From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0PEMI305060 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi! I'm new in OpenPGP domain. First of all I would like to know if tis mailing list is still functionally because the last message was posted in 18 Jan 2000. Thank you in advance, Cornel Gligan-Ignatescu From owner-ietf-openpgp@mail.imc.org Fri Jan 25 12:27:53 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08175 for ; Fri, 25 Jan 2002 12:27:52 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PH7c613867 for ietf-openpgp-bks; Fri, 25 Jan 2002 09:07:38 -0800 (PST) Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PH7b313863 for ; Fri, 25 Jan 2002 09:07:37 -0800 (PST) Received: from knotes.kodak.com (knotes2.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g0PH7ZC28702 for ; Fri, 25 Jan 2002 12:07:35 -0500 (EST) Subject: Re: OpenPGP vs. OpenPGP/MIME To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Fri, 25 Jan 2002 11:07:24 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 01/25/2002 12:07:31 PM 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: From: John Dlugosz Re compatibility: I use (don't laugh) Lotus Notes 4.5 at work, and it is totally different from normal email. It has a gateway to translate internet mail into its own document format. Mime attachments are turned into embedded documents at the end. What would it do to PGP/MIME or any other use of MIME that requires knowing the =meaning= of the parts? I doubt it would work. Regular old-fashond ASCII Armored PGP works fine. With the GUI tools from NAI, it's pretty simple to use via the clipboard even though L.N. is totally unaware of it. If the main point of PGP/MIME was to get mail readers to transparantly handle PGP, it obviously has problems for readers that =don't=. And mail readers could just as easily be built to know about the ===BEGIN...=== lines. Just to throw something out, how about ASCII-Armored PGP for the body of the message, and MIME attachments for multiple (paralell) signatures? For that matter, they wouldn't need MIME, just another ASCII Armor'ed block following the main one. --John From owner-ietf-openpgp@mail.imc.org Fri Jan 25 13:14:18 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09758 for ; Fri, 25 Jan 2002 13:14:17 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PHtKw15433 for ietf-openpgp-bks; Fri, 25 Jan 2002 09:55:20 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PHtC315428 for ; Fri, 25 Jan 2002 09:55:13 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA24007; Fri, 25 Jan 2002 12:55:09 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA19753; Fri, 25 Jan 2002 12:55:07 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA07726; Fri, 25 Jan 2002 12:55:05 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA29767; Fri, 25 Jan 2002 12:55:04 -0500 (EST) To: Simon Josefsson Cc: Werner Koch , ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020125.212537.125101827.kazu@iijlab.net> <87u1tapo6d.fsf@alberti.gnupg.de> From: Derek Atkins Date: 25 Jan 2002 12:55:04 -0500 In-Reply-To: Message-ID: Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The point behind the micalg= parameter was for ease in implementation of a one-pass processing. If you know in advance to setup an md5 or sha1 hash processor, you can process the message through the hash before you get to the signature portion. At least that was why it was done originally, -derek Simon Josefsson writes: > Werner Koch writes: > > >> (3) It's not clear how a receiving MUA should do when the value of > >> the micalg parameter is differnt from the value specified in the > >> second part(e.g a PGP packet for PGP/MIME). > > > > For PGP just ignore it. It does not make sense because you can't just > > feed the hash into a OpenPGP verifier (there are other informations > > needed to be hashed along with the message). > > This view isn't consistent with how I read RFC 3156, it seems to > require that applications populate the field with the MIC algorithm > used to hash the message. Using the wrong micalg value causes > problems. > > IMHO either the micalg parameter should be made optional, or the > PGP/MIME spec should suggest using a dummy value ("micalg=pgp") to > signal to the application that the algorithm specified in the OpenPGP > blob should be used. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Fri Jan 25 14:30:43 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12038 for ; Fri, 25 Jan 2002 14:30:42 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PJIxS17595 for ietf-openpgp-bks; Fri, 25 Jan 2002 11:18:59 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PJIv317591 for ; Fri, 25 Jan 2002 11:18:58 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id EAA25179 for ; Sat, 26 Jan 2002 04:18:59 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id EAA11140 for ; Sat, 26 Jan 2002 04:18:58 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id EAA22694 for ; Sat, 26 Jan 2002 04:18:58 +0900 (JST) Date: Sat, 26 Jan 2002 04:20:16 +0900 (JST) Message-Id: <20020126.042016.68535928.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <87u1tapo6d.fsf@alberti.gnupg.de> X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Derek Atkins Subject: Re: OpenPGP vs. OpenPGP/MIME > The point behind the micalg= parameter was for ease in implementation > of a one-pass processing. If you know in advance to setup an md5 > or sha1 hash processor, you can process the message through the hash > before you get to the signature portion. I know. But who is using this feature actually? --Kazu From owner-ietf-openpgp@mail.imc.org Fri Jan 25 15:53:38 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14006 for ; Fri, 25 Jan 2002 15:53:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0PKcji19678 for ietf-openpgp-bks; Fri, 25 Jan 2002 12:38:45 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PKcg319674 for ; Fri, 25 Jan 2002 12:38:42 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24207; Fri, 25 Jan 2002 15:38:42 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA04600; Fri, 25 Jan 2002 15:38:40 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA06489; Fri, 25 Jan 2002 15:38:39 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id PAA19923; Fri, 25 Jan 2002 15:38:38 -0500 (EST) To: Kazu Yamamoto (=?iso-2022-jp?b?GyRCOzNLXE9CSScbKEI=?=) Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <87u1tapo6d.fsf@alberti.gnupg.de> <20020126.042016.68535928.kazu@iijlab.net> From: Derek Atkins Date: 25 Jan 2002 15:38:38 -0500 In-Reply-To: <20020126.042016.68535928.kazu@iijlab.net> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I dont know. I suspect that an integrated MIME parser with the PGPsdk _could_ use it, but I don't know if anyone does. -derek Kazu Yamamoto ($B;3K\OBI'(B) writes: > From: Derek Atkins > Subject: Re: OpenPGP vs. OpenPGP/MIME > > > The point behind the micalg= parameter was for ease in implementation > > of a one-pass processing. If you know in advance to setup an md5 > > or sha1 hash processor, you can process the message through the hash > > before you get to the signature portion. > > I know. But who is using this feature actually? > > --Kazu -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Sat Jan 26 05:57:33 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05148 for ; Sat, 26 Jan 2002 05:57:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0QAgFQ02771 for ietf-openpgp-bks; Sat, 26 Jan 2002 02:42:15 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0QAgC302763 for ; Sat, 26 Jan 2002 02:42:12 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16UQkB-0004zb-00; Sat, 26 Jan 2002 12:11:35 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16UQDs-00054M-00; Sat, 26 Jan 2002 11:38:12 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <87u1tapo6d.fsf@alberti.gnupg.de> <20020126.042016.68535928.kazu@iijlab.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Sat, 26 Jan 2002 11:38:11 +0100 In-Reply-To: <20020126.042016.68535928.kazu@iijlab.net> (Kazu Yamamoto's message of "Sat, 26 Jan 2002 04:20:16 +0900 (JST)") Message-ID: <874rl9gzxo.fsf@alberti.gnupg.de> Lines: 15 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sat, 26 Jan 2002 04:20:16 +0900 (JST), Kazu Yamamoto (³Ü§) said: > I know. But who is using this feature actually? For S/MIME it does really make sense as you don't need to pass a lengthly message to the S/MIME application. You can just pass the hash value. This is different from OpenPGP because S/MIME uses a 2-stage hashing method (in most cases). Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Mon Jan 28 06:16:25 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22157 for ; Mon, 28 Jan 2002 06:16:25 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SAaru18304 for ietf-openpgp-bks; Mon, 28 Jan 2002 02:36:53 -0800 (PST) Received: from uranus.telemach.com (ns.interscope.ro [193.226.188.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SAao318298 for ; Mon, 28 Jan 2002 02:36:51 -0800 (PST) Subject: Need help - public and private keys in OpenPGP format MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 28 Jan 2002 12:36:48 +0200 Message-ID: Thread-Topic: Need help - public and private keys in OpenPGP format Thread-Index: AcGn59NHpMfutbkySViurRGONEpuHw== From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0SAar318301 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi! I want to store a public key and a private key in OpenPGP format. Is there anyone who can give me some examples, or who can tell me where can I find some examples with this topic? (I work with Visual C++ 6.0 and Windows 2000) Tank you in advance, Cornel Gligan-Ignatescu From owner-ietf-openpgp@mail.imc.org Mon Jan 28 06:32:59 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22362 for ; Mon, 28 Jan 2002 06:32:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SB7ND21349 for ietf-openpgp-bks; Mon, 28 Jan 2002 03:07:23 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SB7M321341 for ; Mon, 28 Jan 2002 03:07:22 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA25433 for ; Mon, 28 Jan 2002 20:07:18 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA20831 for ; Mon, 28 Jan 2002 20:07:18 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA03204 for ; Mon, 28 Jan 2002 20:07:18 +0900 (JST) Date: Mon, 28 Jan 2002 20:08:37 +0900 (JST) Message-Id: <20020128.200837.46608363.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <874rl9gzxo.fsf@alberti.gnupg.de> References: <20020126.042016.68535928.kazu@iijlab.net> <874rl9gzxo.fsf@alberti.gnupg.de> X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Werner From: Werner Koch Subject: Re: OpenPGP vs. OpenPGP/MIME > For S/MIME it does really make sense as you don't need to pass a > lengthly message to the S/MIME application. You can just pass the > hash value. This is different from OpenPGP because S/MIME uses a > 2-stage hashing method (in most cases). I don't understand this. I think you are talking about verification, not creating a signature. Would you tell me how the micalg parameter is useful for S/MIME application on verification more concretely? Probably I should understand what 2-stage hashing method is. --Kazu From owner-ietf-openpgp@mail.imc.org Mon Jan 28 07:38:05 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23146 for ; Mon, 28 Jan 2002 07:38:05 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g0SCAQ526276 for ietf-openpgp-bks; Mon, 28 Jan 2002 04:10:26 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SCAM326265 for ; Mon, 28 Jan 2002 04:10:22 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16VB4x-0006Jc-00; Mon, 28 Jan 2002 13:40:07 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16VAZp-0001la-00; Mon, 28 Jan 2002 13:07:57 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020126.042016.68535928.kazu@iijlab.net> <874rl9gzxo.fsf@alberti.gnupg.de> <20020128.200837.46608363.kazu@iijlab.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Mon, 28 Jan 2002 13:07:56 +0100 In-Reply-To: <20020128.200837.46608363.kazu@iijlab.net> (Kazu Yamamoto's message of "Mon, 28 Jan 2002 20:08:37 +0900 (JST)") Message-ID: <871ygael0j.fsf@alberti.gnupg.de> Lines: 31 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Mon, 28 Jan 2002 20:08:37 +0900 (JST), Kazu Yamamoto (³Ü§) said: > I don't understand this. I think you are talking about verification, > not creating a signature. Right. When you create a signature, you know in advance what hash algorithm to use. > Would you tell me how the micalg parameter is useful for S/MIME > application on verification more concretely? Probably I should > understand what 2-stage hashing method is. S/MIME usually hashes the text and store the hash value inside the so called signedAttributes. The signedAttributes, which are usually small and contain various things like the signature creation time, are then hashed again and that value is the input to the PK verification algorithm. OpenPGP hashes everything as one big block. The problem is that you can't feed the hash value to OpenPGP because it is not possible to hash more stuff after a hash as been finalized (i.e. the hash value calculated) - well it would be possible to use the intermediate values (the hash context) to the verification process, so that it can hash more data in, but I don't consider this a clean design. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0SCAQ526276 for ietf-openpgp-bks; Mon, 28 Jan 2002 04:10:26 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SCAM326265 for ; Mon, 28 Jan 2002 04:10:22 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16VB4x-0006Jc-00; Mon, 28 Jan 2002 13:40:07 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16VAZp-0001la-00; Mon, 28 Jan 2002 13:07:57 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020126.042016.68535928.kazu@iijlab.net> <874rl9gzxo.fsf@alberti.gnupg.de> <20020128.200837.46608363.kazu@iijlab.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Mon, 28 Jan 2002 13:07:56 +0100 In-Reply-To: <20020128.200837.46608363.kazu@iijlab.net> (Kazu Yamamoto's message of "Mon, 28 Jan 2002 20:08:37 +0900 (JST)") Message-ID: <871ygael0j.fsf@alberti.gnupg.de> Lines: 31 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 28 Jan 2002 20:08:37 +0900 (JST), Kazu Yamamoto (³Ü§) said: > I don't understand this. I think you are talking about verification, > not creating a signature. Right. When you create a signature, you know in advance what hash algorithm to use. > Would you tell me how the micalg parameter is useful for S/MIME > application on verification more concretely? Probably I should > understand what 2-stage hashing method is. S/MIME usually hashes the text and store the hash value inside the so called signedAttributes. The signedAttributes, which are usually small and contain various things like the signature creation time, are then hashed again and that value is the input to the PK verification algorithm. OpenPGP hashes everything as one big block. The problem is that you can't feed the hash value to OpenPGP because it is not possible to hash more stuff after a hash as been finalized (i.e. the hash value calculated) - well it would be possible to use the intermediate values (the hash context) to the verification process, so that it can hash more data in, but I don't consider this a clean design. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SB7ND21349 for ietf-openpgp-bks; Mon, 28 Jan 2002 03:07:23 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SB7M321341 for ; Mon, 28 Jan 2002 03:07:22 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA25433 for ; Mon, 28 Jan 2002 20:07:18 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA20831 for ; Mon, 28 Jan 2002 20:07:18 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA03204 for ; Mon, 28 Jan 2002 20:07:18 +0900 (JST) Date: Mon, 28 Jan 2002 20:08:37 +0900 (JST) Message-Id: <20020128.200837.46608363.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <874rl9gzxo.fsf@alberti.gnupg.de> References: <20020126.042016.68535928.kazu@iijlab.net> <874rl9gzxo.fsf@alberti.gnupg.de> X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner From: Werner Koch Subject: Re: OpenPGP vs. OpenPGP/MIME > For S/MIME it does really make sense as you don't need to pass a > lengthly message to the S/MIME application. You can just pass the > hash value. This is different from OpenPGP because S/MIME uses a > 2-stage hashing method (in most cases). I don't understand this. I think you are talking about verification, not creating a signature. Would you tell me how the micalg parameter is useful for S/MIME application on verification more concretely? Probably I should understand what 2-stage hashing method is. --Kazu Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SAaru18304 for ietf-openpgp-bks; Mon, 28 Jan 2002 02:36:53 -0800 (PST) Received: from uranus.telemach.com (ns.interscope.ro [193.226.188.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SAao318298 for ; Mon, 28 Jan 2002 02:36:51 -0800 (PST) Subject: Need help - public and private keys in OpenPGP format MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Mon, 28 Jan 2002 12:36:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need help - public and private keys in OpenPGP format Thread-Index: AcGn59NHpMfutbkySViurRGONEpuHw== From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0SAar318301 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! I want to store a public key and a private key in OpenPGP format. Is there anyone who can give me some examples, or who can tell me where can I find some examples with this topic? (I work with Visual C++ 6.0 and Windows 2000) Tank you in advance, Cornel Gligan-Ignatescu Received: by above.proper.com (8.11.6/8.11.3) id g0QAgFQ02771 for ietf-openpgp-bks; Sat, 26 Jan 2002 02:42:15 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0QAgC302763 for ; Sat, 26 Jan 2002 02:42:12 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16UQkB-0004zb-00; Sat, 26 Jan 2002 12:11:35 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16UQDs-00054M-00; Sat, 26 Jan 2002 11:38:12 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <87u1tapo6d.fsf@alberti.gnupg.de> <20020126.042016.68535928.kazu@iijlab.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Sat, 26 Jan 2002 11:38:11 +0100 In-Reply-To: <20020126.042016.68535928.kazu@iijlab.net> (Kazu Yamamoto's message of "Sat, 26 Jan 2002 04:20:16 +0900 (JST)") Message-ID: <874rl9gzxo.fsf@alberti.gnupg.de> Lines: 15 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 26 Jan 2002 04:20:16 +0900 (JST), Kazu Yamamoto (³Ü§) said: > I know. But who is using this feature actually? For S/MIME it does really make sense as you don't need to pass a lengthly message to the S/MIME application. You can just pass the hash value. This is different from OpenPGP because S/MIME uses a 2-stage hashing method (in most cases). Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0PKcji19678 for ietf-openpgp-bks; Fri, 25 Jan 2002 12:38:45 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PKcg319674 for ; Fri, 25 Jan 2002 12:38:42 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24207; Fri, 25 Jan 2002 15:38:42 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA04600; Fri, 25 Jan 2002 15:38:40 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA06489; Fri, 25 Jan 2002 15:38:39 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id PAA19923; Fri, 25 Jan 2002 15:38:38 -0500 (EST) To: Kazu Yamamoto (=?iso-2022-jp?b?GyRCOzNLXE9CSScbKEI=?=) Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <87u1tapo6d.fsf@alberti.gnupg.de> <20020126.042016.68535928.kazu@iijlab.net> From: Derek Atkins Date: 25 Jan 2002 15:38:38 -0500 In-Reply-To: <20020126.042016.68535928.kazu@iijlab.net> Message-ID: Lines: 24 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I dont know. I suspect that an integrated MIME parser with the PGPsdk _could_ use it, but I don't know if anyone does. -derek Kazu Yamamoto ($B;3K\OBI'(B) writes: > From: Derek Atkins > Subject: Re: OpenPGP vs. OpenPGP/MIME > > > The point behind the micalg= parameter was for ease in implementation > > of a one-pass processing. If you know in advance to setup an md5 > > or sha1 hash processor, you can process the message through the hash > > before you get to the signature portion. > > I know. But who is using this feature actually? > > --Kazu -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: by above.proper.com (8.11.6/8.11.3) id g0PJIxS17595 for ietf-openpgp-bks; Fri, 25 Jan 2002 11:18:59 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PJIv317591 for ; Fri, 25 Jan 2002 11:18:58 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id EAA25179 for ; Sat, 26 Jan 2002 04:18:59 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id EAA11140 for ; Sat, 26 Jan 2002 04:18:58 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id EAA22694 for ; Sat, 26 Jan 2002 04:18:58 +0900 (JST) Date: Sat, 26 Jan 2002 04:20:16 +0900 (JST) Message-Id: <20020126.042016.68535928.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <87u1tapo6d.fsf@alberti.gnupg.de> X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Derek Atkins Subject: Re: OpenPGP vs. OpenPGP/MIME > The point behind the micalg= parameter was for ease in implementation > of a one-pass processing. If you know in advance to setup an md5 > or sha1 hash processor, you can process the message through the hash > before you get to the signature portion. I know. But who is using this feature actually? --Kazu Received: by above.proper.com (8.11.6/8.11.3) id g0PHtKw15433 for ietf-openpgp-bks; Fri, 25 Jan 2002 09:55:20 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PHtC315428 for ; Fri, 25 Jan 2002 09:55:13 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA24007; Fri, 25 Jan 2002 12:55:09 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA19753; Fri, 25 Jan 2002 12:55:07 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA07726; Fri, 25 Jan 2002 12:55:05 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA29767; Fri, 25 Jan 2002 12:55:04 -0500 (EST) To: Simon Josefsson Cc: Werner Koch , ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020125.212537.125101827.kazu@iijlab.net> <87u1tapo6d.fsf@alberti.gnupg.de> From: Derek Atkins Date: 25 Jan 2002 12:55:04 -0500 In-Reply-To: Message-ID: Lines: 36 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The point behind the micalg= parameter was for ease in implementation of a one-pass processing. If you know in advance to setup an md5 or sha1 hash processor, you can process the message through the hash before you get to the signature portion. At least that was why it was done originally, -derek Simon Josefsson writes: > Werner Koch writes: > > >> (3) It's not clear how a receiving MUA should do when the value of > >> the micalg parameter is differnt from the value specified in the > >> second part(e.g a PGP packet for PGP/MIME). > > > > For PGP just ignore it. It does not make sense because you can't just > > feed the hash into a OpenPGP verifier (there are other informations > > needed to be hashed along with the message). > > This view isn't consistent with how I read RFC 3156, it seems to > require that applications populate the field with the MIC algorithm > used to hash the message. Using the wrong micalg value causes > problems. > > IMHO either the micalg parameter should be made optional, or the > PGP/MIME spec should suggest using a dummy value ("micalg=pgp") to > signal to the application that the algorithm specified in the OpenPGP > blob should be used. -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: by above.proper.com (8.11.6/8.11.3) id g0PH7c613867 for ietf-openpgp-bks; Fri, 25 Jan 2002 09:07:38 -0800 (PST) Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PH7b313863 for ; Fri, 25 Jan 2002 09:07:37 -0800 (PST) Received: from knotes.kodak.com (knotes2.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g0PH7ZC28702 for ; Fri, 25 Jan 2002 12:07:35 -0500 (EST) Subject: Re: OpenPGP vs. OpenPGP/MIME To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Fri, 25 Jan 2002 11:07:24 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 01/25/2002 12:07:31 PM 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: From: John Dlugosz Re compatibility: I use (don't laugh) Lotus Notes 4.5 at work, and it is totally different from normal email. It has a gateway to translate internet mail into its own document format. Mime attachments are turned into embedded documents at the end. What would it do to PGP/MIME or any other use of MIME that requires knowing the =meaning= of the parts? I doubt it would work. Regular old-fashond ASCII Armored PGP works fine. With the GUI tools from NAI, it's pretty simple to use via the clipboard even though L.N. is totally unaware of it. If the main point of PGP/MIME was to get mail readers to transparantly handle PGP, it obviously has problems for readers that =don't=. And mail readers could just as easily be built to know about the ===BEGIN...=== lines. Just to throw something out, how about ASCII-Armored PGP for the body of the message, and MIME attachments for multiple (paralell) signatures? For that matter, they wouldn't need MIME, just another ASCII Armor'ed block following the main one. --John Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PEMIU05064 for ietf-openpgp-bks; Fri, 25 Jan 2002 06:22:18 -0800 (PST) Received: from uranus.telemach.com (ns.interscope.ro [193.226.188.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PEMB305059 for ; Fri, 25 Jan 2002 06:22:13 -0800 (PST) Subject: Please help me! I'm new with OpenPGP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Fri, 25 Jan 2002 16:22:04 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please help me! I'm new with OpenPGP Thread-Index: AcGlq71o7f5K/ER5QcyZ8XJv2NxkZw== From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0PEMI305060 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! I'm new in OpenPGP domain. First of all I would like to know if tis mailing list is still functionally because the last message was posted in 18 Jan 2000. Thank you in advance, Cornel Gligan-Ignatescu Received: by above.proper.com (8.11.6/8.11.3) id g0PE7TL04498 for ietf-openpgp-bks; Fri, 25 Jan 2002 06:07:29 -0800 (PST) Received: from slipsten.extundo.com ([195.42.214.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PE7Q304494 for ; Fri, 25 Jan 2002 06:07:27 -0800 (PST) Received: (from jas@localhost) by slipsten.extundo.com (8.11.6/8.11.6) id g0PE7LT15859; Fri, 25 Jan 2002 15:07:21 +0100 From: Simon Josefsson To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020125.212537.125101827.kazu@iijlab.net> <87u1tapo6d.fsf@alberti.gnupg.de> Date: Fri, 25 Jan 2002 15:07:21 +0100 In-Reply-To: <87u1tapo6d.fsf@alberti.gnupg.de> (Werner Koch's message of "Fri, 25 Jan 2002 14:15:06 +0100") Message-ID: Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: >> (3) It's not clear how a receiving MUA should do when the value of >> the micalg parameter is differnt from the value specified in the >> second part(e.g a PGP packet for PGP/MIME). > > For PGP just ignore it. It does not make sense because you can't just > feed the hash into a OpenPGP verifier (there are other informations > needed to be hashed along with the message). This view isn't consistent with how I read RFC 3156, it seems to require that applications populate the field with the MIC algorithm used to hash the message. Using the wrong micalg value causes problems. IMHO either the micalg parameter should be made optional, or the PGP/MIME spec should suggest using a dummy value ("micalg=pgp") to signal to the application that the algorithm specified in the OpenPGP blob should be used. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PDvID04205 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:57:18 -0800 (PST) Received: from slipsten.extundo.com ([195.42.214.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDvF304201 for ; Fri, 25 Jan 2002 05:57:16 -0800 (PST) Received: (from jas@localhost) by slipsten.extundo.com (8.11.6/8.11.6) id g0PDvBX15845; Fri, 25 Jan 2002 14:57:11 +0100 From: Simon Josefsson To: James M Galvin Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: Date: Fri, 25 Jan 2002 14:57:11 +0100 In-Reply-To: (James M Galvin's message of "Thu, 24 Jan 2002 20:17:12 -0500 (EST)") Message-ID: Lines: 65 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu) 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: James M Galvin writes: > I believe it is the design of RFC 1847 that makes interoperability > low. > > In what way? Please explain. Here are some of my issues with RFC 1847. I'm not sure a simple revision of RFC 1847 can fix them, but I hope this is of some use during the revision of the document at least. Some of these aren't really technical arguments, but rather rooted in implementation and operational experience. * Assumes that MIME delimiters are immutable. In practice, MIME delimiters are changed in transit. I haven't found anything that explicitly forbids this in MIME, and the design of MIME sort of suggests that decoding and re-encoding the document is OK. Some IMAP servers are designed around this assumption, and I can't say that I blame them. * RFC 1847 assumes that applications have access to the raw transmitted MIME blob, rather than a MIME decoded object. Some mail access protocols, such as IMAP, can decode and split structured MIME objects. * It does not say that multipart/{signed,encrypted} parts (including MIME delimiters) MUST be preserved as-is when MUAs forward them using e.g. message/rfc822. Perhaps it is the odd one out, but the "forward" function in Gnus decodes MIME messages by default, to be able to display them properly in the message editing buffer, and later re-encodes the message. * Not the fault of RFC 1847, but some MIME applications does not follow the MIME recommendation to treat unknown multipart/foo types as multipart/mixed. So the parts are trashed, filtered, or marked as "viruses" or something. This is a implementation problem, but if a protocol can make implementation problems less likely to happen, this should be considered in the design of the protocol IMHO. * The MICALG parameter should be made optional. For some security infrastructures, it isn't applicable. For OpenPGP, it is not clear if the MICALG or the field inside the PGP signature blob should be used. Some mailers (Mutt) have been sending MD5 in the MICALG field and MIC:ing the message with SHA1. Perhaps illustrating is to consider an alternative approach of marrying mail security and MIME: The MIME structure is left as-is, and the body part is altered to include a "security" blob. This path is chosen by some Outlook PGP plugins (surely because the Outlook API is limited, and not by design, I am sure), and in my experience it works better than PGP/MIME -- legacy applications doesn't destroy the security blob and MIME aware message protocols are able to to retrieve just one MIME part and have it be verified/decrypted, everything else being equal. This solution is probably a bit against the spirit of MIME (the Content-Type header should be the sole specifier of how to treat a MIME body), so I'm not seriously advocating it as a standard, but it could be useful to compare the two approaches. One way to make this somewhat more MIME friendly would to add a MIME Content-Type parameter "signed=pgp" on a part that has undergone PGP treatment (and leaving the Content-Type to text/plain, application/msword etc as is). Received: by above.proper.com (8.11.6/8.11.3) id g0PDqLK04054 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:52:21 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDqJ304049 for ; Fri, 25 Jan 2002 05:52:20 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id WAA27492 for ; Fri, 25 Jan 2002 22:52:20 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA01587 for ; Fri, 25 Jan 2002 22:52:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id WAA16831 for ; Fri, 25 Jan 2002 22:52:19 +0900 (JST) Date: Fri, 25 Jan 2002 22:53:37 +0900 (JST) Message-Id: <20020125.225337.68541953.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: <87u1tapo6d.fsf@alberti.gnupg.de> References: <20020125.212537.125101827.kazu@iijlab.net> <87u1tapo6d.fsf@alberti.gnupg.de> X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: OpenPGP vs. OpenPGP/MIME > > (2) It's not clear how a receiving MUA should do when the value of the > > protocol parameter is different from the value of content type (of > > the first part for encryption and of the second part for > > How an error is handled is not in the scope of most protocols. Do > whatever you see fits. I understand what you mean. And I agree with you in many cases. However, RFC 1847 is to define a signature service. If error handing is implementation dependent, a broken multipart/security is verified as GOOD in some MUAs and it is verified as BAD in other MUAs. This is not good for signature services. > > (3) It's not clear how a receiving MUA should do when the value of > > the micalg parameter is differnt from the value specified in the > > second part(e.g a PGP packet for PGP/MIME). > > For PGP just ignore it. It does not make sense because you can't just > feed the hash into a OpenPGP verifier (there are other informations > needed to be hashed along with the message). Well, unless you want to > have a big monolithic application which can pass hash contexts around. So, why is the micalg parameter a MUST? --Kazu Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PDITh03040 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:18:29 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDIQ303036 for ; Fri, 25 Jan 2002 05:18:26 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16U6hY-0004Jb-00; Fri, 25 Jan 2002 14:47:32 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16U6CB-0003vc-00; Fri, 25 Jan 2002 14:15:07 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020125.212537.125101827.kazu@iijlab.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Fri, 25 Jan 2002 14:15:06 +0100 In-Reply-To: <20020125.212537.125101827.kazu@iijlab.net> (Kazu Yamamoto's message of "Fri, 25 Jan 2002 21:25:37 +0900 (JST)") Message-ID: <87u1tapo6d.fsf@alberti.gnupg.de> Lines: 25 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 25 Jan 2002 21:25:37 +0900 (JST), Kazu Yamamoto (³Ü§) said: > (2) It's not clear how a receiving MUA should do when the value of the > protocol parameter is different from the value of content type (of > the first part for encryption and of the second part for How an error is handled is not in the scope of most protocols. Do whatever you see fits. Issue a warning so that such errors don't get unnoticed. > (3) It's not clear how a receiving MUA should do when the value of > the micalg parameter is differnt from the value specified in the > second part(e.g a PGP packet for PGP/MIME). For PGP just ignore it. It does not make sense because you can't just feed the hash into a OpenPGP verifier (there are other informations needed to be hashed along with the message). Well, unless you want to have a big monolithic application which can pass hash contexts around. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0PDAA702480 for ietf-openpgp-bks; Fri, 25 Jan 2002 05:10:10 -0800 (PST) Received: from slipsten.extundo.com ([195.42.214.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PDA7302476 for ; Fri, 25 Jan 2002 05:10:07 -0800 (PST) Received: (from jas@localhost) by slipsten.extundo.com (8.11.6/8.11.6) id g0PD9s215837; Fri, 25 Jan 2002 14:09:54 +0100 From: Simon Josefsson To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020124214534.GA677@akamai.com> <20020124224603.GA3429@sobolev.does-not-exist.org> Date: Fri, 25 Jan 2002 14:09:54 +0100 In-Reply-To: <20020124224603.GA3429@sobolev.does-not-exist.org> (Thomas Roessler's message of "Thu, 24 Jan 2002 23:46:03 +0100") Message-ID: Lines: 21 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (i386-redhat-linux-gnu) 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: Thomas Roessler writes: >> I agree with Jon's opinion. PGP/MIME interoperability is bad. > > Really? It certainly won't get worse than MIME interoperability in > general. MIME interop isn't very good, when you beyond the simple features. As an example, my mail server filter multipart/signed. I have no idea why, and of course it is a bug, but the point is that for some reason the deployment of PGP/MIME failed here. >> I believe it is the design of RFC 1847 that makes interoperability >> low. I'm even considering arguing for the solution chosen by Outlook >> PGP plugins when it comes to PGP and MIME, just PGP encrypt each >> MIME part without touching the MIME headers at all. > > Funny enough, S/MIME uses RFC 1847 as well, and that one works. S/MIME doesn't use RFC 1847 for encrypting messages, and S/MIME allows non-RFC 1847 mechanisms when it comes to signed messages as well. Received: by above.proper.com (8.11.6/8.11.3) id g0PCOQT27953 for ietf-openpgp-bks; Fri, 25 Jan 2002 04:24:26 -0800 (PST) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PCOO327949 for ; Fri, 25 Jan 2002 04:24:24 -0800 (PST) Received: from ns.iij.ad.jp (ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA18723; Fri, 25 Jan 2002 21:24:19 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA24532; Fri, 25 Jan 2002 21:24:19 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA09421; Fri, 25 Jan 2002 21:24:19 +0900 (JST) Date: Fri, 25 Jan 2002 21:25:37 +0900 (JST) Message-Id: <20020125.212537.125101827.kazu@iijlab.net> To: galvin@acm.org, ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: X-Mailer: Mew version 3.0.52 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: James M Galvin Subject: Re: OpenPGP vs. OpenPGP/MIME > I > believe it is the design of RFC 1847 that makes interoperability > low. > > In what way? Please explain. I think RFC 1847 has several ambiguities: (1) It's not clear whether or not the protocol parameter is case-sensitive. The parameter indicates content type, which is case-insensitive, of a second part. However, the parameter is case-sensitive because RFC 1847 does not mention this explicitly. (2) It's not clear how a receiving MUA should do when the value of the protocol parameter is different from the value of content type (of the first part for encryption and of the second part for signature.) (3) It's not clear how a receiving MUA should do when the value of the micalg parameter is differnt from the value specified in the second part(e.g a PGP packet for PGP/MIME). > co-Author of RFC1847 (for which a revision is in progress) Good news. Where can I find the draft? --Kazu Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P1MV114064 for ietf-openpgp-bks; Thu, 24 Jan 2002 17:22:31 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0P1MU314059 for ; Thu, 24 Jan 2002 17:22:30 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g0P1MSc08889 for ietf-openpgp@imc.org; Thu, 24 Jan 2002 20:22:28 -0500 Date: Thu, 24 Jan 2002 20:22:28 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020125012228.GA8870@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020124214534.GA677@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Gibbous (81% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 24, 2002 at 11:38:13PM +0100, Simon Josefsson wrote: > > David Shaw writes: > > > I stopped using it when I found myself in a corporate environment > > where the majority of people were using various corporate mailers that > > blew up in various odd ways with it. I'm sure this isn't a PGP/MIME > > thing - they'd have blown up with any MIME they didn't understand, but > > while a regular clearsigned signature can be ignored by those people > > that either don't care or don't use PGP, a PGP/MIME message does not > > always degrade quite so gracefully. > > I think you just pretty well described what Jon meant by PGP/MIME > often not working in practice, whereas OpenPGP usually does work. Exactly. I was agreeing with Jon as well (did I accidentally say OpenPGP somewhere where I meant PGP/MIME or vice versa?) In my experience, MIME in general except for two cases too frequently does "interesting" things. Those two good cases are a) the really common stuff (attaching a file and forwarding an email, possibly with its own attachments), and b) the stuff the vendor provides, and therefore tests (S/MIME, etc.) David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P1EXp13659 for ietf-openpgp-bks; Thu, 24 Jan 2002 17:14:33 -0800 (PST) Received: from one.elistx.com (one.elistx.com [209.116.252.130]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0P1EW313655 for ; Thu, 24 Jan 2002 17:14:32 -0800 (PST) Received: from two.elistx.com (two.elistx.com [209.116.254.209]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GQG00E84ZL11G@eListX.com> for ietf-openpgp@imc.org; Thu, 24 Jan 2002 20:17:25 -0500 (EST) Date: Thu, 24 Jan 2002 20:17:12 -0500 (EST) From: James M Galvin Subject: Re: OpenPGP vs. OpenPGP/MIME In-reply-to: X-X-Sender: galvin@two.elistx.com To: Simon Josefsson Cc: ietf-openpgp@imc.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 24 Jan 2002, Simon Josefsson wrote: I believe it is the design of RFC 1847 that makes interoperability low. In what way? Please explain. Jim co-Author of RFC1847 (for which a revision is in progress) -- James M. Galvin Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0P0qbL12590 for ietf-openpgp-bks; Thu, 24 Jan 2002 16:52:37 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0P0qa312585 for ; Thu, 24 Jan 2002 16:52:36 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Thu, 24 Jan 2002 16:52:34 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20020124224603.GA3429@sobolev.does-not-exist.org> References: <20020124214534.GA677@akamai.com> <20020124224603.GA3429@sobolev.does-not-exist.org> Date: Thu, 24 Jan 2002 16:48:32 -0800 To: Thomas Roessler , Simon Josefsson From: Jon Callas Subject: Re: OpenPGP vs. OpenPGP/MIME Cc: ietf-openpgp@imc.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:46 PM +0100 1/24/02, Thomas Roessler wrote: >On 2002-01-24 23:38:13 +0100, Simon Josefsson wrote: > >>I agree with Jon's opinion. PGP/MIME interoperability is bad. > >Really? It certainly won't get worse than MIME interoperability in >general. > That is precisely my point. It's not a PGP problem, it's a MIME problem. Which means that PGP/MIME is a good thing in theory, but not in practice. Once MIME interoperability starts working, more power to it. >>I believe it is the design of RFC 1847 that makes interoperability >>low. I'm even considering arguing for the solution chosen by >>Outlook PGP plugins when it comes to PGP and MIME, just PGP >>encrypt each MIME part without touching the MIME headers at all. > >Funny enough, S/MIME uses RFC 1847 as well, and that one works. Funny enough, not I nor anyone I know has ever used S/MIME successfully. But I suspect that is cultural more than technical. Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ONE4U10648 for ietf-openpgp-bks; Thu, 24 Jan 2002 15:14:04 -0800 (PST) Received: from mail.mediacompany.com (postfix@castor.mediacompany.com [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ONE2310643 for ; Thu, 24 Jan 2002 15:14:02 -0800 (PST) Received: from sobolev.does-not-exist.org (unknown [62.144.244.136]) by mail.mediacompany.com (Postfix) with ESMTP id 0E1884805; Fri, 25 Jan 2002 00:13:50 +0100 (CET) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 8D8F02ED15; Thu, 24 Jan 2002 23:46:03 +0100 (CET) Date: Thu, 24 Jan 2002 23:46:03 +0100 From: Thomas Roessler To: Simon Josefsson Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020124224603.GA3429@sobolev.does-not-exist.org> Mail-Followup-To: Simon Josefsson , ietf-openpgp@imc.org References: <20020124214534.GA677@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-01-24 23:38:13 +0100, Simon Josefsson wrote: >I agree with Jon's opinion. PGP/MIME interoperability is bad. Really? It certainly won't get worse than MIME interoperability in general. >I believe it is the design of RFC 1847 that makes interoperability >low. I'm even considering arguing for the solution chosen by >Outlook PGP plugins when it comes to PGP and MIME, just PGP >encrypt each MIME part without touching the MIME headers at all. Funny enough, S/MIME uses RFC 1847 as well, and that one works. -- Thomas Roessler Received: by above.proper.com (8.11.6/8.11.3) id g0OMeeC10130 for ietf-openpgp-bks; Thu, 24 Jan 2002 14:40:40 -0800 (PST) Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OMeb310125 for ; Thu, 24 Jan 2002 14:40:38 -0800 (PST) Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.2/8.12.2) with ESMTP id g0OMe3HJ018979 for ; Thu, 24 Jan 2002 23:40:08 +0100 To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME References: <20020124214534.GA677@akamai.com> From: Simon Josefsson In-Reply-To: <20020124214534.GA677@akamai.com> (David Shaw's message of "Thu, 24 Jan 2002 16:45:34 -0500") Date: Thu, 24 Jan 2002 23:38:13 +0100 Message-ID: Lines: 19 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1.80 (i686-pc-linux-gnu) 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: David Shaw writes: > I stopped using it when I found myself in a corporate environment > where the majority of people were using various corporate mailers that > blew up in various odd ways with it. I'm sure this isn't a PGP/MIME > thing - they'd have blown up with any MIME they didn't understand, but > while a regular clearsigned signature can be ignored by those people > that either don't care or don't use PGP, a PGP/MIME message does not > always degrade quite so gracefully. I think you just pretty well described what Jon meant by PGP/MIME often not working in practice, whereas OpenPGP usually does work. I agree with Jon's opinion. PGP/MIME interoperability is bad. I believe it is the design of RFC 1847 that makes interoperability low. I'm even considering arguing for the solution chosen by Outlook PGP plugins when it comes to PGP and MIME, just PGP encrypt each MIME part without touching the MIME headers at all. That solution _works_, even though it is ugly and bad and wrong from a engineering point of view. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OLjXI09087 for ietf-openpgp-bks; Thu, 24 Jan 2002 13:45:33 -0800 (PST) Received: from claude.kendall.akamai.com (wirefire.akamai.com [65.202.32.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OLjW309083 for ; Thu, 24 Jan 2002 13:45:32 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g0OLjYx00919 for ietf-openpgp@imc.org; Thu, 24 Jan 2002 16:45:34 -0500 Date: Thu, 24 Jan 2002 16:45:34 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020124214534.GA677@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.26i X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waxing Gibbous (80% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jan 24, 2002 at 12:14:31PM -0800, Jon Callas wrote: > > Let me state off the bat that I'm taking off any official hat as > author/editor/expert I might have. This is my personal opinion as a > computer user who uses OpenPGP. > > I'm distressed by the opinion that I have heard (usually second or more > hand) that somehow base OpenPGP in 2440+ is deprecated, uncool, or > something, and that the way to go is OpnPGP/MIME. I think at least some of those opinions are based on section 2.4 in 2440bis: Note that many applications, particularly messaging applications, will want more advanced features as described in the OpenPGP-MIME document, RFC2015. An application that implements OpenPGP for messaging SHOULD implement OpenPGP-MIME. Statements like "many applications, ... will want more advanced..", and "SHOULD" imply (to my eye) "This is what I should use. The other way must not be as good, or the RFC wouldn't have told me I SHOULD use this." > MIME-coded messages have great uses. But alas, even to this day, there are > lots of uses of them that aren't quite ready for prime time. Let's face it > -- the majority of mailers don't do MIME correctly, and if I have to pry > apart attachments to get to a clearsigned signature just so I can > re-assemble the thing in a text editor so I can check the signature, I'm > probably not going to do it. I actually like PGP/MIME quite a lot - it handles painlessly a lot of fussy details that otherwise I'd have to handle. I stopped using it when I found myself in a corporate environment where the majority of people were using various corporate mailers that blew up in various odd ways with it. I'm sure this isn't a PGP/MIME thing - they'd have blown up with any MIME they didn't understand, but while a regular clearsigned signature can be ignored by those people that either don't care or don't use PGP, a PGP/MIME message does not always degrade quite so gracefully. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0OKEqM07674 for ietf-openpgp-bks; Thu, 24 Jan 2002 12:14:52 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OKEp307670 for ; Thu, 24 Jan 2002 12:14:51 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for ; Thu, 24 Jan 2002 12:14:48 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: Date: Thu, 24 Jan 2002 12:14:31 -0800 To: ietf-openpgp@imc.org From: Jon Callas Subject: OpenPGP vs. OpenPGP/MIME Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me state off the bat that I'm taking off any official hat as author/editor/expert I might have. This is my personal opinion as a computer user who uses OpenPGP. I'm distressed by the opinion that I have heard (usually second or more hand) that somehow base OpenPGP in 2440+ is deprecated, uncool, or something, and that the way to go is OpnPGP/MIME. I think this is patently ridiculous. Usually, the way to go is to use base OpenPGP, which for all its flaws, has one major advantage over all other cryptosystems that I've used, including OpenPGP/MIME. That advantage is this: It actually works. Nearly never do I fail to decrypt, verify, etc. an OpenPGP object, and when I do, the problem can be solved by ASCII armoring the output -- which means that the problem is implicit line-end translation that damages the binary. To repeat, this is not a philosophical objection. This is not because I have some horrid dislike for MIME. Well, all right, I do have a horrid dislike for MIME, but I have a horrid dislike for MIME solely because it doesn't work. I'm a practical person. I like any and all technologies that work without my fussing with them. If we waved a magic wand and these things started working, I wouldn't object. I would even start says, "Hey, MIME actually works." But they don't work, and I do dislike them for this lack. MIME does one thing well -- putting in files as attachments, and thus making email a convenient file transfer protocol. This almost always works. The further one strays from this basic function, the less reliable it is. Sending a message in HTML and MIME-attaching pictures works pretty reliably. But by the time you get to doing security multiparts, interoperability mostly sucks. With OpenPGP/MIME, this is particularly frustrating because there is almost always a perfectly good way to do the same thing without MIME that would have worked fine. Using OpenPGP/MIME makes sense when: (1) The operation you were going to do needed to use MIME anyway. For example, you're sending someone an attachment, and you'd like it encrypted. (2) You're using some feature of OpenPGP/MIME that gives you useful things you can't get any other way. Parallel signatures spring to mind. Using OpenPGP/MIME makes no sense when: (1) Whatever you were doing does little take the "-----BEGIN PGP MESSAGE-----" header and prefix it with one that says, "Content type: application/whatever". (2) Protecting a blob of data has nothing whatsoever to do with MIME. For example, I know of a banking system that uses OpenPGP encoded messages. There's no need for MIME here. MIME-coded messages have great uses. But alas, even to this day, there are lots of uses of them that aren't quite ready for prime time. Let's face it -- the majority of mailers don't do MIME correctly, and if I have to pry apart attachments to get to a clearsigned signature just so I can re-assemble the thing in a text editor so I can check the signature, I'm probably not going to do it. It had better be pretty important for me to take five minutes out of my day to bother. If it's encrypted, it's a lot easier for me to decide that the message is more akin to the last chance offers for domain names, offers to buy drugs without prescriptions, and entreaties to skim off some subsarharan money that I get, and treat the message the same way. Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0JDBES24872 for ietf-openpgp-bks; Sat, 19 Jan 2002 05:11:14 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc205.dialup.uoi.gr [195.130.119.205]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0JDBA324868 for ; Sat, 19 Jan 2002 05:11:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RvFk-0000FA-00 for ; Sat, 19 Jan 2002 15:09:48 +0200 Date: Sat, 19 Jan 2002 15:09:47 +0200 From: Nikos Mavroyanopoulos To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020119150947.3da6f42b.nmav@hellug.gr> In-Reply-To: <20020118161846.7db5732b.nmav@hellug.gr> References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> <20020118161846.7db5732b.nmav@hellug.gr> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 18 Jan 2002 16:18:46 +0200 Nikos Mavroyanopoulos wrote: > > That is also my understanding. The point is whether it is possible > > lookup a key based on the fingerprint. I say yes because for a local > > lookup you should index you keyring anyway (think about a server and > > millions of users) and then it doesn't matter whether to lookup by > > fingerprint or keyID. [...] > The reason I replaced keyIDs with Fingerprints is that this identifier > is covered by the TLS Finished messages. This means that after the Finished > messages are sent, the parties know that the peer got a key which is identified > by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify > for this. If they should be added, they should be added for backwards > compatibility and only for this reason. On second thoughts, I think there is not an issue for backwards compatibility, since a client is not required to send the fingerprint (he may send the key). A holder of a v3 key may send the key instead of the fingerprint, in the case he suspects that the server could not retrieve the key. I think this is the most clean solution. If you agree I'll keep the original version. -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr Received: by above.proper.com (8.11.6/8.11.3) id g0IEf6d25474 for ietf-openpgp-bks; Fri, 18 Jan 2002 06:41:06 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc217.dialup.uoi.gr [195.130.119.217]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IEf3325470 for ; Fri, 18 Jan 2002 06:41:03 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RaBA-00033E-00 for ; Fri, 18 Jan 2002 16:39:40 +0200 Date: Fri, 18 Jan 2002 16:18:46 +0200 From: Nikos Mavroyanopoulos To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020118161846.7db5732b.nmav@hellug.gr> In-Reply-To: <87d708ol37.fsf@alberti.gnupg.de> References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Jan 2002 20:04:28 +0100 Werner Koch wrote: > > used to present an "I can use this key" message to the other side, > > which implies (to me) that the remote end would need to lookup a key > > based on that number. Could you please explain how this "identifier" > That is also my understanding. The point is whether it is possible > lookup a key based on the fingerprint. I say yes because for a local > lookup you should index you keyring anyway (think about a server and > millions of users) and then it doesn't matter whether to lookup by > fingerprint or keyID. I should add here that: This identifier is used with 2 purposes: 1. To identify the key 2. To provide equal security with the case where the actual key is sent [0] The reason I replaced keyIDs with Fingerprints is that this identifier is covered by the TLS Finished messages. This means that after the Finished messages are sent, the parties know that the peer got a key which is identified by the fingerprint or keyID. Since keyIDs[1] can be faked, they do not qualify for this. If they should be added, they should be added for backwards compatibility and only for this reason. [0]: This is also discussed in the draft-ietf-tls-extensions-02 in the security considerations chapter (client certificate URL extension). [1]: I don't believe that a hash truncated to 64bits provides any security -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IBw9017592 for ietf-openpgp-bks; Fri, 18 Jan 2002 03:58:09 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IBw7317583 for ; Fri, 18 Jan 2002 03:58:07 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RY5X-00053q-00; Fri, 18 Jan 2002 13:25:43 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RXb9-0001NS-00; Fri, 18 Jan 2002 12:54:19 +0100 To: ietf-openpgp@imc.org, ietf-tls@lists.certicom.com Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> <3C476EB8.65DC0295@cyphers.net> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Fri, 18 Jan 2002 12:54:19 +0100 In-Reply-To: <3C476EB8.65DC0295@cyphers.net> (Will Price's message of "Thu, 17 Jan 2002 16:39:20 -0800") Message-ID: <878zavoowk.fsf@alberti.gnupg.de> Lines: 53 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) 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: [I am not on the tls list, feel free to resend it] On Thu, 17 Jan 2002 16:39:20 -0800, Will Price said: > Another important point about backwards compatibility: the current > OpenPGP/TLS draft already has well over a million deployed clients. This is an expired draft and as such not anymore accessible. And: at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." > Every PGP client since I believe 6.0.0 (September 1998) supports > PGPtls as described in the draft, and every PGP Keyserver since that PGP has a lot of proprietary features which are either in conflict to OpenPGP or not documented at all. NAI folks are talking for years: "We will write up the specification RSN" - I have never seen more than these announcements. Some non-NAI folks reverse engineered the format of the photo ID from actual PGP output, so that David Shaw could implement this in GnuPG but most other stuff is unknown and NAI is even dropping OpenPGP required features (v4 sigs on data) - well may be this is a bug, but those things have happened far too often. > While PGPtls in the PGPsdk was the first implementation (for which > source code is currently available at the pgp website, and part of > every source release we've done for the last few years), I know And since you re-opened the source for >= 7, you use a license which makes the source useless and actual dangerous for a programmer to look at. > In addition to ignoring all the fielded uses and implementations of > OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency There is no documentation on this format - may be PGP implemented that draft but nobody writing TLS or OpenPGP code is able to even check this as there is no usable source. If NAI would have been interested in standard conformace, the draft should be reissued regulary and the extensions to OpenPGP discussed with the OpenPGP WG. The same thing goes for OpenPGP features like MDC and a new transport format for secret keys - NAI seems not to be interested in it anymore. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I8kEb29132 for ietf-openpgp-bks; Fri, 18 Jan 2002 00:46:14 -0800 (PST) Received: from hackserv.saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0I8k9329117 for ; Fri, 18 Jan 2002 00:46:13 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Fri, 18 Jan 2002 10:41:23 0200 Message-ID: <3C47DFB3.8139C297@saiknes.lv> Date: Fri, 18 Jan 2002 10:41:23 +0200 From: disastry@saiknes.lv Organization: disastry.NO.SPaM.NET X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,lv,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Werner Koch wrote: > On 17 Jan 2002 09:52:24 -0500, Derek Atkins said: > > > You probably do not want to assume that the fingerprint is 20 octets > > long; fingerprints on v3 RSA keys are only 16 octets long. So, your > > Left pad them with zeroes and store the fingerprint maybe right pad fingerprint with keyid. but there is only space for short 4byte keyid.. __ Disastry http://disastry.dhs.org/ http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon ^----PGP 2.6.3ia-multi05 (supports IDEA, CAST5, BLOWFISH, TWOFISH, AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes) -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPEfDTjBaTVEuJQxkEQNPdwCg81w2dYiwrZW4/eOgLc3eF9xwYpsAniZu +Y+mULBtyamyoA3YiHoDPInA =zBCL -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I5B8q10076 for ietf-openpgp-bks; Thu, 17 Jan 2002 21:11:08 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I5B6310072 for ; Thu, 17 Jan 2002 21:11:06 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ4E9I00.6HF; Thu, 17 Jan 2002 22:05:42 -0800 Message-ID: <3C47AE65.AA25692E@cyphers.net> Date: Thu, 17 Jan 2002 21:11:01 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF Transport Layer Security WG CC: ietf-openpgp@imc.org Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > Will Price writes: > > History shows that is not actually true. For instance, TLS is > > almost identical to SSL. Why is this? Is it because > > "implementation > > experience" showed that SSL was simply the One True Way to write > > a transport security protocol? No. It's because there was a large > > SSL installed base of which the TLS designers wanted to take > > advantage, and thus the more identical the protocol was the more > > it would be accepted. > Funny, I think of the TLS experience the opposite way: Despite > the fact that SSL had an enormous installed base TLS is > incompatible with SSL. > > > - From an implementation experience point of view, I would say > > that the last four years have demonstrated the cipher suite space > > issue is not an issue, and the "we're going to run out of space" > > argument is the only one made to defend this negotiation proposal > > which depends on an extension proposal. > No. Even in the absence of the cipher suite depletion argument, > your approach would be a clumsy hack. Orthogonality is a good > thing. Orthogonality? Like the orthogonality of lumping the cipher type, key length, hash type, key exchange type, and export status into one sixteen bit number? I don't think so. Sorry, that argument doesn't fly in the context of TLS. The Orthogonality to the Nth degree doorway is in the IPsec WG. For TLS 1.0, the cipher suite remains the right place to put this. What we wanted in 1998, and what we still want today is a TLS 1.1 which has a field for the certificate type. I think we both agree in principle that certificate type should have had its own field. The difference is that you're willing ditch backwards compatibility and change OpenPGP/TLS to include its own clumsy hack for specifying the certificate type and depend on yet another draft, whereas we've done things the TLS 1.0 way in TLS 1.0 and would support fixing the protocol itself in a future rev. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEeuHay7FkvPc+xMEQI3rACglfiwns8NBx0Eq0VrCgsemE77rNMAoOdc vqYhnUOI8eod+jgAT5Jmj5zt =rydy -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g0I4C1v08722 for ietf-openpgp-bks; Thu, 17 Jan 2002 20:12:01 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I4Bv308714 for ; Thu, 17 Jan 2002 20:11:57 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ4BIW00.0H2; Thu, 17 Jan 2002 21:06:32 -0800 Message-ID: <3C47A087.82FD450E@cyphers.net> Date: Thu, 17 Jan 2002 20:11:51 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF Transport Layer Security WG CC: ietf-openpgp@imc.org Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 History shows that is not actually true. For instance, TLS is almost identical to SSL. Why is this? Is it because "implementation experience" showed that SSL was simply the One True Way to write a transport security protocol? No. It's because there was a large SSL installed base of which the TLS designers wanted to take advantage, and thus the more identical the protocol was the more it would be accepted. - From an implementation experience point of view, I would say that the last four years have demonstrated the cipher suite space issue is not an issue, and the "we're going to run out of space" argument is the only one made to defend this negotiation proposal which depends on an extension proposal. Time has demonstrated that particular sky is not going to fall, and thus in the absence of any method in the standard to specify certificate type the cipher suite field remains the correct place to put this. Eric Rescorla wrote: > Implementation experience is an important factor. The existence of > implementations which were written pre-Proposed and which would be > broken by a new specification isn't. If you want to argue that your > implementation experience indicates that this is the right approach > and some other approach is wrong, go ahead. I don't see you arguing > that. Rather, I see you arguing that you (and presumably others) > have implemented a specific approach and would be inconvenienced by > any other approach, regardless of its technical merits. That's not > the basis on which the IETF is supposed to make decisions. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEegfqy7FkvPc+xMEQLzTgCgwo11ZaRZPQxI0Kw7vuEVGnJCIQYAoKqk 0a78Fe7qhgTOT+EqZlvBruk2 =Lurc -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0I314T07187 for ietf-openpgp-bks; Thu, 17 Jan 2002 19:01:04 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I312307183 for ; Thu, 17 Jan 2002 19:01:02 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ488Q00.8G6; Thu, 17 Jan 2002 19:55:38 -0800 Message-ID: <3C478FE8.9BF9BE08@cyphers.net> Date: Thu, 17 Jan 2002 19:00:56 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF Transport Layer Security WG CC: ietf-openpgp@imc.org Subject: Re: [ietf-tls] Re: Fw: using openpgp with tls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eric Rescorla wrote: > Will Price writes: > > Another important point about backwards compatibility: the > > current OpenPGP/TLS draft already has well over a million > > deployed clients. Every PGP client since I believe 6.0.0 > > (September 1998) supports PGPtls as described in the draft, and > > every PGP Keyserver since that time period also supports PGPtls. > I don't find this argument very convincing. You implement things > that are Internet-Drafts at your own risk. That's why every I-D > has a disclaimer at the top. If popularity were the criterion > for standardization, we could disband the IETF and just wait > for Microsoft to tell us what the standard was. We published the draft, then we implemented, then we published code. This is standard procedure for anybody in the IETF. Implementations and implementation experience are critical factors in the WG, and if they could be ignored then TLS/SSL would be quite different today I'm sure you'll admit. > > In addition to ignoring all the fielded uses and implementations > > of OpenPGP/TLS, Nikos' proposed changes also suffer from the > > dependency problem on the TLSEXT draft, > This is a feature not a bug. Definitely seems like a bug to me. When I originally designed this, it was clear that TLS should have had a standard way of choosing a certificate type much like IKE does. I believe I raised this issue on the list at the time and the response of the list was IIRC muted agreement, but there were no plans for a new version of the TLS draft so it wasn't a discussion that was going to go anywhere. The others I spoke with in the WG felt that using the cipher suite field was the way to go. Writing a draft for a new certificate type which defines an impromptu technique for how to negotiate an OpenPGP certificate type is clearly not the way to go. TLS should always have had a certificate type field built-in. Were TLS to have such a standardized method, the OpenPGP/TLS draft should be modified to adopt that. However, it's not particularly important that such a method be developed. No more than 2 perhaps 3 certificate types will survive into the future, so that doesn't appear to be a serious concern. Worrying about running out of 16 bit space for cipher suites is unnecessary to me. We should now and should always have been conservative about which cipher suites get assigned numbers. No more than 20 cipher suites are in active use today, and going forward into the future I expect those to change but the overall number of actively used cipher suites will get smaller converging on the popular few. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEePtay7FkvPc+xMEQLJ2ACg5/R+TIlgEpWe4hZOQbjjodFNfyYAn0A8 hskbpVu9J97s/Orw23zs3yzB =Kv8s -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g0I0dSP04374 for ietf-openpgp-bks; Thu, 17 Jan 2002 16:39:28 -0800 (PST) Received: from enigma.cyphers.net (enigma.cyphers.net [64.220.173.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I0dQ304370 for ; Thu, 17 Jan 2002 16:39:27 -0800 (PST) Received: from cyphers.net (idea.cyphers.net [64.220.173.131]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id GQ41OR00.8G3; Thu, 17 Jan 2002 17:34:03 -0800 Message-ID: <3C476EB8.65DC0295@cyphers.net> Date: Thu, 17 Jan 2002 16:39:20 -0800 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-openpgp@imc.org CC: ietf-tls@lists.certicom.com Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another important point about backwards compatibility: the current OpenPGP/TLS draft already has well over a million deployed clients. Every PGP client since I believe 6.0.0 (September 1998) supports PGPtls as described in the draft, and every PGP Keyserver since that time period also supports PGPtls. PGPtls can be used for split key network reconstitution, normal key searches on keyservers, client authentication to keyservers for the purpose of deleting or disabling keys, and a whole host of other things in various products from NAI and others. While PGPtls in the PGPsdk was the first implementation (for which source code is currently available at the pgp website, and part of every source release we've done for the last few years), I know others have mentioned other implementations as well to me over the last year or so. In addition to ignoring all the fielded uses and implementations of OpenPGP/TLS, Nikos' proposed changes also suffer from the dependency problem on the TLSEXT draft, and the Fingerprint/KeyID confusion which I've previously detailed on the ietf-tls list. It would be a huge mistake to adopt the proposed changes. Derek Atkins wrote: > > Werner Koch writes: > > > Let's avoid the X.509 > > problem of not knowing how to cleany identify a key. > > Why not add 8 more bytes and you still get this functionality and > backwards compatibility? > > Keep in mind that lack-of-backwards-compatibility is what got us > where we are today, a fragmented community of people. It all > started with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP. > > Backwards compatibility is a Good Thing, in particular when talking > about long-lived identity keys. - - -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.1.1 iQA/AwUBPEdufKy7FkvPc+xMEQJ6FQCfStNGaVZH3v00PfvlC+K/OKF0fNEAniX7 HwmnVYqVPtvH3TEmFWstFLd/ =L7x2 -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g0HJqII25264 for ietf-openpgp-bks; Thu, 17 Jan 2002 11:52:18 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJqD325259 for ; Thu, 17 Jan 2002 11:52:14 -0800 (PST) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.21.75]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA09525; Thu, 17 Jan 2002 14:52:13 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA28143; Thu, 17 Jan 2002 14:52:10 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id OAA20905; Thu, 17 Jan 2002 14:52:10 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id OAA00567; Thu, 17 Jan 2002 14:52:09 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> <87d708ol37.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 14:52:09 -0500 In-Reply-To: <87d708ol37.fsf@alberti.gnupg.de> Message-ID: Lines: 21 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > Let's avoid the X.509 > problem of not knowing how to cleany identify a key. Why not add 8 more bytes and you still get this functionality and backwards compatibility? Keep in mind that lack-of-backwards-compatibility is what got us where we are today, a fragmented community of people. It all started with PGP 2.5 and got worse with PGP 5.0, let alone OpenPGP. Backwards compatibility is a Good Thing, in particular when talking about long-lived identity keys. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJ86x24086 for ietf-openpgp-bks; Thu, 17 Jan 2002 11:08:06 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJ84324081 for ; Thu, 17 Jan 2002 11:08:04 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RIJw-0001JH-00; Thu, 17 Jan 2002 20:35:32 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RHps-0008LH-00; Thu, 17 Jan 2002 20:04:28 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 20:04:28 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 13:07:43 -0500") Message-ID: <87d708ol37.fsf@alberti.gnupg.de> Lines: 34 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 13:07:43 -0500, Derek Atkins said: > used to present an "I can use this key" message to the other side, > which implies (to me) that the remote end would need to lookup a key > based on that number. Could you please explain how this "identifier" That is also my understanding. The point is whether it is possible lookup a key based on the fingerprint. I say yes because for a local lookup you should index you keyring anyway (think about a server and millions of users) and then it doesn't matter whether to lookup by fingerprint or keyID. There is even no reasonable high overhead when inserting a new key: Most keys are v4 and to get a keyID you need to calculate the fingerprint anyway. For the few v3 keys (cf. dtype.org for keyserver statistics) you can avoid the fingerprint calculation but really this doesn't matter anymore. For a lookup via keyserver there is probably a problem with the HKS type servers but they have so many problems that they have to replaced anyway. I am pretty sure that the NAI certserver is able to do a lookup by fingerprint and to add this to the ALMI and cryptnet servers will only take a few hours. So why not using _only_ the fingerprint in TLS. IIRC we had a discussion a long time ago to allow the use of fingerprint in the next version of signature packets. My point is that the fingerprint is the correct way to identify a key and that there is no need for backward compatibilty when a new protocol is designed. Let's avoid the X.509 problem of not knowing how to cleany identify a key. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0HI7mE22029 for ietf-openpgp-bks; Thu, 17 Jan 2002 10:07:48 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HI7j322025 for ; Thu, 17 Jan 2002 10:07:45 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA25611; Thu, 17 Jan 2002 13:07:45 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01513; Thu, 17 Jan 2002 13:07:44 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA07923; Thu, 17 Jan 2002 13:07:44 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id NAA00224; Thu, 17 Jan 2002 13:07:43 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> <87hepkoo0f.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 13:07:43 -0500 In-Reply-To: <87hepkoo0f.fsf@alberti.gnupg.de> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On 17 Jan 2002 12:44:30 -0500, Derek Atkins said: > > > Keep in mind that TLS can use "user certificates" too... Are you > > implying that users with v3 certs have to generate a new key > > in order to use them in TLS? > > Yes, for the same reasons as for servers. The majority of keys is v4 I disagree that these reasons are valid... But that's not important right now.. > And I still don't see a reason why a keyID is needed in TLS. We need > the keyIDs to lookup signing keys but this has nothing to do with TLS. Ok, perhaps I am confused. Could you please explain how the fingerprint would get used the TLS protocol? I thought it was being used to present an "I can use this key" message to the other side, which implies (to me) that the remote end would need to lookup a key based on that number. Could you please explain how this "identifier" is meant to be used within TLS? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HI45E21888 for ietf-openpgp-bks; Thu, 17 Jan 2002 10:04:05 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HI43321884 for ; Thu, 17 Jan 2002 10:04:03 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RHJz-0008Sp-00; Thu, 17 Jan 2002 19:31:31 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RGqm-0008GB-00; Thu, 17 Jan 2002 19:01:20 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 19:01:20 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 12:44:30 -0500") Message-ID: <87hepkoo0f.fsf@alberti.gnupg.de> Lines: 17 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 12:44:30 -0500, Derek Atkins said: > Keep in mind that TLS can use "user certificates" too... Are you > implying that users with v3 certs have to generate a new key > in order to use them in TLS? Yes, for the same reasons as for servers. The majority of keys is v4 for quite a long time now. I know only a few people insisting on using the old keys - even Ted T'so has a v4 key now. And I still don't see a reason why a keyID is needed in TLS. We need the keyIDs to lookup signing keys but this has nothing to do with TLS. -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0HHiXV21060 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:44:33 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHiU321049 for ; Thu, 17 Jan 2002 09:44:31 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17212; Thu, 17 Jan 2002 12:44:32 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.21.85]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25796; Thu, 17 Jan 2002 12:44:32 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13032; Thu, 17 Jan 2002 12:44:30 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA00174; Thu, 17 Jan 2002 12:44:30 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> <87lmewopaz.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 12:44:30 -0500 In-Reply-To: <87lmewopaz.fsf@alberti.gnupg.de> Message-ID: Lines: 43 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Keep in mind that TLS can use "user certificates" too... Are you implying that users with v3 certs have to generate a new key in order to use them in TLS? -derek Werner Koch writes: > On 17 Jan 2002 12:24:03 -0500, Derek Atkins said: > > > I don't think that's a reasonable assumption to make. Worse, if you > > have _ANY_ v3 keys then you need to ship the keyID. Perhaps there is > > Why? Because the HKP keyservers are not able to search by > fingerprint? Hopefully this will be fixed and the modern key servers > support such a lookup (well, not checked but easy to add). > > I can't imagine that anyone will use an old v3 key for TLS > authentication - TLS is always used on a networked machine (surprise) > and as such this machine is much more exposed to attacks than the > secure boxes we all use to handle or secret keys ;-). If TLS is > configured somewhere, a new key should be used for this and this key > can in turn be signed by certification key. > > Using PGP keys with TLS is a new thing and we don't have to take > backwards compatibility into account. > > Ciao, > > Werner > > > -- > Werner Koch Omnis enim res, quae dando non deficit, dum habetur > g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. > Privacy Solutions -- Augustinus > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: by above.proper.com (8.11.6/8.11.3) id g0HHa5A20658 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:36:05 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHa3320649 for ; Thu, 17 Jan 2002 09:36:03 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RGst-0007s4-00; Thu, 17 Jan 2002 19:03:31 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RGPk-0008DW-00; Thu, 17 Jan 2002 18:33:24 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 18:33:24 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 12:24:03 -0500") Message-ID: <87lmewopaz.fsf@alberti.gnupg.de> Lines: 28 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 12:24:03 -0500, Derek Atkins said: > I don't think that's a reasonable assumption to make. Worse, if you > have _ANY_ v3 keys then you need to ship the keyID. Perhaps there is Why? Because the HKP keyservers are not able to search by fingerprint? Hopefully this will be fixed and the modern key servers support such a lookup (well, not checked but easy to add). I can't imagine that anyone will use an old v3 key for TLS authentication - TLS is always used on a networked machine (surprise) and as such this machine is much more exposed to attacks than the secure boxes we all use to handle or secret keys ;-). If TLS is configured somewhere, a new key should be used for this and this key can in turn be signed by certification key. Using PGP keys with TLS is a new thing and we don't have to take backwards compatibility into account. Ciao, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0HHO5v20023 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:24:05 -0800 (PST) Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHO3320018 for ; Thu, 17 Jan 2002 09:24:04 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA13457; Thu, 17 Jan 2002 12:24:05 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA21162; Thu, 17 Jan 2002 12:24:04 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA17041; Thu, 17 Jan 2002 12:24:03 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA00139; Thu, 17 Jan 2002 12:24:03 -0500 (EST) To: Werner Koch Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <87u1tkoqb4.fsf@alberti.gnupg.de> From: Derek Atkins Date: 17 Jan 2002 12:24:03 -0500 In-Reply-To: <87u1tkoqb4.fsf@alberti.gnupg.de> Message-ID: Lines: 30 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > > You probably want to send along the keyID as well as the fingerprint. > > Frankly, I suggested to drop the keyID because the few extra bytes for > a fingerprint are not an issue and it makes the code easier if we only > have to lookup by fingerprint. Sure, it's redundant for v4 keys but it's required for v3 keys. > > Most implementations can only lookup a key based on the keyID. As a > > Then they should be fixed. To lookup by keyID you have to calculate > the fingerprint anyway for v4 keys. And there won't be many v3 keys > in use with TLS. I don't think that's a reasonable assumption to make. Worse, if you have _ANY_ v3 keys then you need to ship the keyID. Perhaps there is some way that if keyID == lower_part(fingerprint) then we only send the fingerprint, but send keyID if it's !=? > Werner -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: by above.proper.com (8.11.6/8.11.3) id g0HHLSj19863 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:21:28 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHLQ319858 for ; Thu, 17 Jan 2002 09:21:26 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA08343; Thu, 17 Jan 2002 12:21:27 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20662; Thu, 17 Jan 2002 12:21:27 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA15968; Thu, 17 Jan 2002 12:21:27 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA00127; Thu, 17 Jan 2002 12:21:26 -0500 (EST) To: Nikos Mavroyanopoulos Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> <20020117185529.42cdf46d.nmav@hellug.gr> From: Derek Atkins Date: 17 Jan 2002 12:21:26 -0500 In-Reply-To: <20020117185529.42cdf46d.nmav@hellug.gr> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikos Mavroyanopoulos writes: > the notation <20> means an upper limit of 20 bytes in TLS (used in > RFC2246), so v3 fingerprints can be used. (the specified data are > encoded with the size). Ok. I am unfamilar with the TLS spec, so thank you for clearing this up. > > You probably want to send along the keyID as well as the fingerprint. > > Most implementations can only lookup a key based on the keyID. As a > > result, you wont be able to easily lookup v3 RSA keys if you only send > > the fingerprint. I would recommend you change the definition to: > > I'm not quite familiar with OpenPGP, and I had the impression that v3 > keys were only defined for backwards compatibility. If v3 keys are still > in use I could use something like: That's ok -- I am. I'm afraid that yes, v3 keys are still in wide use. Anyone who generated their key using PGP 2.x and is still using PGP with that key is de facto using a v3 key. I, personally, am one such user. It is more than just backwards compatibility (IMHO). > > opaque PGPKeyID<8> > > opaque PGPFingerprint<20> > > > > struct { > > PGPKeyID pgp_key_id; > > PGPFingerprint pgp_fingerprint; > > } PGPKeyDescriptor; > > The first version always sends the keyID (which is redundant in v4 keys). I'm willing to live with 8 bytes of redundancy. It's still better than X.509 ;) > The second version is a bit complicated, but sends the keyID only for v3 > keys. I don't really like it because (at least since today) TLS did not > have to know about X.509 certificates' version explicitly. I think it's > better to be that way for OpenPGP keys too. I agree.. Go with the former and always send the extra 8 bytes of keyID. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HHEBU19554 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:14:11 -0800 (PST) Received: from porta.u64.de (porta.u64.de [194.77.88.106]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HHE8319549 for ; Thu, 17 Jan 2002 09:14:09 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16RGXa-0007Oe-00; Thu, 17 Jan 2002 18:41:30 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16RG4l-0008B6-00; Thu, 17 Jan 2002 18:11:43 +0100 To: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 17 Jan 2002 18:11:43 +0100 In-Reply-To: (Derek Atkins's message of "17 Jan 2002 09:52:24 -0500") Message-ID: <87u1tkoqb4.fsf@alberti.gnupg.de> Lines: 27 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 09:52:24 -0500, Derek Atkins said: > You probably do not want to assume that the fingerprint is 20 octets > long; fingerprints on v3 RSA keys are only 16 octets long. So, your Left pad them with zeroes and store the fingerprint as meta data with the keys or index a DB using the fingerprint. It might even be easier to require the use of v4 keys. > You probably want to send along the keyID as well as the fingerprint. Frankly, I suggested to drop the keyID because the few extra bytes for a fingerprint are not an issue and it makes the code easier if we only have to lookup by fingerprint. > Most implementations can only lookup a key based on the keyID. As a Then they should be fixed. To lookup by keyID you have to calculate the fingerprint anyway for v4 keys. And there won't be many v3 keys in use with TLS. Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus Received: by above.proper.com (8.11.6/8.11.3) id g0HH9Pr19339 for ietf-openpgp-bks; Thu, 17 Jan 2002 09:09:25 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc223.dialup.uoi.gr [195.130.119.223]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HH9I319332 for ; Thu, 17 Jan 2002 09:09:20 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16RG16-0007vm-00; Thu, 17 Jan 2002 19:07:56 +0200 Date: Thu, 17 Jan 2002 18:55:29 +0200 From: Nikos Mavroyanopoulos To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020117185529.42cdf46d.nmav@hellug.gr> In-Reply-To: References: <20020117085114.3854af79.nmav@hellug.gr> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 17 Jan 2002 09:52:24 -0500 Derek Atkins wrote: Derek, thank you for your comments, > You probably do not want to assume that the fingerprint is 20 octets > long; fingerprints on v3 RSA keys are only 16 octets long. So, your > definition of PGPFingerprint<20> wont work with all OpenPGP keys. > Since you're already assuming DSS keys by your 20-octet fingerprint, > it should be noted that the v4 (DSS) keyID is just the lower 64-bits > of the fingerprint. (RFC2440: 11.2) the notation <20> means an upper limit of 20 bytes in TLS (used in RFC2246), so v3 fingerprints can be used. (the specified data are encoded with the size). > You probably want to send along the keyID as well as the fingerprint. > Most implementations can only lookup a key based on the keyID. As a > result, you wont be able to easily lookup v3 RSA keys if you only send > the fingerprint. I would recommend you change the definition to: I'm not quite familiar with OpenPGP, and I had the impression that v3 keys were only defined for backwards compatibility. If v3 keys are still in use I could use something like: > opaque PGPKeyID<8> > opaque PGPFingerprint<20> > > struct { > PGPKeyID pgp_key_id; > PGPFingerprint pgp_fingerprint; > } PGPKeyDescriptor; or > opaque PGPKeyID<8> > opaque PGPFingerprint<20> > enum { v3, v4 } PGPKeyVersion; > > struct { > PGPFingerprint pgp_fingerprint; > PGPKeyVersion keyVersion; > select (PGPKeyVersion) { > case v3: PGPKeyID; > case v4: {}; > } > } PGPKeyDescriptor; The first version always sends the keyID (which is redundant in v4 keys). The second version is a bit complicated, but sends the keyID only for v3 keys. I don't really like it because (at least since today) TLS did not have to know about X.509 certificates' version explicitly. I think it's better to be that way for OpenPGP keys too. > -derek > -- > Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory > Member, MIT Student Information Processing Board (SIPB) > URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH > warlord@MIT.EDU PGP key available -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HEqaV14974 for ietf-openpgp-bks; Thu, 17 Jan 2002 06:52:36 -0800 (PST) Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HEqX314970 for ; Thu, 17 Jan 2002 06:52:33 -0800 (PST) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id JAA09505; Thu, 17 Jan 2002 09:52:32 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA22199; Thu, 17 Jan 2002 09:52:28 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id JAA14213; Thu, 17 Jan 2002 09:52:25 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA24717; Thu, 17 Jan 2002 09:52:24 -0500 (EST) To: Nikos Mavroyanopoulos Cc: ietf-openpgp@imc.org Subject: Re: Fw: [ietf-tls] using openpgp with tls References: <20020117085114.3854af79.nmav@hellug.gr> From: Derek Atkins Date: 17 Jan 2002 09:52:24 -0500 In-Reply-To: <20020117085114.3854af79.nmav@hellug.gr> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Nikos Mavroyanopoulos writes: > Hello, > Some days ago I posted to ietf-tls WG mailing list, a modification > of the draft-ietf-tls-openpgp-01. Since this is about openpgp, > I decided to post it here too. > > The original post: > > I wanted to use openpgp certificates with TLS, but > draft-ietf-tls-openpgp-01 is expired, and had some properties that I did > not like. Here I modified the tls-openpgp draft in a way that: > * no new cipher suites need to be defined, in order to use openpgp keys > * does not use keyIDs but key fingerprints > > I'd appreciate any comments on this. You probably do not want to assume that the fingerprint is 20 octets long; fingerprints on v3 RSA keys are only 16 octets long. So, your definition of PGPFingerprint<20> wont work with all OpenPGP keys. Since you're already assuming DSS keys by your 20-octet fingerprint, it should be noted that the v4 (DSS) keyID is just the lower 64-bits of the fingerprint. (RFC2440: 11.2) You probably want to send along the keyID as well as the fingerprint. Most implementations can only lookup a key based on the keyID. As a result, you wont be able to easily lookup v3 RSA keys if you only send the fingerprint. I would recommend you change the definition to: opaque PGPKeyID<8> opaque PGPFingerprintV3<16> opaque PGPFingerprintV4<20> struct { PGPKeyVersion keyVersion; select (keyVersion) { case v3: PGPFingerprintV3; case v4: PGPFingerprintV4; } PGPKeyID; } PGPKeyDescriptor; And then use the PGPKeyDescriptor in your Certificate structure. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0H6qr001074 for ietf-openpgp-bks; Wed, 16 Jan 2002 22:52:53 -0800 (PST) Received: from crystal.i-net.gr (foobar@pc233.dialup.uoi.gr [195.130.119.233]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0H6qh301064 for ; Wed, 16 Jan 2002 22:52:50 -0800 (PST) Received: from localhost ([127.0.0.1] helo=crystal ident=foobar) by crystal.i-net.gr with smtp (Exim 3.32 #1 (Debian)) id 16R6OS-0000TF-00 for ; Thu, 17 Jan 2002 08:51:24 +0200 Date: Thu, 17 Jan 2002 08:51:14 +0200 From: Nikos Mavroyanopoulos To: ietf-openpgp@imc.org Subject: Fw: [ietf-tls] using openpgp with tls Message-Id: <20020117085114.3854af79.nmav@hellug.gr> X-Mailer: Sylpheed version 0.6.5claws25 (GTK+ 1.2.10; i386-debian-linux-gnu) X-URL: http://members.hellug.gr/nmav X-PGP-KeyID: B15C37D1 X-Request-PGP: finger:nmav@members.hellug.gr Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello, Some days ago I posted to ietf-tls WG mailing list, a modification of the draft-ietf-tls-openpgp-01. Since this is about openpgp, I decided to post it here too. The original post: I wanted to use openpgp certificates with TLS, but draft-ietf-tls-openpgp-01 is expired, and had some properties that I did not like. Here I modified the tls-openpgp draft in a way that: * no new cipher suites need to be defined, in order to use openpgp keys * does not use keyIDs but key fingerprints I'd appreciate any comments on this. 2. Certificates The X.509v3 [X509] certificates recommended for use with TLS will not be used in conjunction with OpenPGP keys. An implementation SHOULD be able to support both TLS with X509 and TLS with OpenPGP keys. It is NOT REQUIRED that an implementation support both. The "peer certificate" in the session state of TLS MAY refer to either X509 or OpenPGP. 3. Changes to the Handshake Message Contents This section describes the changes to the TLS handshake message contents when OpenPGP keys are to be used for authentication. 3.1 Hello Messages 3.1.1 Extension Type A new value, "cert_type(7)", has been added to the enumerated ExtensionType, defined in [TLSEXT]. This value is used as the extension number for the extensions in both the client hello message and the server hello message. This value was chosen based on the version of defined in [TLSEXT] that was current at the time of writing, so may be changed in future. 3.1.2 The Client Hello Message An extension of type CertificateTypeExtension is appended to the standard client hello message using the client hello extension mechanism defined in [TLSEXT]. This extension carries a list of supported Certificate types the client can use. This extension SHOULD NOT be used if the client supports only X.509 Certificates. enum { client, server } ClientOrServerExtension; enum { X.509(0), OpenPGP(1), (255) } CertificateType; struct { select(ClientOrServerExtension) { case client: CertificateType certificate_type<1..2^8-1>; case server: CertificateType certificate_type; } } CertificateTypeExtension; 3.1.3 Server Hello The certificate type selected by the server (certificate_type), is appended to the server hello message using the hello extension mechanism defined in [TLSEXT]. The certificate type selected by the server (certificate_type), is encoded in an CertificateTypeExtension structure, which is sent in an extended server hello message, using an extension of type "cert_type". The CertificateTypeExtension structure may be omited if the server only supports X.509 certificates. 3.2 Server certificate The contents of the certificate message sent from server to client and vice versa are determined by the negotiated certificate type and the cipher suite. In case OpenPGP certificate type is negotiated then it is required to present an OpenPGP key in the Certificate message. A OpenPGP key appearing in the Certificate message will be sent in binary OpenPGP format. The Certificate message includes an OpenPGP key where the X.509 certificate would normally appear. The option is also available to send an OpenPGP fingerprint, instead of sending the entire key. The generation of fingerprints is defined in [OpenPGP]. The client will respond with a fatal alert unsupported_certificate if the key with the given fingerprint cannot be found. If the key is not valid, expired, revoked, corrupt, the appropriate fatal alert message is sent from section A.3 of the TLS specification. If a key is valid and neither expired nor revoked, it is accepted by the protocol. A particular OpenPGP compatible TLS implementation MAY wish to allow users to designate certain keys specifically as Trusted Server Keys. This is a local matter outside the scope of this document. enum { key (0), key_fingerprint (1), (255) } PGPKeyDescriptorType; opaque PGPFingerprint<20>; opaque PGPKey<1..2^24-1> struct { PGPKeyDescriptorType descriptorType; select (descriptorType) { case key_fingerprint: PGPFingerprint; case key: PGPKey; } } Certificate; 3.3 Certificate Request The server is allowed to request a client certificate from the client. The meaning of this message is essentially unchanged to allow OpenPGP keys. The rsa_sign and dss_sign certificate types may be requested in conjunction with OpenPGP keys. The ClientCertificateType field is used identically to the TLS specification. The subsequent DistinguishedName field is NOT included when using OpenPGP keys. The Client Certificate message is sent using the same formatting as the server Certificate message in response to the Certificate Request message. If no OpenPGP key is available from the client, then an empty certificate is returned. The server MAY then respond with a fatal alert if appropriate. This transaction follows the TLS specification. 3.4 Server Key Exchange When using ephemeral Diffie-Hellman, the Server Key Exchange message is sent to pass the Diffie-Hellman public value to the client. The client and server then use this value to establish the shared secret. This is identical to the operation of standard TLS. 3.5 Certificate Verify The Certificate Verify message for OpenPGP key types is identical to the specification. The signature is made using either DSS or RSA depending on the Cipher Suite. 3.6 Finished The Finished message for OpenPGP key types is identical to the description in the specification. 4. Supported Key Exchange Algorithms OpenPGP certificates can be used with the following key exchange algorithms: Key Exchange Algorithm Certificate Key Type RSA RSA public key; the certificate must allow the key to be used for encryption. DHE_DSS DSS public key. DHE_RSA RSA public key which can be used for signing. The above key exchange algorithms are defined in [TLS]. 5. Cipher Suites No new Cipher Suites are required, in order to use OpenPGP certificates, but some additional Cipher Suites are defined here in order to support algorithms defined in [OpenPGP] but are not present in [TLS]. CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_SHA = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_CAST_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_SHA = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_CAST_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_CAST_CBC_SHA = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_CAST_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD = { 0x00, 0x?? }; CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD = { 0x00, 0x?? }; All of the above Cipher Suites use either the CAST, AES, or TripleDES block ciphers in CBC mode. The choice of hash is either SHA-1 or RIPEMD-160. "Export" algorithms also MAY NOT be used with OpenPGP keys. Implementations are not required to support the above cipher suites. 6. References [TLS] T. Dierks, and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [OpenPGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [TLSEXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "TLS Extensions", draft-ietf-tls-extensions-02 (work in progress), June 2001. [X509] CCITT. Recommendation X.509: "The Directory - Authentication Framework". 1988. -- Nikos Mavroyanopoulos mailto:nmav@hellug.gr Received: by above.proper.com (8.11.6/8.11.3) id g093Kw200174 for ietf-openpgp-bks; Tue, 8 Jan 2002 19:20:58 -0800 (PST) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g093Km300167 for ; Tue, 8 Jan 2002 19:20:56 -0800 (PST) Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA24899; Wed, 9 Jan 2002 16:20:33 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA146637; Wed, 9 Jan 2002 16:20:32 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 9 Jan 2002 16:20:32 +1300 (NZDT) Message-ID: <200201090320.QAA146637@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: roessler@does-not-exist.org, vedaal@hotmail.com Subject: Re: new patent app conflicts with pgp Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >On 2002-01-08 09:00:42 -0500, vedaal wrote: >>[C] According to a web page I located, RFC1991 was published August 1996 >>and includes the following text: > >See also Schneier, Applied Cryptography 2nd ed, p. 51, for a slightly more >abstract description. This is from 1996, too. If you really want go go back to old stuff, there's the PEM RFCs starting in 1987, OSI (who?) work from the mid 1980's, and assorted conference papers and research work on secure mail from the same time frame. Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08Hfdd10975 for ietf-openpgp-bks; Tue, 8 Jan 2002 09:41:39 -0800 (PST) Received: from smtp.tiscali.de (mx0.12move.de [62.26.124.140]) by above.proper.com (8.11.6/8.11.3) with SMTP id g08Hfb310970 for ; Tue, 8 Jan 2002 09:41:37 -0800 (PST) Received: (qmail 65541 invoked from network); 8 Jan 2002 17:41:32 -0000 Received: from unknown (HELO sobolev.does-not-exist.org) (62.27.238.11) by smtp0.tiscali.de with SMTP; 8 Jan 2002 17:41:32 -0000 Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 6AEEA2ED15; Tue, 8 Jan 2002 16:58:19 +0100 (CET) Date: Tue, 8 Jan 2002 16:58:19 +0100 From: Thomas Roessler To: vedaal Cc: ietf-openpgp@imc.org Subject: Re: new patent app conflicts with pgp Message-ID: <20020108155819.GE24528@sobolev.does-not-exist.org> Mail-Followup-To: vedaal , ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-Face: Oxq^+Q$NuUQ-&J#F14uCyP4}v%$5{ZGnS}PX;zoxOQ%*`#dkJ'qx$w}\Z;m.e*,_K0V8mii$qU(|l Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-01-08 09:00:42 -0500, vedaal wrote: >[C] According to a web page I located, RFC1991 was published August 1996 >and includes the following text: See also Schneier, Applied Cryptography 2nd ed, p. 51, for a slightly more abstract description. This is from 1996, too. -- Thomas Roessler http://log.does-not-exist.org/ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08E2o702030 for ietf-openpgp-bks; Tue, 8 Jan 2002 06:02:50 -0800 (PST) Received: from hotmail.com (oe41.law3.hotmail.com [209.185.240.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08E2n302026 for ; Tue, 8 Jan 2002 06:02:49 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 8 Jan 2002 06:02:42 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: Re: new patent app conflicts with pgp Date: Tue, 8 Jan 2002 09:00:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 08 Jan 2002 14:02:42.0185 (UTC) FILETIME=[23B1E790:01C1984D] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Sat, Jan 05, 2002 at 01:53:09PM -0500, John Kane wrote: > > Someone has applied for a US patent on the technique of > using a symmetric session key on a document, and then using > multiple public keys to encrypt the session key to multiple > recipients I forwarded the message with the url to a patent attorney who also happens to be an avid pgp/gpg user, and on several of the pgp mailing lists, {but not this one}, and am listing his response below: Vedaal, please forward this message to the IETF list and anywhere else you think appropriate. Below are some facts to ponder. As a patent agent registered to practice before the U.S. Patent Office, I do advise clients about patentability of their inventions. Indeed, if a client came to me with this pending application, I would be in a position to counsel him or her as to whether I thought it wise to pursue it. However, I do not provide such advice to anyone but a client in a professional relationship (see disclaimer), so the legal conclusions of these facts are left to the reader or his or her legal counsel. Also, please note that the scope of my practice does *not* extend to analyzing the effect of issued patents, as that is a matter before the courts and not the Patent Office. Now on to the facts... [A] The independent claims of the Jevans application, as published, are copied below. All other published claims are dependent on one of these two, and are thus no broader in scope than these two. I've broken claim 1 into sections for easier reading. 1. A method for transmitting a message, comprising the steps of - - encrypting said message to develop an encrypted message, - - said encrypted message being decryptable using a first decryption key; - - encrypting said first decryption key with encryption keys of a plurality of target recipients, to develop a plurality of encrypted decryption keys; and - - transmitting said encrypted message and said encrypted decryption keys to said target recipients. 22. Apparatus including at least one computer readable storage medium, said apparatus carrying data comprising: an encrypted message, said encrypted message being decryptable using a first decryption key; and a plurality of encrypted decryption keys stored in conjunction with said encrypted message, each of said encrypted decryption keys including said first decryption key encrypted with an encryption key of a respective target recipient of said message. [B] The application claims priority of a provisional application filed Feb. 24, 2000. Assuming that provisional application fully supports the pending claims (and that shouldn't be taken for granted), any patent or "printed publication" that (1) was available to the interested public more than one year before the provisional's filing date, i.e., before Fed. 24, 1999, and (2) "discloses, either expressly or inherently, all of the limitations [i.e., elements] of the claim[s]" would anticipate the claims and render them unpatentable. Note that the definition of "printed publication" likely includes RFCs, which are easily found on any search engine and are publicly available (i.e., "Distribution of this memo is unlimited"). Even if a reference does not discloses all limitations of a claim, a claim can be rejected as obvious over a reference or combination of references, coupled with a clear suggestion in the art (prior published literature, patents, etc.) that the reference(s) can or should be combined or modified to arrive at the claimed invention. [C] According to a web page I located, RFC1991 was published August 1996 and includes the following text: >"A pgp file consists of three components: a message component, a signature >(optional), and a session key component (optional)." [5.2] . . . >"The session key component includes the encrypted session key and the >identifier of the recipients public key used by the sender to encrypt the >session key. The session key component consists of a single >public-key-encrypted packet for each recipient of the message." [5.2.3] [D] According to another web page I located, RFC2440 was published November 1998 and includes the following text: > A Public-Key Encrypted Session Key packet holds the session key used > to encrypt a message. Zero or more Encrypted Session Key packets > (either Public-Key or Symmetric-Key) may precede a Symmetrically > Encrypted Data Packet, which holds an encrypted message. The message > is encrypted with the session key, and the session key is itself > encrypted and stored in the Encrypted Session Key packet(s). The > Symmetrically Encrypted Data Packet is preceded by one Public-Key > Encrypted Session Key packet for each OpenPGP key to which the > message is encrypted. The recipient of the message finds a session > key that is encrypted to their public key, decrypts the session key, > and then uses the session key to decrypt the message. . . . > Note that when an implementation forms several PKESKs with one > session key, forming a message that can be decrypted by several keys, > the implementation MUST make new PKCS-1 padding for each key. > > An implementation MAY accept or use a Key ID of zero as a "wild card" > or "speculative" Key ID. In this case, the receiving implementation > would try all available private keys, checking for a valid decrypted > session key. This format helps reduce traffic analysis of messages. > [5.1] [E] During pendency of their applications, a patent applicant and his or her representatives are legally bound to disclose to the Patent Examiner any materials they consider "material to patentability" of the application. This includes materials sent to them from third parties after they have filed (and published) the application. Sometimes the submitted materials are devastating, and the application goes abandoned. Other times submitting the materials actually winds up helping strengthen the eventual patent because the Examiner considered the worst "prior art" and still allowed the claims to issue -- there's a presumption that the Examiner did his or her job correctly. So don't try this at home, at least not without specific professional advice. I hope this info provides some illumination for your continued discussions. I don't subscribe to the list, so feel free to CC: me if you wish. Ed Suominen Registered Patent Agent (http://eepatents.com) Independent Inventor of Electrical Engineering Technology U.S. Patents 5,926,513; 5,937,341*; 6,052,748*; 6,069,913; additional patents pending* (*Available for licensing) < Nothing in this message is to be construed as legal advice or the opinion of my firm or any client. > -----BEGIN PGP SIGNATURE----- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: { Acts of Kindness better the World, and protect the Soul } Comment: KeyID: 0x6A05A0B785306D25 Comment: Fingerprint: 96A6 5F71 1C43 8423 D9AE 02FD A711 97BA iQEVAwUBPDr7QmoFoLeFMG0lAQPQ8gf+Ikdie+OpuAkwAzPKD6xHTQxK0v680GFm 2ZEGYpQ7tEveS7ntCdR74IBtiJj9rwTV0vx/Eu6YGOEe7oKCHxWrx8bxLG+O5YUj chTFOFL1YWdGxYdKzSidUGQl6YkKc+DP2Abh4cMGRUNI7V1NxzvjRB3T8QH/TitL ld2xoLfhvv3iLoKN3lJkHWBxQ0o+fJFroSDTDjvdYrXlNo6tygQ6Sf+qNZh4Whtw qZ/ZVMkPIxRkbGu2kCPZ2rtVRoP+pr74LHA5n50qW2NEtDB2+y80Lgedu8wq4OvS UQV/kWOWzCn80RRKKECr6GUGk371BG51iKA6H5q8R3KlW4KwLSMS7A== =6ahh -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g07MuZk09052 for ietf-openpgp-bks; Mon, 7 Jan 2002 14:56:35 -0800 (PST) Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07MuY309048 for ; Mon, 7 Jan 2002 14:56:34 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g07MuTV08102 for ietf-openpgp@imc.org; Mon, 7 Jan 2002 17:56:29 -0500 Date: Mon, 7 Jan 2002 17:56:29 -0500 From: David Shaw To: IETF-OpenPGP Subject: Re: new patent app conflicts with pgp Message-ID: <20020107175629.D2997@akamai.com> Mail-Followup-To: IETF-OpenPGP References: <3C374B93.A3EBCF85@softhome.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C374B93.A3EBCF85@softhome.net>; from jkane89@softhome.net on Sat, Jan 05, 2002 at 01:53:09PM -0500 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Crescent (32% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jan 05, 2002 at 01:53:09PM -0500, John Kane wrote: > > Someone has applied for a US patent on the technique of > using a symmetric session key on a document, and then using > multiple public keys to encrypt the session key to multiple > recipients. Newton Hammet newton(at)hammet.net brought > this to our attention. > > http://appft1.uspto.gov/netahtml/PTO/srchnum.html > (search for 20010055396) > http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html > http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html > > He cites RSA as prior art, but not RFC1991/RFC2440. I've not read the patent, but if there really is a prior art conflict with PGP: http://www.uspto.gov/web/menu/helpfaq.htm#a50 #50 How does one file protest on patents that are pending? Protests by a member of the public against pending applications will be referred to the examiner having charge of the subject matter involved. A protest specifically identifying the application to which the protest is directed will be entered in the application file if: (1) The protest is submitted prior to the publication of the application or the mailing of a notice of allowance under rule 1.311, whichever occurs first; and (2) The protest is either served upon the applicant in accordance with rule 1.248, or filed with the Office in duplicate in the event service is not possible. For more detailed information on protesting a patent, you may visit our Web site at http://www.uspto.gov/web/offices/pac/mpep/mpep.htm for the Manual of Patent Examining Procedure (MPEP) Chapter 1900. The specific document referred to is at http://www.uspto.gov/web/offices/pac/mpep/mpep_e8_1900.pdf David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07LNDr06636 for ietf-openpgp-bks; Mon, 7 Jan 2002 13:23:13 -0800 (PST) Received: from wanda.ch (adsl-73-116-basel1.tiscalinet.ch [212.254.73.116]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07LNB306632 for ; Mon, 7 Jan 2002 13:23:11 -0800 (PST) Received: from wanda.ch (wanda.ch [212.254.73.116]) by wanda.ch (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g07LMqx06514; Mon, 7 Jan 2002 22:22:52 +0100 Message-ID: <3C3A11AB.4050501@wanda.ch> Date: Mon, 07 Jan 2002 22:22:51 +0100 From: Marcel Waldvogel Organization: WandA -- The Waldvogel and Aschwanden Family User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801 X-Accept-Language: de, en-us MIME-Version: 1.0 To: John Kane CC: IETF-OpenPGP , jwn2@qualcomm.com Subject: Re: new patent app conflicts with pgp References: <3C374B93.A3EBCF85@softhome.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: John, It seems to me that PGP is clear prior art in itself to the relevant claims, so I don't think we should need to worry. -Marcel John Kane wrote: >Someone has applied for a US patent on the technique of >using a symmetric session key on a document, and then using >multiple public keys to encrypt the session key to multiple >recipients. Newton Hammet newton(at)hammet.net brought >this to our attention. > > http://appft1.uspto.gov/netahtml/PTO/srchnum.html > (search for 20010055396) >http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html >http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html > >He cites RSA as prior art, but not RFC1991/RFC2440. >This seems to be in the context of a business model where >a server allows secure access to a symmetrically-encrypted >document by allowing the author to upload multiple >public-key headers for multiple recipients, and to repost >both amended PKI access lists and amended updates of >the document (potentially re-using the orig.sess key). > >However: > [0024] As another example, encrypted decryption keys could > be bundled into the message and the single message with the > encrypted decryption keys could be broadcast to all recipients > without compromising the security of the mechanism. > >-- >John Kane >Stratham, NH (USA) > > > > Received: by above.proper.com (8.11.6/8.11.3) id g07Ge6J28699 for ietf-openpgp-bks; Mon, 7 Jan 2002 08:40:06 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Ge5328695 for ; Mon, 7 Jan 2002 08:40:05 -0800 (PST) Received: by sentry.gw.tislabs.com; id LAA18046; Mon, 7 Jan 2002 11:45:10 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018031; Mon, 7 Jan 02 11:44:45 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07GdUl29792 for ietf-openpgp@imc.org; Mon, 7 Jan 2002 11:39:30 -0500 (EST) Date: Mon, 7 Jan 2002 11:39:30 -0500 (EST) Message-Id: <200201071639.g07GdUl29792@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-openpgp@imc.org Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002 FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml. 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) hosted by THE INTERNET SOCIETY February 6 - 8, 2002 Catamaran Resort Hotel, San Diego, California NDSS is the premier event for security experts around the world. Come to the 9th Annual NDSS and share in the latest concepts on the Internet security front. Southern California's Catamaran Resort Hotel offers spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny getaway with opportunities to confer with your security counterparts from across the globe. For more information and on line registration go to the NDSS'02 web site: http://www.isoc.org/ndss02. Questions about registration? Contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org. Interested in sponsoring a give-away or meal? Contact Martin Kupres at +1 41 22 807 1444 or send e-mail to sponsorndss@isoc.org. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g06G1OO29094 for ietf-openpgp-bks; Sun, 6 Jan 2002 08:01:24 -0800 (PST) Received: from claude.kendall.akamai.com (walrus.ne.mediaone.net [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g06G1N329090 for ; Sun, 6 Jan 2002 08:01:23 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g06G0r309529 for ietf-openpgp@imc.org; Sun, 6 Jan 2002 11:00:53 -0500 Date: Sun, 6 Jan 2002 11:00:53 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Text canonicalization Message-ID: <20020106110053.A9308@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> <20011227193337.F685@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from vedaal@hotmail.com on Fri, Dec 28, 2001 at 08:15:07AM -0500 X-PGP-Key: 2048R/3CB3B415/4D 96 83 18 2B AF BE 45 D0 07 C4 07 51 37 B3 18 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Crescent (45% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Dec 28, 2001 at 08:15:07AM -0500, vedaal wrote: > > This sounds very good, but what about detached signatures? A detached > > signature doesn't carry the text with it, so wouldn't the the text > > (presumably delivered via http or ftp, which can change line endings) > > need to be re-canonicalized for signature verification? To a certain > > degree this applies to a clearsigned document as well. > ... > also applies somewhat to GnuPG signed and encrypted messages when signed > with a v3 rsa key, and GnuPG armored signed messages with a v3 rsa key, > PGP interprets it as a 'detached' signature, > and 'searches' (unsuccessfully) for the file trying to verify it. > {not the case with v4 rsa sigs, which seem to act differently} This is a slightly different problem - GnuPG would never make a non-clear or non-detached signature with v3 keys that PGP 6 or 7 liked. I fixed this a few days ago, and it works properly now. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g05J2mE12097 for ietf-openpgp-bks; Sat, 5 Jan 2002 11:02:48 -0800 (PST) Received: from softhome.net (jive.SoftHome.net [66.54.152.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g05J2l312093 for ; Sat, 5 Jan 2002 11:02:47 -0800 (PST) Received: from softhome.net ([209.6.136.56]) (AUTH: PLAIN jkane89@softhome.net) by softhome.net with esmtp; Sat, 05 Jan 2002 11:47:30 -0700 Message-ID: <3C374B93.A3EBCF85@softhome.net> Date: Sat, 05 Jan 2002 13:53:09 -0500 From: John Kane X-Mailer: Mozilla 4.61 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF-OpenPGP CC: jwn2@qualcomm.com Subject: new patent app conflicts with pgp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Someone has applied for a US patent on the technique of using a symmetric session key on a document, and then using multiple public keys to encrypt the session key to multiple recipients. Newton Hammet newton(at)hammet.net brought this to our attention. http://appft1.uspto.gov/netahtml/PTO/srchnum.html (search for 20010055396) http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011444.html http://lists.gnupg.org/pipermail/gnupg-users/2002-January/011445.html He cites RSA as prior art, but not RFC1991/RFC2440. This seems to be in the context of a business model where a server allows secure access to a symmetrically-encrypted document by allowing the author to upload multiple public-key headers for multiple recipients, and to repost both amended PKI access lists and amended updates of the document (potentially re-using the orig.sess key). However: [0024] As another example, encrypted decryption keys could be bundled into the message and the single message with the encrypted decryption keys could be broadcast to all recipients without compromising the security of the mechanism. -- John Kane Stratham, NH (USA) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04N2Fv23768 for ietf-openpgp-bks; Fri, 4 Jan 2002 15:02:15 -0800 (PST) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04N2D323764 for ; Fri, 4 Jan 2002 15:02:14 -0800 (PST) Received: from [192.168.1.180] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Fri, 4 Jan 2002 15:01:59 -0800 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20011227193337.F685@akamai.com> References: <200112051759.JAA27637@finney.org> <871yi8xnb1.fsf@alberti.gnupg.de> <20011227193337.F685@akamai.com> Date: Fri, 4 Jan 2002 14:58:47 -0800 To: David Shaw , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Text canonicalization Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:33 PM -0500 12/27/01, David Shaw wrote: >This sounds very good, but what about detached signatures? A detached >signature doesn't carry the text with it, so wouldn't the the text >(presumably delivered via http or ftp, which can change line endings) >need to be re-canonicalized for signature verification? To a certain >degree this applies to a clearsigned document as well. > The point of what I'm suggesting is that generating or verifying a signature is always (or almost always) just hashing the data and going on with it, no matter what the mode. Text mode comes in when the processing program can guarantee that the signed data is in canonicalized text. So most detached sigs must be in binary mode, unless the implementation wants to transform the text, or otherwise knows that it's in that format. That's what I mean by it being an assurance. The cryptography is always the same. Text mode means that if you use a well-defined transform from canonical form, it will be in the right character set etc. >Email delivery of the text is a whole other can of worms, though it >could be argued that if it's email, it should be PGP/MIME. I suppose that can be argued, but I argue otherwise. I and many other people delete PGP/MIME without reading, but that's another discussion. (I've actually been planning such a rant, and was composing it in my head. Thanks for the opening.) With regard to text vs. binary, the rule I'm saying is that when you create a signature, and when you verify it, you process the actual bits in a data packet, no matter where that data packet is. The crypto sections of an OpenPGP system ignore the mode. The interesting problem comes, as I understand it, comes from this scenario: Alice puts on an FTP server a text file, foo.txt, and a detached signature, foo.sig. Bob FTPs both files, foo.txt in text mode, and foo.sig in binary mode, and the line ends get changed as part of FTPing the file. Consequently, the signature doesn't verify. I can think of several answers to this scenario: (1) Don't do that, you'll hurt yourself. Come on, digital signatures are fragile and brittle. Text mode operations, be they OpenPGP's, FTP's, or anyone else's, alter text, and that's going to cause problems. (a) Alice puts the file on her system in some well-known format that the right thing will be done with. Examples of this include ZIP files, .tar.gz, .gz, .Z, .sit, etc. The signature is over the container. Bob FTPs them both in binary mode, verifies the signature and unpacks foo.txt. (b) Bob FTPs both files in binary mode and verifies the signature. Then he translates foo.txt, or re-FTPs it in text mode. (c) Bob's OpenPGP program could tell him that the file seems not to be in "canonical text" and that this may be the reason why it didn't verify. This is arguably something of a copout, as it can be irritating to have a program tell you something didn't work, and here's why. I know I always mutter to the system, "You're the computer, if it's that easy, fix it." (2) Bob's OpenPGP program has a heuristic to try to compensate for a text translation. Note that I said try. There are many, many ways this can fail. But there are many ways it can work correctly. If an OpenPGP program (or a wrapper around one -- this is a perfect place to use a perl script) tries the straightforward thing of converting line ends to CRLF, it will probably work just fine. If it tries the next simple attempt -- assume that the text is in ISO Latin-1, and convert it to UTF-8, it will probably get most of the rest. Certainly most mail things will work right with these. (3) Put the text file in an OpenPGP clearsigned message. I suppose this really ought to be (1)(d), as it's another "don't do that" solution. But it works. If the problem is that you have a file that you want to be both directly readable as text and signed, clearsigning is a way to go. I realize that this brings the implementer into a subset of the text heuristic because line ends might flipped around. But it *should* already be put into canonical UTF-8, and thus the problem of figuring out how to verify it is much easier. Jon