From owner-ietf-openpgp@mail.imc.org Tue Feb 12 02:39: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 CAA05539 for ; Tue, 12 Feb 2002 02:39:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1C7K5E22314 for ietf-openpgp-bks; Mon, 11 Feb 2002 23:20:05 -0800 (PST) Received: from mail.uni-bielefeld.de (IDENT:72@mail2.uni-bielefeld.de [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C7K3322303 for ; Mon, 11 Feb 2002 23:20:03 -0800 (PST) Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GRE00I7QSDC1N@mail.uni-bielefeld.de> for ietf-openpgp@imc.org; Tue, 12 Feb 2002 08:20:01 +0100 (MET) Date: Tue, 12 Feb 2002 08:19:41 +0100 From: Marc Mutz Subject: Re: OpenPGP vs. OpenPGP/MIME In-reply-to: To: john.dlugosz@kodak.com, ietf-openpgp@imc.org Message-id: <200202120819.43542@sendmail.mutz.com> Organization: KDE MIME-version: 1.0 X-Mailer: KMail [version 1.3.9] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PGP-Key: 0xBDBFE838 References: 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 On Friday 25 January 2002 18:07, john.dlugosz@kodak.com wrote: > 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. I guess labelling this as re: compatibility is stretching the sense at best. If Notes doesn't handle MIME, what's the point in arguing that PGP/MIME is bad for interop and citing Notes as an example. > 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. As long as MIME parsers follow the rule to treat unknown multipart/* as multipart/mixed, no problem would arise. It's the broken mail software that causes problems here. > 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. - From the point of view of a MIME parser implementor, old-fashioned pgp messages are pure horror. While you can trust that with PGP/MIME signed and/or encrypted body parts are correctly labelled, for plain PGP messages you have to scan all possible body parts (ie. at least those labelled text/plain) to check for pgp message blocks. Worse: Your nice DOM that you built around the concepts of rfc(2)822, rfc2015, rfc204x and friends is totally wrecked when you have to deal with body parts embedded in body parts other that multipart/* or message/*. The same issue arises with uuencoded messages. You have to introduce fake body parts when you want to actually keep your DOM. Don't start to think about those broken flat message digests with multiple pgp message blocks in them :-( OTOH, letting aside the cryptographic functions, implementing rfc1847 is dead easy. > 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. See above for why this is a bad idea. Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aMIO3oWD+L2/6DgRAjOMAJ9NnKy2i4rCUss+sMtvKkxYjJmvMwCgmroj KjCN6jL6OYiLTms/+6VjL+Q= =dy2i -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Feb 12 02:45: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 CAA05581 for ; Tue, 12 Feb 2002 02:45:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C7T9u24251 for ietf-openpgp-bks; Mon, 11 Feb 2002 23:29:09 -0800 (PST) Received: from mail.uni-bielefeld.de (IDENT:72@mail2.uni-bielefeld.de [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C7T4324223 for ; Mon, 11 Feb 2002 23:29:04 -0800 (PST) Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GRE00GL7SSD15@mail.uni-bielefeld.de> for ietf-openpgp@imc.org; Tue, 12 Feb 2002 08:29:02 +0100 (MET) Date: Tue, 12 Feb 2002 08:28:59 +0100 From: Marc Mutz Subject: Re: OpenPGP vs. OpenPGP/MIME In-reply-to: To: Jon Callas , Thomas Roessler , Simon Josefsson Cc: ietf-openpgp@imc.org Message-id: <200202120829.01245@sendmail.mutz.com> Organization: KDE MIME-version: 1.0 X-Mailer: KMail [version 1.3.9] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PGP-Key: 0xBDBFE838 References: <20020124224603.GA3429@sobolev.does-not-exist.org> 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 On Friday 25 January 2002 01:48, Jon Callas wrote: > 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. So we should prolong the lifespan of a broken design (just think i18n) just because the mime interop of some widely deployed mail software is less than optimal? What about encouraging people to implement PGP/MIME and see its wide deployment force others to fix their stuff? Just the opinion of someone implementing of a MIME parser: Plain pgp is ugly as hell, PGP/MIME resp. rfc1847 sucks much less. Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aMQ83oWD+L2/6DgRAt+HAKCeWc2K6gwdgissULdwxB2u+tcjMQCg9Ycz ncJLzXIiRSGx11o5HLL2CkA= =DTck -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 13 00:20: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 AAA09170 for ; Wed, 13 Feb 2002 00:20:24 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D545r25337 for ietf-openpgp-bks; Tue, 12 Feb 2002 21:04:05 -0800 (PST) Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D544325333 for ; Tue, 12 Feb 2002 21:04:04 -0800 (PST) Received: from p4 ([12.224.51.110]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020213050404.KMZT1214.rwcrmhc54.attbi.com@p4>; Wed, 13 Feb 2002 05:04:04 +0000 Message-Id: <3.0.5.32.20020212210415.01c95008@localhost> X-Sender: cme@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 Feb 2002 21:04:15 -0800 To: Jon Callas , ietf-openpgp@imc.org From: Carl Ellison Subject: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh In-Reply-To: <200202120829.01245@sendmail.mutz.com> References: <20020124224603.GA3429@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D544325334 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone know why PGP/MIME messages from Mutt consistently crash Eudora while those from Evolution or exmh don’t? One would think that a good standard wouldn’t allow any such variability. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPGnzz3PxfjyW5ytxEQLhJgCgp9w4C3w34EPKarXNkwrSJkQACfQAn0g4 KNIqsxq11W3VB2Wz1kYx/Q/c =ZpBn -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://world.std.com/~cme | | PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+ From owner-ietf-openpgp@mail.imc.org Wed Feb 13 00:38: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 AAA10506 for ; Wed, 13 Feb 2002 00:38:37 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D5OrM25785 for ietf-openpgp-bks; Tue, 12 Feb 2002 21:24:53 -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 g1D5Oq325780 for ; Tue, 12 Feb 2002 21:24:52 -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 GRGKH400.55M; Tue, 12 Feb 2002 22:24:40 -0800 Message-ID: <3C69F8A6.86DB7647@cyphers.net> Date: Tue, 12 Feb 2002 21:24:54 -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: Carl Ellison CC: ietf-openpgp@imc.org Subject: Re: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh References: <20020124224603.GA3429@sobolev.does-not-exist.org> <3.0.5.32.20020212210415.01c95008@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D5Oq325781 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, it is because you're using an old version of PGP (6.5.8) which was released in June of 1999 (in other words, many years ago). In recent versions, we accomodated the Mutt way of encoding PGP/MIME. I don't recall exactly which version that went into. The current Eudora plugin version is 7.1.1 which is of course part of PGP 7.1.1. Carl Ellison wrote: > Does anyone know why PGP/MIME messages from Mutt consistently crash > Eudora while those from Evolution or exmh don’t? > > One would think that a good standard wouldn’t allow any such > variability. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 (Build 151) Beta iQA/AwUBPGn4nKy7FkvPc+xMEQIzlgCdE7nJM3KVDq58+nvLwBTqWNnzCxgAn3/P 3n/9TJ+KF79Q9yiTqgXy3jpw =I69h -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 13 03:05: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 DAA22506 for ; Wed, 13 Feb 2002 03:05:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D7nbk08730 for ietf-openpgp-bks; Tue, 12 Feb 2002 23:49:37 -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 g1D7nY308726 for ; Tue, 12 Feb 2002 23:49:35 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Wed, 13 Feb 2002 09:44:05 0200 Message-ID: <3C6A1945.9D6B25EB@saiknes.lv> Date: Wed, 13 Feb 2002 09:44:05 +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: OpenPGP vs. OpenPGP/MIME 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 PGP/MIME is evil. can not save message to disk and decrypt and/or verify later outside MUA, some virus checking software removes attachments, does not work with many mailing lists (that are configured to remove attachments), does not work with web archives of mailing lists (for example http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html), does not work with newsgroups. __ 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/AwUBPGn8yjBaTVEuJQxkEQMUzQCeLUZwDzQvKzAQSs2W/Pjjn2jJKl4AoIh8 5CpDyEHwN/ceJqcN9ZdvtHs5 =eFfP -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 13 04:18:50 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 EAA24368 for ; Wed, 13 Feb 2002 04:18:50 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D91lj21153 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:01:47 -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 g1D91j321139 for ; Wed, 13 Feb 2002 01:01:45 -0800 (PST) Subject: Need some explanations about privarte key in OpenPGP format Date: Wed, 13 Feb 2002 11:01:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: Need some explanations about privarte key in OpenPGP format Thread-Index: AcG0bRt+tIORbBYdS7ulqicxphY8EA== From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D91k321147 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi! I read and re-read the rfc 2440 and I am confused about few things. (from http://www.imc.org/draft-ietf-openpgp-rfc2440bis) ... 5.5.3. Secret Key Packet Formats The Secret Key and Secret Subkey packets contain all the data of the Public Key and Public Subkey packets, with additional algorithm-specific secret key data appended, in encrypted form. The packet contains: - A Public Key or Public Subkey packet, as described above - One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm specifier. - [Optional] If string-to-key usage octet was 255, a one-octet symmetric encryption algorithm. - [Optional] If string-to-key usage octet was 255, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above. So far so good. - [Optional] If secret data is encrypted, Initial Vector (IV) of the same length as the cipher's block size. - Encrypted multi-precision integers comprising the secret key data. These algorithm-specific fields are as described below. - Two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536). This checksum is encrypted together with the algorithm- specific fields. I have some questions about the last three paragraphs: - Is the Initial Vector encrypted with the algorithm-specific portion? - In case that the Initial Vector is encrypted with the algorithm-specific portion, does the plain text of the the algorithm-specific portion, on that the checksum is made, include the Initial vector or not? - Let's assume that I encrypt the algorithm-specific portion with IDEA. What it happens if the length of the algorithm-specific portion is not multiple of 8 (64 bit)? How can I fill the last block of the algorithm-specific portion to be an 8 byte (64 bit) block? Is anybody who can answer to my questions? Thank you in advance, Cornel Gligan-Ignatescu From owner-ietf-openpgp@mail.imc.org Wed Feb 13 05:01:32 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 FAA25099 for ; Wed, 13 Feb 2002 05:01:32 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1D9m1A28177 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:48:01 -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 g1D9lx328173 for ; Wed, 13 Feb 2002 01:47:59 -0800 (PST) Received: from sobolev.does-not-exist.org (unknown [62.144.244.99]) by mail.mediacompany.com (Postfix) with ESMTP id 4A6BB4802; Wed, 13 Feb 2002 10:47:46 +0100 (CET) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 3CC552ED19; Wed, 13 Feb 2002 10:45:11 +0100 (CET) Date: Wed, 13 Feb 2002 10:45:11 +0100 From: Thomas Roessler To: ietf-openpgp@imc.org, Will Price Subject: Re: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh Message-ID: <20020213094511.GZ6830@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org, Will Price References: <20020124224603.GA3429@sobolev.does-not-exist.org> <3.0.5.32.20020212210415.01c95008@localhost> <3C69F8A6.86DB7647@cyphers.net> <20020124224603.GA3429@sobolev.does-not-exist.org> <3.0.5.32.20020212210415.01c95008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3C69F8A6.86DB7647@cyphers.net> <3.0.5.32.20020212210415.01c95008@localhost> User-Agent: Mutt/1.5.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-02-12 21:04:15 -0800, Carl Ellison wrote: >One would think that a good standard wouldn't allow any such >variability. One would also think that a good implementation won't crash when encountering standard compliant messages (it shouldn't even crash when receiving junk). On 2002-02-12 21:24:54 -0800, Will Price wrote: >In recent versions, we accomodated the Mutt way of encoding >PGP/MIME. I don't recall exactly which version that went into. The >current Eudora plugin version is 7.1.1 which is of course part of >PGP 7.1.1. May I ask what particular detail of mutt's way of encoding had to be specifically accomodated? I'm asking because _if_ mutt is violating the standard, this would be something I'd really like to see fixed. (Yes, I am aware that earlier versions of mutt have possibly generated wrong micalg parameters, unless users paid attention. This particular problem has, however, been fixed quite thoroughly.) Writing with the "current mutt maintainer" hat, -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Wed Feb 13 05:06:29 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 FAA25191 for ; Wed, 13 Feb 2002 05:06:29 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D9rdZ28326 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:53:39 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1D9rc328322 for ; Wed, 13 Feb 2002 01:53:38 -0800 (PST) Received: (cpmta 11128 invoked from network); 13 Feb 2002 01:53:32 -0800 Received: from 217.82.92.236 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 13 Feb 2002 01:53:32 -0800 X-Sent: 13 Feb 2002 09:53:32 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE To: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Date: Wed, 13 Feb 2002 10:53:17 +0100 X-Mailer: KMail [version 1.3.9] References: <3C6A1945.9D6B25EB@saiknes.lv> In-Reply-To: <3C6A1945.9D6B25EB@saiknes.lv> X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Message-Id: <200202131053.18910@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D9rc328323 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 13 February 2002 08:44, disastry@saiknes.lv wrote: > PGP/MIME is evil. I disagree. pgp/miem isn't evil at all. It's the broken mail software out there that is the problem. And I restate that deprecating pgp/mime (or whatever this should lead to) will take the strain off of those "vendors" to fix their "products"... > can not save message to disk and decrypt and/or verify later outside > MUA, For "decrypt", this is usually wrong, since exactly one part contains the encrypted data, the other only contains metadata, which is either superfluous or could be translated into options for the OpenPGP backend when decrypting... So the real problem is signing: The MUA could offer to convert the multipart/signed part to a file/detached sig pair of files on save. Remember: You can't also view asian text/plain, wihc is usually encoded in base64, without the help of the MUA. > some virus checking software removes attachments, which is broken behaviour... > does not work with many mailing lists (that are configured to remove > attachments), those ml's are broken (since multipart/signed is _not_ an attachment). > does not work with web archives of mailing lists (for > example http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html), broken software used there, too. > does not work with newsgroups. Care to explain what's the problem there? So why are all those packages broken? Because pgp/mime is so rare that they don't need to fix their stuff. Marc - -- Marc Mutz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ajeN3oWD+L2/6DgRArrOAKCcP+SvN6sXtJDTFn8iVrLK3EUnegCePj2p AhtyoZ0724pmBvNxC+2BpjU= =o0f3 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 13 05:07:45 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 FAA25239 for ; Wed, 13 Feb 2002 05:07:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D9rBb28312 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:53:11 -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 g1D9r9328307 for ; Wed, 13 Feb 2002 01:53:09 -0800 (PST) Received: from sobolev.does-not-exist.org (unknown [194.162.148.86]) by mail.mediacompany.com (Postfix) with ESMTP id 240CE4802; Wed, 13 Feb 2002 10:53:08 +0100 (CET) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id DAF112ED15; Wed, 13 Feb 2002 10:50:05 +0100 (CET) Date: Wed, 13 Feb 2002 10:50:05 +0100 From: Thomas Roessler To: disastry@saiknes.lv Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020213095005.GA6830@sobolev.does-not-exist.org> Mail-Followup-To: disastry@saiknes.lv, ietf-openpgp@imc.org References: <3C6A1945.9D6B25EB@saiknes.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3C6A1945.9D6B25EB@saiknes.lv> User-Agent: Mutt/1.5.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-02-13 09:44:05 +0200, disastry@saiknes.lv wrote: >can not save message to disk and decrypt and/or verify later >outside MUA, Where do you get the expectation from that you can handle e-mail messages without software able to parse their format? (And, BTW, you can certainly do all you desire outside the MUA. You just have to do some _very_ basic MIME parsing yourself. >some virus checking software removes attachments, Such virus checking software is broken. >does not work with many mailing lists (that are configured to >remove attachments), Such mailing lists are broken. >does not work with web archives of mailing lists (for example >http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html), That's not an example for PGP/MIME, but an example for mailing list archiving software not being able to cope with RFC announcements as sent out by the RFC editor. This is another instance of broken software. Nice try, though. >does not work with newsgroups. Why not? -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Wed Feb 13 05:35:29 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 FAA26091 for ; Wed, 13 Feb 2002 05:35:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DA4XA00371 for ietf-openpgp-bks; Wed, 13 Feb 2002 02:04:33 -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 g1DA4V300366 for ; Wed, 13 Feb 2002 02:04:31 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16awnM-0001eg-00; Wed, 13 Feb 2002 11:37:48 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16awEe-0008FM-00; Wed, 13 Feb 2002 11:01:56 +0100 To: "Cornel GLIGAN" Cc: Subject: Re: Need some explanations about privarte key in OpenPGP format References: From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Wed, 13 Feb 2002 11:01:55 +0100 In-Reply-To: ("Cornel GLIGAN"'s message of "Wed, 13 Feb 2002 11:01:43 +0200") Message-ID: <87vgd1wvho.fsf@alberti.gnupg.de> Lines: 58 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=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Feb 2002 11:01:43 +0200, Cornel GLIGAN said: > I have some questions about the last three paragraphs: > - Is the Initial Vector encrypted with the algorithm-specific > portion? The IV is a parameter to the CFB (Cipher Feed Back) encryption mode. > - Let's assume that I encrypt the algorithm-specific portion with > IDEA. What it happens if the length of the algorithm-specific portion is > not multiple of 8 (64 bit)? How can I fill the last block of the > algorithm-specific portion to be an 8 byte (64 bit) block? Padding is not required with CFB. Don't hardwire the 64 bits; you have to use the blocksize of the used cipher (e.g. 128 for AES). You find more information about encryption modes in the standard literature: @Book{Men:96:HAC, author = "Alfred J. Menezes and Paul van Oorschot and Scott Vanstone", title = "Handbook of Applied Cryptography", language = "USenglish", publisher = pub-CRC, address = pub-CRC:adr, pages = "xxvii + 780", year = "1996", ISBN = "0-8493-8523-7", keywords = "cryptograpy", } There is an online resource for it, IIRC: http://cacr.math.uwaterloo.ca/hac/ or @Book{Sch:96:AC, author = "Bruce Schneier", title = "Applied Cryptography", language = "USenglish", edition = "second", publisher = pub-WIL, address = pub-WIL:adr, pages = "xxiii + 758", year = "1996", ISBN = "0-471-11709-9", } Hth, Werner -- Werner Koch Omnis enim res, quae dando non deficit, dum habetur g10 Code GmbH et non datur, nondum habetur, quomodo habenda est. Privacy Solutions -- Augustinus From owner-ietf-openpgp@mail.imc.org Wed Feb 13 06:55:51 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 GAA28236 for ; Wed, 13 Feb 2002 06:55:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DBbCk08446 for ietf-openpgp-bks; Wed, 13 Feb 2002 03:37:12 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DBbA308442 for ; Wed, 13 Feb 2002 03:37:10 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id g1DBbAp13147; Wed, 13 Feb 2002 11:37:10 GMT Message-ID: <15pcYfZa+ka8IA0i@pillar.turnpike.com> Date: Wed, 13 Feb 2002 11:35:54 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: OpenPGP vs. OpenPGP/MIME References: <3C6A1945.9D6B25EB@saiknes.lv> In-Reply-To: <3C6A1945.9D6B25EB@saiknes.lv> MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Turnpike/6.01-Alpha-6-M () Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Feb 2002, disastry@saiknes.lv wrote: >PGP/MIME is evil. It is the only sensible way to properly secure an entire MIME message with PGP. In the case of signed messages, it allows the recipient to be sure that the sender signed _all_ of the message, including attachments: it allows arbitrarily complex messages to be signed successfully: in principle it allows the sender to send a signed message to a group of people, some of whom are not interested in PGP at all since the act of signing does not pollute the actual message in any way. Of course the last point depends on basic MIME compliance of users' MUAs, and there are some common clients that treat multipart/unknown differently to multipart/mixed :-(( In the case of encrypted messages, it allows the sender to be sure that no-one intercepting the message can know if any attachments are present and what types of attachments there are. It allows encryption of arbitrarily complex messages. >can not save message to disk and decrypt the decryption is easy; but you will be left with a MIME message which will need to be interpreted (by munpack etc) which is a barrier. Best thing is to encourage PGP/MIME support in MUAs. >and/or verify later outside MUA, verify is easy if the message source is available. >some virus checking software removes attachments, some virus checking software removes/quarantines _all_ PGP encrypted material. >does not work with many mailing lists (that are configured to remove >attachments), Best thing is to encourage PGP/MIME support in mailing-lists. [[ Actually, best thing is to encourage MIME support in mailing lists (some lists append text material to the end of messages - which in the case of multipart/* messages gets hidden by MIME MUAs!) ]] >does not work with newsgroups. have a look at alt.security.pgp and see how much PGP clear-signed material is quoted/requoted etc Many messages consist mainly of redundant fragments of quoted ascii-armor. This seems to me to be a serious barrier to the routine use of PGP in newsgroups/mailing-lists. How about the opposite contention: "Clear-signed messages are evil" The ascii-armor is intrusive, so that the use of PGP is restricted to arenas where people will put up with such material "in their faces". The ascii-armor breaks the UseNet signature convention ("-- " becomes "- -- "): another barrier to routine use of PGP in UseNet. Clear signing is often done "behind the MUAs back" - leading to wrapping problems (how many users have to be told how to balance the wrapping action of their MUAs against the wrapping action of their PGP settings?) Clear-signing starts breaking when messages are not simple us-ascii and can't be used to properly secure messages with attachments. [As an example of the first case, I will clear sign this message via the clipboard. The signature will fail. because the '€' character will be signed by PGP as a Windows-1252 character (which is what the clipboard will contain), but my MUA will send it utf-8.] In practice, clear-signing can be made to interoperate for simple us- ascii messages, and PGP/MIME support is indeed patchy, but I hope PGP/MIME support does grow because of its inherent advantages. And if it doesn't, the "world's most popular clients" can still sign and encrypt arbitrary MIME messages securely - they include seamless S/MIME support. - -- Ian Bell T U R N P I K E -----BEGIN PGP SIGNATURE----- Version: PGP 7.1 iQA/AwUBPGpO573aNYn/fmK7EQL3YACfTxQv/5/eL2F+i33MIvIQMkNwONAAn26A QNdP0tJK59utXegMPXCjcwT7 =bSLW -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 13 14:39:49 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 OAA18676 for ; Wed, 13 Feb 2002 14:39:48 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DJJfl28657 for ietf-openpgp-bks; Wed, 13 Feb 2002 11:19:41 -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 g1DJJe328653 for ; Wed, 13 Feb 2002 11:19:40 -0800 (PST) Received: from [192.168.1.19] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for ; Wed, 13 Feb 2002 11:19:39 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20020213095005.GA6830@sobolev.does-not-exist.org> References: <3C6A1945.9D6B25EB@saiknes.lv> <20020213095005.GA6830@sobolev.does-not-exist.org> Date: Wed, 13 Feb 2002 11:09:45 -0800 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: 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: At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: >>does not work with many mailing lists (that are configured to >>remove attachments), > >Such mailing lists are broken. As someone who runs a number of such "broken" mailing lists, I "broke" them because I consider the security risk of my list being use to spread the latest Outlook thingie to be much higher than the damage caused by breaking them. It also prevents the inevitable newbie who sends a picture or movie as an attachment, causing a dozen people to go over their mail quotas. My message to my users is that if it's important, put it somewhere and provide a URL. If it's important, I'll even provide disk space for it. I must respectfully disagree with this assessment. People who maintain computer systems used by a number of people have a responsibility to protect that shared resource. Stopping attachments on mailing lists is not any more "broken" than putting up a firewall is. Jon From owner-ietf-openpgp@mail.imc.org Thu Feb 14 04:38: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 EAA14159 for ; Thu, 14 Feb 2002 04:38:16 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1E9C8M10202 for ietf-openpgp-bks; Thu, 14 Feb 2002 01:12:08 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1E9C6310195 for ; Thu, 14 Feb 2002 01:12:06 -0800 (PST) Received: (cpmta 7664 invoked from network); 14 Feb 2002 01:12:01 -0800 Received: from 129.70.24.67 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 14 Feb 2002 01:12:01 -0800 X-Sent: 14 Feb 2002 09:12:01 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE To: Jon Callas , ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Date: Wed, 13 Feb 2002 23:09:53 +0100 X-Mailer: KMail [version 1.3.9] References: <3C6A1945.9D6B25EB@saiknes.lv> <20020213095005.GA6830@sobolev.does-not-exist.org> In-Reply-To: X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Message-Id: <200202132309.55041@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1E9C6310196 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 13 February 2002 20:09, Jon Callas wrote: > At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: > >>does not work with many mailing lists (that are configured to > >>remove attachments), > > > >Such mailing lists are broken. > I must respectfully disagree with this assessment. People who > maintain computer systems used by a number of people have a > responsibility to protect that shared resource. Stopping attachments > on mailing lists is not any more "broken" than putting up a firewall > is. A mailing list software isn't broken because it filters out attachments, but because it can't distinguish pgp/mime signed plain text messages from attachments. Not everything consisting of a mulitpart contains an attachment. In fact, it would be totally legal for me to always send multipart messages, where, for instance, the first nested body part contains the text of the mail and the secons one my signature. I can't speak for Thomas, but that's probably what he meant: That mailing list software needs to be able to distinguish between attachments and signed messages. (Though I can understand why Thomas could find ml's which filter all "attachments" broken: You can't even forward a message to them (needs a multipart/mixed with nested message/rfc822 - eek)). Marc - -- Marc Mutz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8auQx3oWD+L2/6DgRAlJPAKCrS7BzalfRAck+5T2X+RipCbz7vgCePn2e Vq6YiYsBw36Qd/aF0cXA54U= =cA/N -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Feb 14 04:43: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 EAA14273 for ; Thu, 14 Feb 2002 04:43:52 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1E9Od211384 for ietf-openpgp-bks; Thu, 14 Feb 2002 01:24:39 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E9Ob311374 for ; Thu, 14 Feb 2002 01:24:37 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id g1E9Oap11511; Thu, 14 Feb 2002 09:24:36 GMT Message-ID: Date: Thu, 14 Feb 2002 09:23:22 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: OpenPGP vs. OpenPGP/MIME References: <3C6A1945.9D6B25EB@saiknes.lv> <20020213095005.GA6830@sobolev.does-not-exist.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed;boundary="=_Turnpike_KjRzeFB6H4a84L4A="; protocol="application/pgp-signature";micalg=pgp-sha1 User-Agent: Turnpike/6.01-Alpha-6-M () Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a PGP signed message sent according to RFC3156 [PGP/MIME] --=_Turnpike_KjRzeFB6H4a84L4A= Content-Type: text/plain;charset=us-ascii;format=flowed Content-Transfer-Encoding: quoted-printable On Wed, 13 Feb 2002, Jon Callas wrote: > >At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: > >>>does not work with many mailing lists (that are configured to >>>remove attachments), >> >>Such mailing lists are broken. [] >I must respectfully disagree with this assessment. People who maintain >computer systems used by a number of people have a responsibility to >protect that shared resource. Stopping attachments on mailing lists is not >any more "broken" than putting up a firewall is. Yes, but there is no reason why mailing-list software should regard=20 application/pgp-signature as an "attachment" when protecting=20 mailing-lists against misplaced or dangerous attachments. (This sent PGP/MIME signed, just to see what happens on this list!) --=20 Ian Bell T U R N P I K E --=_Turnpike_KjRzeFB6H4a84L4A= Content-Type: application/pgp-signature Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: PGPsdk 2.1a246 iQA/AwUAPGuCCL3aNYn/fmK7EQJqQgCeO39or+XFgS7IpxEjHCWQXqZQVYQAnjTc 5L/pjQ/TLzgMXJU1sek1Z5Eh =ITJC -----END PGP SIGNATURE----- --=_Turnpike_KjRzeFB6H4a84L4A=-- From owner-ietf-openpgp@mail.imc.org Thu Feb 14 10:27:29 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 KAA24117 for ; Thu, 14 Feb 2002 10:27:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EF3XA04610 for ietf-openpgp-bks; Thu, 14 Feb 2002 07:03:33 -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 g1EF3V304606 for ; Thu, 14 Feb 2002 07:03:31 -0800 (PST) Subject: Need some explanations about privarte key in OpenPGP format, CFB mode Date: Thu, 14 Feb 2002 17:03:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: Need some explanations about privarte key in OpenPGP format Thread-Index: AcG0bRt+tIORbBYdS7ulqicxphY8EAA+iUoA From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1EF3W304607 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi! I tried to store a private key in OpenPGP format, using the CFB mode as described in http://www.imc.org/draft-ietf-openpgp-rfc2440bis : 12.8. OpenPGP CFB mode OpenPGP does symmetric encryption using a variant of Cipher Feedback Mode (CFB mode). This section describes the procedure it uses in detail. This mode is what is used for Symmetrically Encrypted Data Packets; the mechanism used for encrypting secret key material is similar, but described in those sections above. In the description below, the value BS is the block size in octets of the cipher. Most ciphers have a block size of 8 octets. The AES and Twofish have a blocksize of 16 octets. Also note that the description below assumes that the IV and CFB arrays start with an index of 1 (unlike the C language, which assumes arrays start with a zero index). OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB "resync" after encrypting those BS+2 octets. Thus, for an algorithm that has a block size of 8 octets (64 bits), the IV is 10 octets long and octets 7 and 8 of the IV are the same as octets 9 and 10. For an algorithm with a blocksize of 16 octets (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key. Step by step, here is the procedure: 1. The feedback register (FR) is set to the IV, which is all zeros. 2. FR is encrypted to produce FRE (FR Encrypted). This is the encryption of an all-zero value. 3. FRE is xored with the first BS octets of random data prefixed to the plaintext to produce C[1] through C[BS], the first BS octets of ciphertext. 4. FR is loaded with C[1] through C[BS]. 5. FR is encrypted to produce FRE, the encryption of the first BS octets of ciphertext. 6. The left two octets of FRE get xored with the next two octets of data that were prefixed to the plaintext. This produces C[BS+1] and C[BS+2], the next two octets of ciphertext. 7. (The resync step) FR is loaded with C[3] through C[BS+2]. 8. FR is encrypted to produce FRE. 9. FRE is xored with the first BS octets of the given plaintext, now that we have finished encrypting the BS+2 octets of prefixed data. This produces C[BS+3] through C[BS+(BS+2)], the next BS octets of ciphertext. 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block). 11. FR is encrypted to produce FRE. 12. FRE is xored with the next BS octets of plaintext, to produce the next BS octets of ciphertext. These are loaded into FR and the process is repeated until the plaintext is used up. Is anybody who can explain to me in details how CFB works because I am very confused. I didn't understand anything after I read this text? Thank you in advance, Cornel Gligan-Ignatescu From owner-ietf-openpgp@mail.imc.org Thu Feb 14 10:42: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 KAA24887 for ; Thu, 14 Feb 2002 10:42:39 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EFNLt05998 for ietf-openpgp-bks; Thu, 14 Feb 2002 07:23:21 -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 g1EFNK305993 for ; Thu, 14 Feb 2002 07:23:20 -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 KAA18959; Thu, 14 Feb 2002 10:23:19 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12357; Thu, 14 Feb 2002 10:23:16 -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 KAA09481; Thu, 14 Feb 2002 10:23:12 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA06737; Thu, 14 Feb 2002 10:23:11 -0500 (EST) To: "Cornel GLIGAN" Cc: Reply-To: From: Derek Atkins Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode References: Date: 14 Feb 2002 10:23:11 -0500 In-Reply-To: Message-ID: Lines: 95 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: What, in particular, are you confused about? (comment inline) "Cornel GLIGAN" writes: > Hi! > > I tried to store a private key in OpenPGP format, using the CFB mode as > described in http://www.imc.org/draft-ietf-openpgp-rfc2440bis : > > 12.8. OpenPGP CFB mode > > OpenPGP does symmetric encryption using a variant of Cipher Feedback > Mode (CFB mode). This section describes the procedure it uses in > detail. This mode is what is used for Symmetrically Encrypted Data > Packets; the mechanism used for encrypting secret key material is > similar, but described in those sections above. > > In the description below, the value BS is the block size in octets > of the cipher. Most ciphers have a block size of 8 octets. The AES > and Twofish have a blocksize of 16 octets. Also note that the > description below assumes that the IV and CFB arrays start with an > index of 1 (unlike the C language, which assumes arrays start with a > zero index). > > OpenPGP CFB mode uses an initialization vector (IV) of all zeros, > and prefixes the plaintext with BS+2 octets of random data, such > that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB > "resync" after encrypting those BS+2 octets. > > Thus, for an algorithm that has a block size of 8 octets (64 bits), > the IV is 10 octets long and octets 7 and 8 of the IV are the same > as octets 9 and 10. For an algorithm with a blocksize of 16 octets > (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate > octets 15 and 16. Those extra two octets are an easy check for a > correct key. > > Step by step, here is the procedure: > > 1. The feedback register (FR) is set to the IV, which is all zeros. What this really says is "The CFB feedback register, which acts at the Initialization Vector as per the CFB FIPS, is initialized to all zeros. > 2. FR is encrypted to produce FRE (FR Encrypted). This is the > encryption of an all-zero value. > > 3. FRE is xored with the first BS octets of random data prefixed to > the plaintext to produce C[1] through C[BS], the first BS octets > of ciphertext. > > 4. FR is loaded with C[1] through C[BS]. > > 5. FR is encrypted to produce FRE, the encryption of the first BS > octets of ciphertext. > > 6. The left two octets of FRE get xored with the next two octets of > data that were prefixed to the plaintext. This produces C[BS+1] > and C[BS+2], the next two octets of ciphertext. > > 7. (The resync step) FR is loaded with C[3] through C[BS+2]. > > 8. FR is encrypted to produce FRE. > > 9. FRE is xored with the first BS octets of the given plaintext, > now that we have finished encrypting the BS+2 octets of prefixed > data. This produces C[BS+3] through C[BS+(BS+2)], the next BS > octets of ciphertext. > > 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 > for an 8-octet block). > > 11. FR is encrypted to produce FRE. > > 12. FRE is xored with the next BS octets of plaintext, to produce > the next BS octets of ciphertext. These are loaded into FR and > the process is repeated until the plaintext is used up. > > Is anybody who can explain to me in details how CFB works because I am > very confused. I didn't understand anything after I read this text? Well, it's explained pretty thoroughly above. The step-by-step instructions pretty much tell you what you need to know. What exactly are you confused about? > Thank you in advance, > > Cornel Gligan-Ignatescu -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Thu Feb 14 13:01: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 NAA02539 for ; Thu, 14 Feb 2002 13:01:03 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EHi7T11346 for ietf-openpgp-bks; Thu, 14 Feb 2002 09:44:07 -0800 (PST) Received: from smtpout.mac.com ([204.179.120.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EHi6311342 for ; Thu, 14 Feb 2002 09:44:06 -0800 (PST) Received: from smtp-relay02.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g1EHi7oU011119 for ; Thu, 14 Feb 2002 09:44:07 -0800 (PST) Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay02.mac.com (Netscape Messaging Server 4.15 relay02 Jun 21 2001 23:53:48) with ESMTP id GRJALI00.PEK for ; Thu, 14 Feb 2002 09:44:06 -0800 Received: from [192.68.187.6] ([208.180.64.78]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GRJALI00.R30 for ; Thu, 14 Feb 2002 09:44:06 -0800 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 14 Feb 2002 11:44:03 -0600 Subject: rfc2015bis From: Kyser Soze To: OpenPGP Message-ID: 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 Hi, I searched the net, there are references to rfc2015bis, but I can't seem to download it from anywhere. Where can it get it from? Thanks K. From owner-ietf-openpgp@mail.imc.org Thu Feb 14 14:37: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 OAA07640 for ; Thu, 14 Feb 2002 14:37:19 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EJKWL16513 for ietf-openpgp-bks; Thu, 14 Feb 2002 11:20:32 -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 g1EJKU316507 for ; Thu, 14 Feb 2002 11:20:30 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16bRxM-00017d-00; Thu, 14 Feb 2002 20:54:12 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16bRNZ-0003Ke-00; Thu, 14 Feb 2002 20:17:13 +0100 To: OpenPGP CC: Kyser Soze Subject: Re: rfc2015bis References: From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 14 Feb 2002 20:17:13 +0100 In-Reply-To: (Kyser Soze's message of "Thu, 14 Feb 2002 11:44:03 -0600") Message-ID: <87g043ub46.fsf@alberti.gnupg.de> Lines: 19 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=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 14 Feb 2002 11:44:03 -0600, Kyser Soze said: > I searched the net, there are references to rfc2015bis, but I can't seem > to download it from anywhere. Where can it get it from? This has been published ad rfc3156. BTW, we need to release another draft: draft-ietf-openpgp-rfc2440bis-03.txt Expires Feb 2002 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 Feb 14 16:02: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 QAA09609 for ; Thu, 14 Feb 2002 16:02:07 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1EKbL122250 for ietf-openpgp-bks; Thu, 14 Feb 2002 12:37:21 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1EKbJ322241 for ; Thu, 14 Feb 2002 12:37:19 -0800 (PST) Received: (cpmta 28573 invoked from network); 14 Feb 2002 12:37:15 -0800 Received: from 217.225.22.235 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 14 Feb 2002 12:37:15 -0800 X-Sent: 14 Feb 2002 20:37:15 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE To: Kyser Soze , OpenPGP Subject: Re: rfc2015bis Date: Thu, 14 Feb 2002 21:34:56 +0100 X-Mailer: KMail [version 1.3.9] References: In-Reply-To: X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Message-Id: <200202142135.00392@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1EKbK322242 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 14 February 2002 18:44, Kyser Soze wrote: > Hi, > I searched the net, there are references to rfc2015bis, but I > can't seem to download it from anywhere. Where can it get it from? It's already an rfc (3152 or 3156 - I always keep forgetting). Marc - -- Marc Mutz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8bB9w3oWD+L2/6DgRArNlAKDFeT5THpUw1EVeE+Wcy7MqUHcbOgCdHACS Q0sj+5N7wlzXx0seEVItZj8= =zwRD -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Feb 15 02:05: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 CAA24971 for ; Fri, 15 Feb 2002 02:05:01 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1F6lqL11506 for ietf-openpgp-bks; Thu, 14 Feb 2002 22:47:52 -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 g1F6lo311502 for ; Thu, 14 Feb 2002 22:47:51 -0800 (PST) Subject: RE: Need some explanations about privarte key in OpenPGP format, CFB mode Date: Fri, 15 Feb 2002 08:47:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: Need some explanations about privarte key in OpenPGP format, CFB mode Thread-Index: AcG1a5TOmj5/Hv5PTjSvDTXVS56KFgAe8Rdw From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1F6lq311503 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hi! First fo all, I want to thank you for you answer me. Here are my problems: >OpenPGP does symmetric encryption using a variant of Cipher Feedback >Mode (CFB mode). This section describes the procedure it uses in >detail. This mode is what is used for Symmetrically Encrypted Data >Packets; the mechanism used for encrypting secret key material is >similar, but described in those sections above. In the "secret key material" section I found this: >Encryption/decryption of the secret data is done in CFB mode using >the key created from the passphrase and the Initial Vector from the >packet. (and now, back to the CFB mode) >OpenPGP CFB mode uses an initialization vector (IV) of all zeros, >and prefixes the plaintext with BS+2 octets of random data, such >that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB >"resync" after encrypting those BS+2 octets. I want to mention that I want to keep a secret key in format OpenPGP not a plain text. 1) What value should I fill in IV? 2) Are those BS+2 octets just for plain text or even for secret key material? >3. FRE is xored with the first BS octets of random data prefixed to >the plaintext to produce C[1] through C[BS], the first BS octets >of ciphertext. 3) Do the C[i] octets represent the final form for OpenPGP format? >12. FRE is xored with the next BS octets of plaintext, to produce >the next BS octets of ciphertext. These are loaded into FR and >the process is repeated until the plaintext is used up. 4) Let's assume that I encrypt the algorithm-specific portion with IDEA. What it happens with the last block of data if the length of the algorithm-specific portion is not multiple of 8 (64 bit)? (and, of course, the last block it will be less than BS - in this case 8 octets) Thank you in advance, Cornel Gligan-Ignatescu From owner-ietf-openpgp@mail.imc.org Fri Feb 15 09:49: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 JAA06946 for ; Fri, 15 Feb 2002 09:49:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FEQJh00511 for ietf-openpgp-bks; Fri, 15 Feb 2002 06:26:19 -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 g1FEQI300503 for ; Fri, 15 Feb 2002 06:26:18 -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 JAA14420; Fri, 15 Feb 2002 09:26:18 -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 JAA24305; Fri, 15 Feb 2002 09:26:18 -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 JAA16900; Fri, 15 Feb 2002 09:26:16 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA27954; Fri, 15 Feb 2002 09:26:15 -0500 (EST) To: "Cornel GLIGAN" Cc: From: Derek Atkins Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode References: Date: 15 Feb 2002 09:26:15 -0500 In-Reply-To: Message-ID: Lines: 80 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: "Cornel GLIGAN" writes: > Hi! > > First fo all, I want to thank you for you answer me. > > Here are my problems: > > >OpenPGP does symmetric encryption using a variant of Cipher Feedback > >Mode (CFB mode). This section describes the procedure it uses in > >detail. This mode is what is used for Symmetrically Encrypted Data > >Packets; the mechanism used for encrypting secret key material is > >similar, but described in those sections above. > > In the "secret key material" section I found this: > >Encryption/decryption of the secret data is done in CFB mode using > >the key created from the passphrase and the Initial Vector from the > >packet. > > (and now, back to the CFB mode) > >OpenPGP CFB mode uses an initialization vector (IV) of all zeros, > >and prefixes the plaintext with BS+2 octets of random data, such > >that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB > >"resync" after encrypting those BS+2 octets. > > I want to mention that I want to keep a secret key in format OpenPGP not > a plain text. > 1) What value should I fill in IV? > 2) Are those BS+2 octets just for plain text or even for secret key > material? The OpenPGP CFB module uses an "Encrypted Initialization". The way this works is: 1) start with an IV of all zeros (in the CFB Context) 2) Create a buffer of "BS+2" bytes 3) Fill in the first BS bytes with random bytes 4) copy the last two bytes of BS into the extra two bytes at the end 5) CFB Encrypt the "BS+2" bytes <-- This is the encrypted IV 6) Re-Sync the CFB context. 7) Start ecnrypting your data. This is done EVERY TIME you initialize a CFB context. These extra BS+2 bytes are prefixed before every CFB encryption. > >3. FRE is xored with the first BS octets of random data prefixed to > >the plaintext to produce C[1] through C[BS], the first BS octets > >of ciphertext. > > 3) Do the C[i] octets represent the final form for OpenPGP format? Yes. Although C[0]..C[BS+2] are the encrypted IV bytes, not your data bytes. > >12. FRE is xored with the next BS octets of plaintext, to produce > >the next BS octets of ciphertext. These are loaded into FR and > >the process is repeated until the plaintext is used up. > > 4) Let's assume that I encrypt the algorithm-specific portion with IDEA. > What it happens with the last block of data if the length of the > algorithm-specific portion is not multiple of 8 (64 bit)? (and, of > course, the last block it will be less than BS - in this case 8 octets) You clearly don't understand how CFB mode works. You don't encrypt your input in block-sized chunks; you rotate your feedback register in block-sized chunks. The ciphertext is just an xor of the feedback register with the plaintext, and you rotate the feedback register by encrypting your output. So if the last block of plaintext is only 1 byte, you only use one byte from the last feedback and toss the rest of your feedback on the floor. > Thank you in advance, > > Cornel Gligan-Ignatescu -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Fri Feb 15 11:59: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 LAA11231 for ; Fri, 15 Feb 2002 11:59:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FGduk07078 for ietf-openpgp-bks; Fri, 15 Feb 2002 08:39:56 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FGdn307071 for ; Fri, 15 Feb 2002 08:39:54 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA30068 for ; Fri, 15 Feb 2002 11:29:18 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA04402 for ; Fri, 15 Feb 2002 11:39:28 -0500 (EST) Message-ID: <004d01c1b63f$4ce5ad80$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode Date: Fri, 15 Feb 2002 11:39:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >I want to mention that I want to keep a secret key in format OpenPGP not > > a plain text. In this context, the "multi-precision integers comprising the secret key data" are the plaintext. > 1) What value should I fill in IV? In the secret key context, the IV should be filled with random bits. That IV is included in the unencrypted section of the secret key packet. For message packets, the IV is initially zero, but the first material to be encrypted is random, which has similar effect. > 2) Are those BS+2 octets just for plain text or even for secret key > material? The "BS+2" scheme is only used in the Symmetrically Encrypted Data ("message") packets. Secret key material is encrypted in a pure CFB mode; see below. > >3. FRE is xored with the first BS octets of random data prefixed to > >the plaintext to produce C[1] through C[BS], the first BS octets > >of ciphertext. > > 3) Do the C[i] octets represent the final form for OpenPGP format? Yes. > 4) Let's assume that I encrypt the algorithm-specific portion with IDEA. > What it happens with the last block of data if the length of the > algorithm-specific portion is not multiple of 8 (64 bit)? (and, of > course, the last block it will be less than BS - in this case 8 octets) CFB mode can use any "block size". The underlying cipher is always applied to the "feedback register", which is a whole block, even if the CFB input is smaller. If the CFB input is N bytes, only the first N bytes of the encrypted feedback register are used; they are XORed with the CFB input to form the CFB output. The CFB output is then shifted into the feedback register. The "block size" under CFB can even change from one input to the next. To decrypt, you also need to know how the data was blocked. RFC2440 uses the phrase "resync" to describe where blocks smaller than the underlying cipher are processed. For example, at the front of a message packet, a full block of random material is processed, following by an 2-byte block of repeated material -- those two bytes are *not* combined with subsequent plaintext to form a "full block", but are processed by themselves. Also, version 3 secret keys are processed one MPI at a time (including only the data, not the length), so the last bytes of each MPI may be a short block. Here is some Java-like pseudo-code for CFB that isn't tied to the OpenPGP behavior. Cipher engine; // underlying cipher, used in "ECB" mode byte [] FR; // feedback register, block-sized; initialized with IV void cfb_encrypt(byte [] src, byte [] dest, int length) { // assumes length <= ECB block size; if not, reject or break up the input // encrypt the FR, and XOR first "length" bytes with src into dest byte [] FRE = engine.encrypt(FR); for (int i = 0; i < length; i++) dest[i] = src[i] ^ FRE[i]; // shift "length" bytes of result into FR int j = 0; for (int i = length; i < FR.length; i++) FR[j++] = FR[i]; for (int i = 0; j < FR.length; i++) FR[j++] = dest[i]; } -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPG048VMkvpTT8vCGEQLuywCgmiCqp2qjFiKH0fSqqFnhz7Z6LScAn21L OkR7fcgruGz8T/RzfX3jv+zm =PnMc -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Feb 16 19:49: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 TAA18888 for ; Sat, 16 Feb 2002 19:49:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1H0MNQ07709 for ietf-openpgp-bks; Sat, 16 Feb 2002 16:22:23 -0800 (PST) Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0ML307703 for ; Sat, 16 Feb 2002 16:22:21 -0800 (PST) Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 2EE292C91 for ; Sun, 17 Feb 2002 01:22:13 +0100 (MET) Received: id ; Sun, 17 Feb 2002 01:21:14 +0100 (CET) Message-Id: Date: Sun, 17 Feb 2002 01:21:14 +0100 (CET) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME In-Reply-To: References: <20020213095005.GA6830@sobolev.does-not-exist.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas : > At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: >>> does not work with many mailing lists (that are configured to >>> remove attachments), >> Such mailing lists are broken. > As someone who runs a number of such "broken" mailing lists, I "broke" them > because I consider the security risk of my list being use to spread the > latest Outlook thingie to be much higher than the damage caused by breaking > them. So it's not about multipart messages, but about dangerous Content-Types? Dangerous Content-Type values have nothing to do with whether a message is a multipart message or not. Any Content-Type can be named directly in the main message headers, and completely harmless Content-Types can be named in the individual body parts of a multipart message. > It also prevents the inevitable newbie who sends a picture or movie > as an attachment, causing a dozen people to go over their mail quotas. Again, this has nothing to do with multiparts. If you want to prevent huge messages, set an appropriate message size limit. From owner-ietf-openpgp@mail.imc.org Thu Feb 21 15:12: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 PAA02076 for ; Thu, 21 Feb 2002 15:12:20 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJlQO29057 for ietf-openpgp-bks; Thu, 21 Feb 2002 11:47:26 -0800 (PST) Received: from hotmail.com (oe20.law3.hotmail.com [209.185.240.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJlP329053 for ; Thu, 21 Feb 2002 11:47:25 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Feb 2002 11:47:22 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: pgp oddities Date: Thu, 21 Feb 2002 14:38:14 -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: 21 Feb 2002 19:47:22.0830 (UTC) FILETIME=[947EE6E0:01C1BB10] 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 have compiled a list of pgp oddities, composed of examples of what can be done to a pgp message and still have it decrypt / verify and what minor changes will invalidate it, and what differences there are between pgp and gnupg in how these changes are accepted. the site is here: http://www.angelfire.com/pr/pgpf/pgpoddities.html except for one clearsigned message done using winpt, all the messages were generated using pgp 6.5.8 ckt build 6 some of the examples may be helpful in considering any recommendations for open pgp format of pgp messages vedaal -----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 iQEVAwUBPHVMo2oFoLeFMG0lAQNQnwf/fv0hd7QAkhlDf1iU5bL/z8Qb4RgF0DGd 6HT5P+IcqN/8HQlC/DLIwt+gMP1PqbE6UVWu58pX6fZUPyeQugdRNIw+cW0me+rQ S38KxM8lBzvKmyx2qRz8K3CrdUiXWd2gxGSPFBW/tm8YtTsx1mOEs17tZuWFeRKp PG6B1tqK37XvQD6qCOzlH9YLp3QaC2u6Gc+8xPB2SBTLAuYdU1Box/RUfntDsnlb cQx1LvLWPKUr8QmOiFgZ5J6HxCT8GLhOqZDt3FMEq64RdBHvwZLJWZqiBLE7IX// kN3hWuwQrQArfPvO9WhXSUG2g9Xas/tsG78yKxJst7WgzzwUM6Xnog== =/VSu -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Feb 21 16:27: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 QAA04871 for ; Thu, 21 Feb 2002 16:27:40 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LLBsi01129 for ietf-openpgp-bks; Thu, 21 Feb 2002 13:11:54 -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 g1LLBr301124 for ; Thu, 21 Feb 2002 13:11:53 -0800 (PST) Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g1LLC1a05770 for ; Thu, 21 Feb 2002 16:12:01 -0500 (EST) Subject: OpenPGP vs. X.509/PKCS To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Thu, 21 Feb 2002 15:11:50 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 02/21/2002 04:11:55 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 If PGP was indeed established as the first useful PK system, why did "they" come up with PKCS standards that are totally different? Why did PKCS-style files and formats propigate through Internet standards, when all along everyone was using PGP, and had access to that code? From owner-ietf-openpgp@mail.imc.org Thu Feb 21 16:40:32 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 QAA05187 for ; Thu, 21 Feb 2002 16:40:31 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LLOZw01438 for ietf-openpgp-bks; Thu, 21 Feb 2002 13:24:35 -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 g1LLOY301434 for ; Thu, 21 Feb 2002 13:24:34 -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 QAA08942; Thu, 21 Feb 2002 16:24:36 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14024; Thu, 21 Feb 2002 16:24:35 -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 QAA18672; Thu, 21 Feb 2002 16:24:34 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA08940; Thu, 21 Feb 2002 16:24:33 -0500 (EST) To: john.dlugosz@kodak.com Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: OpenPGP vs. X.509/PKCS References: Date: 21 Feb 2002 16:24:33 -0500 In-Reply-To: Message-ID: Lines: 18 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: Because "they" weren't making any money off of PGP. :) -derek john.dlugosz@kodak.com writes: > From: John Dlugosz > > If PGP was indeed established as the first useful PK system, why did "they" > come up with PKCS standards that are totally different? Why did PKCS-style > files and formats propigate through Internet standards, when all along > everyone was using PGP, and had access to that code? > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Thu Feb 21 17: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 RAA06317 for ; Thu, 21 Feb 2002 17:36:18 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMI0c02822 for ietf-openpgp-bks; Thu, 21 Feb 2002 14:18:00 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMHx302818 for ; Thu, 21 Feb 2002 14:17:59 -0800 (PST) Received: from pc5211wxptfm (cp92837-a.dbsch1.nb.nl.home.com [217.120.34.92]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with SMTP id g1LMHlsX044210; Thu, 21 Feb 2002 23:17:47 +0100 (CET) From: "Leon Kuunders" To: "Derek Atkins" , Cc: Subject: RE: OpenPGP vs. X.509/PKCS Date: Thu, 21 Feb 2002 23:17:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit So the question is: how could we turn OpenPGP into a more-money-making infrastructure? And that comes down to: what kind of need would there be for OpenPGP? If there is already X509? What can OpenPGP do what the other one can't? And what kind of business model would go with that? Is it feasible to think that as long as the 'mainstream' is not convinced of the fact that OpenPGP can bring them _more_ money than X509 - that this battle is moving towards a definite end? -Leon. > From: Derek Atkins > > Because "they" weren't making any money off of PGP. :) > > -derek > > john.dlugosz@kodak.com writes: > > > From: John Dlugosz > > > > If PGP was indeed established as the first useful PK system, > why did "they" > > come up with PKCS standards that are totally different? Why > did PKCS-style > > files and formats propigate through Internet standards, when all along > > everyone was using PGP, and had access to that code? > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > From owner-ietf-openpgp@mail.imc.org Thu Feb 21 18:06: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 SAA06995 for ; Thu, 21 Feb 2002 18:06:05 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMk1103406 for ietf-openpgp-bks; Thu, 21 Feb 2002 14:46:01 -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 g1LMk0303400 for ; Thu, 21 Feb 2002 14:46:00 -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 RAA11223; Thu, 21 Feb 2002 17:46:02 -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 RAA27857; Thu, 21 Feb 2002 17:46:02 -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 RAA20894; Thu, 21 Feb 2002 17:46:01 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA12673; Thu, 21 Feb 2002 17:46:00 -0500 (EST) To: "Leon Kuunders" Cc: , From: "Derek Atkins" Subject: Re: OpenPGP vs. X.509/PKCS References: Date: 21 Feb 2002 17:46:00 -0500 In-Reply-To: Message-ID: Lines: 70 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: At the time PGP was created, there were a LOT of things that PGP could offer than X.509 could not. To name a few: - PGP certificates are MUCH smaller than X.509 in terms of the number of bytes required to represent the same semantic content. - at the time X.509 certificates could only carry a single signature, forcing users into a strict hierarchical model, whereas PGP allows the opportunity for a more web-like model that better mirrors real-world relationships. - PGP certificates are self-generated, and require no interaction with anybody in order to start using the system, wheras with X.509 you need to get your key signed by an authority before you can use it at all. Note that the question you are asking does not necessarily follow from the question that I answered. The question was about why PKCS was created. PKCS came from RSADSI, which was the company that owned the RSA patent. They created the PKCS standards. As for why X.509 took off? It took off because there was money to be made when you force users to use your services (read: you're a CA), and because you have a business whereas PGP does not. (Note that all this happened in the early 90s, well before PGP, Inc. existed). -derek "Leon Kuunders" writes: > So the question is: how could we turn OpenPGP into a more-money-making > infrastructure? And that comes down to: what kind of need would there be for > OpenPGP? If there is already X509? What can OpenPGP do what the other one > can't? And what kind of business model would go with that? > > Is it feasible to think that as long as the 'mainstream' is not convinced of > the fact that OpenPGP can bring them _more_ money than X509 - that this > battle is moving towards a definite end? > > -Leon. > > > From: Derek Atkins > > > > Because "they" weren't making any money off of PGP. :) > > > > -derek > > > > john.dlugosz@kodak.com writes: > > > > > From: John Dlugosz > > > > > > If PGP was indeed established as the first useful PK system, > > why did "they" > > > come up with PKCS standards that are totally different? Why > > did PKCS-style > > > files and formats propigate through Internet standards, when all along > > > everyone was using PGP, and had access to that code? > > > > > > > -- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com > > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Thu Feb 21 18:17: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 SAA07108 for ; Thu, 21 Feb 2002 18:17:57 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LN2os03747 for ietf-openpgp-bks; Thu, 21 Feb 2002 15:02:50 -0800 (PST) Received: from muppet.faveve.uni-stuttgart.de (mail@muppet.faveve.uni-stuttgart.de [129.69.139.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LN2n303743 for ; Thu, 21 Feb 2002 15:02:49 -0800 (PST) Received: from delta by muppet.faveve.uni-stuttgart.de with local (Exim 3.13 #1) id 16e2Ec-0004Cl-00 for ietf-openpgp@imc.org; Fri, 22 Feb 2002 00:02:42 +0100 Date: Fri, 22 Feb 2002 00:02:42 +0100 From: Helmut Springer To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. X.509/PKCS Message-ID: <20020221230242.GZ15932@faveve.uni-stuttgart.de> 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: 1024/864FB4AD AE 42 C3 2C A1 3E 55 6D B3 AC 3C D2 F3 CF FF E7 X-pgp-key-url: http://www.citecs.de/pgpkey.delta.asc Organization: elite[tm] since running completely computer based FAX Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 21 Feb 2002 at 23:17 +0100, Leon Kuunders wrote: > So the question is: how could we turn OpenPGP into a > more-money-making infrastructure? And that comes down to: what Title : Extensions to TLS for OpenPGP keys Author(s) : W. Price, M. Elkins Filename : draft-ietf-tls-openpgp-02.txt Pages : 4 Date : 19-Feb-02 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-02.txt Comes to mind. Interoperability with SSH would be another step towards a "complete" PKI solution. But then you need both a need for PKIs and widely used software to generate real money... -- MfG/best regards, helmut springer "Freedom's just another word for nothing left to lose" From owner-ietf-openpgp@mail.imc.org Fri Feb 22 12:32:51 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 MAA12796 for ; Fri, 22 Feb 2002 12:32:50 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHFLZ08162 for ietf-openpgp-bks; Fri, 22 Feb 2002 09:15:21 -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 g1MHFJ308158 for ; Fri, 22 Feb 2002 09:15:20 -0800 (PST) Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g1MHFQi07180 for ; Fri, 22 Feb 2002 12:15:26 -0500 (EST) Subject: Alice, Bob, ... Foo, bar? To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Fri, 22 Feb 2002 11:15:15 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 02/22/2002 12:15:21 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 I know about Alice and Bob in general. But does anyone have a pointer to a complete list of which names are commonly used, and what Roles those names are used for? E.g. Eve is used for an evesdropper. Someone else (I forgot who) can alter packets, though. --John From owner-ietf-openpgp@mail.imc.org Fri Feb 22 12:32: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 MAA12802 for ; Fri, 22 Feb 2002 12:32:51 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHCOO08075 for ietf-openpgp-bks; Fri, 22 Feb 2002 09:12:24 -0800 (PST) Received: from mail1.biodata.com (mail1.biodata.com [62.159.113.2] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MHCN308070 for ; Fri, 22 Feb 2002 09:12:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: OpenPGP vs. X.509/PKCS Date: Fri, 22 Feb 2002 18:09:16 +0100 Message-ID: <3DD04EB2E6FBEB47896D9CD157CBB83D04520D@bbq1m003.biodata.org> Thread-Topic: OpenPGP vs. X.509/PKCS Thread-Index: AcG7K+2Xu9ermtr6QdWw5CoNHgn1WwAbPSZgAAqybnA= From: "Dominikus Scherkl" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1MHCN308071 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > At the time PGP was created, there were a LOT of things that PGP > could offer than X.509 could not. To name a few: > > - PGP certificates are MUCH smaller than X.509 in terms of the number > of bytes required to represent the same semantic content. If you see this as an important advantage, I can't understand why still nobody is iteressted in integrating elliptic curves into the openPGP standard (as I proposed in last august, you may find it at: http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt). This Draft is now expired, but I still want it to become part of openPGP. PS: my mail-account has changed: -- Dominikus Scherkl Mail: dominikusscherkl@glueckkanja.com From owner-ietf-openpgp@mail.imc.org Fri Feb 22 13:10:34 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 NAA14457 for ; Fri, 22 Feb 2002 13:10:34 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHq4m08935 for ietf-openpgp-bks; Fri, 22 Feb 2002 09:52:04 -0800 (PST) Received: from tomts21-srv.bellnexxia.net (tomts21.bellnexxia.net [209.226.175.183]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MHq2308931 for ; Fri, 22 Feb 2002 09:52:02 -0800 (PST) Received: from [192.168.1.101] ([64.229.184.93]) by tomts21-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020222175151.OOAZ805.tomts21-srv.bellnexxia.net@[192.168.1.101]>; Fri, 22 Feb 2002 12:51:51 -0500 Date: Fri, 22 Feb 2002 12:51:55 -0500 (EST) From: Robert Guerra X-X-Sender: rguerra@med.mine.nu To: john.dlugosz@kodak.com cc: ietf-openpgp@imc.org Subject: Re: Alice, Bob, ... Foo, bar? In-Reply-To: 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: The Alice and Bob After Dinner Speech given at the Zurich Seminar, April 1984 by John Gordon http://www.conceptlabs.co.uk/alicebob.html On Fri, 22 Feb 2002 john.dlugosz@kodak.com wrote: > > From: John Dlugosz > > I know about Alice and Bob in general. But does anyone have a pointer to a > complete list of which names are commonly used, and what Roles those names > are used for? E.g. Eve is used for an evesdropper. Someone else (I forgot > who) can alter packets, though. > > --John > > -- Robert Guerra Director, Computer Professionals for Social Responsibility (CPSR) From owner-ietf-openpgp@mail.imc.org Fri Feb 22 15:06:45 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 PAA20172 for ; Fri, 22 Feb 2002 15:06:45 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MJmks11397 for ietf-openpgp-bks; Fri, 22 Feb 2002 11:48:46 -0800 (PST) Received: from m11.jersey.juno.com (m11.jersey.juno.com [64.136.16.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MJmj311391 for ; Fri, 22 Feb 2002 11:48:45 -0800 (PST) Received: from cookie.juno.com by cookie.juno.com for <"xS5dSbQuAOKnbKF9wbUrHN7eQ5MrSfHN1OQ+CU8aSxySJLirJ69MZg=="> Received: (from joe.tag@juno.com) by m11.jersey.juno.com (jqueuemail) id GUAC82KD; Fri, 22 Feb 2002 14:48:08 EST To: rguerra@yahoo.com Cc: john.dlugosz@kodak.com, ietf-openpgp@imc.org Date: Fri, 22 Feb 2002 14:47:56 -0500 Subject: Re: Alice, Bob, ... Foo, bar? Message-ID: <20020222.144757.-713507.0.joe.tag@juno.com> X-Mailer: Juno 5.0.33 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-1,3-7,9,11-25,27-58 From: Joe Tag Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, You can also find the reference in Schneir __Applied_Crytography__ text; and in Pfleeger's __Security_in_Computing__ . Koblitz in his __Number_Theory_and_Crypto__ used names like 'Aida' and 'Bernardo'. I like 'Anna' ( think the old morse code naviation system " . _ " = a ; "_ ." = n; and ''Anna'' is a 'palindrome name' ; You could use also, "Alyssa" (think Milano). Boris (Russion), Bruce. Carol, Carl, Carlos, Charles is the "Certificate Authority" 'Evan' could also be an eavesdropper (just think Evil). "Trent" is the "Digital 'Trusted' Notary. Also known as "Ted". Sincerely yours, Joe Tag,Jr. http://www.kean.edu/~jtag On Fri, 22 Feb 2002 12:51:55 -0500 (EST) Robert Guerra writes: > > The Alice and Bob After Dinner Speech > > given at the Zurich Seminar, April 1984 > > by John Gordon > > > http://www.conceptlabs.co.uk/alicebob.html > > On Fri, 22 Feb 2002 john.dlugosz@kodak.com wrote: > > > > > From: John Dlugosz > > > > I know about Alice and Bob in general. But does anyone have a > pointer to a > > complete list of which names are commonly used, and what Roles > those names > > are used for? E.g. Eve is used for an evesdropper. Someone else > (I forgot > > who) can alter packets, though. > > > > --John > > > > > > -- > Robert Guerra > Director, Computer Professionals for Social Responsibility (CPSR) > > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. From owner-ietf-openpgp@mail.imc.org Fri Feb 22 15:50:28 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 PAA23243 for ; Fri, 22 Feb 2002 15:50:28 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MKUlB12446 for ietf-openpgp-bks; Fri, 22 Feb 2002 12:30:47 -0800 (PST) Received: from diplomatic.passport.ca (mail.passport.ca [204.225.103.222]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MKUj312442 for ; Fri, 22 Feb 2002 12:30:45 -0800 (PST) Received: from passport.ca ([207.112.115.244]) by diplomatic.passport.ca (8.11.3/8.11.3) with ESMTP id g1MKU5S10098; Fri, 22 Feb 2002 15:30:06 -0500 (EST) Message-ID: <3C76AA4D.D50778EA@passport.ca> Date: Fri, 22 Feb 2002 15:30:05 -0500 From: Paul Shields X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Joe Tag CC: rguerra@yahoo.com, john.dlugosz@kodak.com, ietf-openpgp@imc.org Subject: Re: Alice, Bob, ... Foo, bar? References: <20020222.144757.-713507.0.joe.tag@juno.com> 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 Also: Malcolm: the man in the middle, an active attacker who can alter messages, forge packets, certificates, etc. Joe Tag wrote: > Hi, > > You can also find the reference in Schneir __Applied_Crytography__ text; > and in > Pfleeger's __Security_in_Computing__ . > Koblitz in his __Number_Theory_and_Crypto__ used names like > 'Aida' and 'Bernardo'. > > I like 'Anna' ( think the old morse code naviation system " . _ " = a ; "_ > ." = n; and > ''Anna'' is a 'palindrome name' ; You could use also, "Alyssa" (think > Milano). > Boris (Russion), Bruce. > Carol, Carl, Carlos, Charles is the "Certificate Authority" > 'Evan' could also be an eavesdropper (just think Evil). > "Trent" is the "Digital 'Trusted' Notary. Also known as "Ted". > > Sincerely yours, > > Joe Tag,Jr. > > http://www.kean.edu/~jtag > > On Fri, 22 Feb 2002 12:51:55 -0500 (EST) Robert Guerra > writes: > > > > The Alice and Bob After Dinner Speech > > given at the Zurich Seminar, April 1984 > > by John Gordon > > > > http://www.conceptlabs.co.uk/alicebob.html > > > > On Fri, 22 Feb 2002 john.dlugosz@kodak.com wrote: > > > > > > From: John Dlugosz > > > > > > I know about Alice and Bob in general. But does anyone have a pointer > to a > > > complete list of which names are commonly used, and what Roles those > names > > > are used for? E.g. Eve is used for an evesdropper. Someone else > > > (I forgot who) can alter packets, though. > > > > > > --John From owner-ietf-openpgp@mail.imc.org Fri Feb 22 18:00: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 SAA00159 for ; Fri, 22 Feb 2002 18:00:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1MMgd614883 for ietf-openpgp-bks; Fri, 22 Feb 2002 14:42:39 -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 g1MMgc314878 for ; Fri, 22 Feb 2002 14:42:38 -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 RAA22274; Fri, 22 Feb 2002 17:42:40 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17631; Fri, 22 Feb 2002 17:42:37 -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 RAA17776; Fri, 22 Feb 2002 17:42:34 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA13772; Fri, 22 Feb 2002 17:42:34 -0500 (EST) To: "Dominikus Scherkl" Cc: From: Derek Atkins Subject: Re: OpenPGP vs. X.509/PKCS References: <3DD04EB2E6FBEB47896D9CD157CBB83D04520D@bbq1m003.biodata.org> Date: 22 Feb 2002 17:42:34 -0500 In-Reply-To: <3DD04EB2E6FBEB47896D9CD157CBB83D04520D@bbq1m003.biodata.org> Message-ID: Lines: 34 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: Give me a patent-free ECC algorithm that has reasonable performance. Replies to /dev/null, please. -derek "Dominikus Scherkl" writes: > > At the time PGP was created, there were a LOT of things that PGP > > could offer than X.509 could not. To name a few: > > > > - PGP certificates are MUCH smaller than X.509 in terms of > the number > > of bytes required to represent the same semantic content. > > If you see this as an important advantage, I can't understand why > still nobody is iteressted in integrating elliptic curves into the > openPGP standard (as I proposed in last august, you may find it at: > http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt). > > This Draft is now expired, but I still want it to become part > of openPGP. > > PS: my mail-account has changed: > > -- > Dominikus Scherkl > Mail: dominikusscherkl@glueckkanja.com > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Sun Feb 24 05:54: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 FAA09885 for ; Sun, 24 Feb 2002 05:54:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1OAVWn00555 for ietf-openpgp-bks; Sun, 24 Feb 2002 02:31:32 -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 g1OAVS300541 for ; Sun, 24 Feb 2002 02:31:30 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Sun, 24 Feb 2002 12:26:34 0200 Message-ID: <3C78BFD9.A8FD4E7D@saiknes.lv> Date: Sun, 24 Feb 2002 12:26:33 +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: Alice, Bob, ... Foo, bar? 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 John Dlugosz wrote: > I know about Alice and Bob in general. But does anyone have a pointer to a > complete list of which names are commonly used, and what Roles those names > are used for? E.g. Eve is used for an evesdropper. Someone else (I forgot > who) can alter packets, though. > --John see: http://www.cs.man.ac.uk/~chl/scenarios.html __ 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/AwUBPHijjzBaTVEuJQxkEQPuGgCgsY7vvA6EvEUnoZJJMobVX+Jr/GgAoKN1 7Smem766Jyk8nVpP0bdqT/ff =HBeV -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Feb 26 16:18: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 QAA21971 for ; Tue, 26 Feb 2002 16:18:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1QKx7B22798 for ietf-openpgp-bks; Tue, 26 Feb 2002 12:59:07 -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 g1QKx4322794 for ; Tue, 26 Feb 2002 12:59:05 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1QKwuB05601 for ietf-openpgp@imc.org; Tue, 26 Feb 2002 15:58:56 -0500 Date: Tue, 26 Feb 2002 15:58:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Revocation key difficulty Message-ID: <20020226205856.GB5246@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.26i X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Full Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi folks, While implementing revocation key ("designated revoker") support for GnuPG, I came across what seems to be a problem in the specificaiton of revocation keys. The RFC says the key designated as the revocation key can issue several types of revocations: key revocations (0x20), subkey revocations (0x28), and certificate revocations (0x30). The first two are not a problem since there is no confusion as to what they revoke. The problem with certificate revocations is that it is not possible in some cases to know which certificate is being revoked. For example, take Alice, Bob, and Charlie. Bob is Alice's designated revoker. Alice and Bob have both signed Charlie's key. Now Alice asks Bob to revoke her signature on Charlie's key. Since both Alice and Bob have signed Charlie's key, and the format of a revocation that is issued by a designated revoker is the same as a revocation issued by the key owner, the OpenPGP program has no way to tell which certification is being revoked: is it Bob's or is it Alice's? A while back, someone suggested a "revocation target" signature subpacket for revocation signatures that would contain the hash of the signature that was being revoked. That would fix this problem, but I'm open to any solution - does it even make sense to allow a revocation key to issue certificate revocations? I always thought of the revocation key as the "revoker of last resort" - more for emergency key revocations in case of compromise or secret key loss than for fine-grained control of previously issued signatures. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Tue Feb 26 18:13: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 SAA24573 for ; Tue, 26 Feb 2002 18:13:56 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1QMqsG25450 for ietf-openpgp-bks; Tue, 26 Feb 2002 14:52:54 -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 g1QMqr325446 for ; Tue, 26 Feb 2002 14:52:53 -0800 (PST) Received: from [63.73.97.188] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Tue, 26 Feb 2002 14:52:43 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20020226205856.GB5246@akamai.com> References: <20020226205856.GB5246@akamai.com> Date: Tue, 26 Feb 2002 14:52:33 -0800 To: David Shaw , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Revocation key difficulty Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:58 PM -0500 2/26/02, David Shaw wrote: >The problem with certificate revocations is that it is not possible in >some cases to know which certificate is being revoked. For example, >take Alice, Bob, and Charlie. Bob is Alice's designated revoker. >Alice and Bob have both signed Charlie's key. Now Alice asks Bob to >revoke her signature on Charlie's key. > >Since both Alice and Bob have signed Charlie's key, and the format of >a revocation that is issued by a designated revoker is the same as a >revocation issued by the key owner, the OpenPGP program has no way to >tell which certification is being revoked: is it Bob's or is it >Alice's? Ummm, that's certificate revocation, not certification revocation. A PGP certificate (a.k.a. key) contains a collection of certifications. It is these certifications (colloquially key signatures) that determine a certificate's validity. A certificate revocation makes the certificate dead. It cancels the *entire* certificate, regardless of anything else. Here's a scenario like yours: Alice and Bob have both signed Charlie's key. Alice is also a designated revoker on Charlie's key. When Alice issues a certificate revocation for Charlie's key (a.k.a. certificate), then Charlie's key is revoked. It is an ex-certificate and has joined the Choir Eternal. It has ceased to be. It no longer matters that Bob signed Charlie's key. It no longer matters that David through Zelda inclusive has signed it. It is no longer valid. This is just like what would happen if Charlie issued that revocation himself. Now, then, there are some unresolved issues related to this. Is the contract that Bob signed two years ago with me now suddenly void? I think not. There are, however, people I respect who think it is. But that's a different discussion. Jon From owner-ietf-openpgp@mail.imc.org Tue Feb 26 18:34:08 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 SAA24986 for ; Tue, 26 Feb 2002 18:34:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QNMhQ25924 for ietf-openpgp-bks; Tue, 26 Feb 2002 15:22:43 -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 g1QNMg325920 for ; Tue, 26 Feb 2002 15:22:42 -0800 (PST) Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g1QNMkK29840; Tue, 26 Feb 2002 18:22:46 -0500 (EST) Subject: Re: Revocation key difficulty To: dshaw@akamai.com Cc: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Tue, 26 Feb 2002 17:22:35 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 02/26/2002 06:22:38 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 ===== A while back, someone suggested a "revocation target" signature subpacket for revocation signatures that would contain the hash of the signature that was being revoked. That would fix this problem, but I'm open to any solution - does it even make sense to allow a revocation key to issue certificate revocations? I always thought of the revocation key as the "revoker of last resort" - more for emergency key revocations in case of compromise or secret key loss than for fine-grained control of previously issued signatures. ===== Hmm, so how would it be used? Alice had signed Charlie's key, and now Alice's key is compromised, so Bob decides to remove Alice's signature from Charlie's key. Why? Well, perhaps Alice is a manager and Charlie is an employee, and Bob is the tech doing all the work. Bob is cleaning all the underling's keys and doesn't want to ask Alice to get involved, or maybe she is out of reach. So, why is it necessary to remove Alice's signature from Charlie's key? Anyone who verifies Charlie's key will see that Alice's has been revoked and will know to ignore it. If you're going to distribute this second-party revokation of signatures, why not just send out a generic "Alice's key is bad" revokation, and that implies that it ought to be removed from certificates too? From owner-ietf-openpgp@mail.imc.org Tue Feb 26 18:53:45 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 SAA25466 for ; Tue, 26 Feb 2002 18:53:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QNcoK26260 for ietf-openpgp-bks; Tue, 26 Feb 2002 15:38:50 -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 g1QNcn326256 for ; Tue, 26 Feb 2002 15:38:49 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1QNchQ10917; Tue, 26 Feb 2002 18:38:43 -0500 Date: Tue, 26 Feb 2002 18:38:43 -0500 From: David Shaw To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020226233843.GE5246@akamai.com> Mail-Followup-To: Jon Callas , ietf-openpgp@imc.org References: <20020226205856.GB5246@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: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Full Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Feb 26, 2002 at 02:52:33PM -0800, Jon Callas wrote: > > At 3:58 PM -0500 2/26/02, David Shaw wrote: > > >The problem with certificate revocations is that it is not possible in > >some cases to know which certificate is being revoked. For example, > >take Alice, Bob, and Charlie. Bob is Alice's designated revoker. > >Alice and Bob have both signed Charlie's key. Now Alice asks Bob to > >revoke her signature on Charlie's key. > > > >Since both Alice and Bob have signed Charlie's key, and the format of > >a revocation that is issued by a designated revoker is the same as a > >revocation issued by the key owner, the OpenPGP program has no way to > >tell which certification is being revoked: is it Bob's or is it > >Alice's? > > Ummm, that's certificate revocation, not certification revocation. A PGP > certificate (a.k.a. key) contains a collection of certifications. It is > these certifications (colloquially key signatures) that determine a > certificate's validity. > > A certificate revocation makes the certificate dead. It cancels the > *entire* certificate, regardless of anything else. Well understood and agreed, but I really did mean what I said. The RFC says (section 5.2.1): 0x30: Certification revocation signature This signature revokes an earlier user ID certification signature (signature class 0x10 through 0x13). It should be issued by the same key that issued the revoked signature or an authorized revocation key The signature should have a later creation date than the signature it revokes. Am I somehow misreading this? To my eye, this says an authorized revocation key can issue a genuine 0x30 *certification* revocation signature. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Tue Feb 26 19:10: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 TAA25882 for ; Tue, 26 Feb 2002 19:10:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QNvi226612 for ietf-openpgp-bks; Tue, 26 Feb 2002 15:57:44 -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 g1QNvh326608 for ; Tue, 26 Feb 2002 15:57:43 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1QNvci11946 for ietf-openpgp@imc.org; Tue, 26 Feb 2002 18:57:38 -0500 Date: Tue, 26 Feb 2002 18:57:38 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020226235738.GF5246@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: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Full Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Feb 26, 2002 at 05:22:35PM -0600, john.dlugosz@kodak.com wrote: > Hmm, so how would it be used? Alice had signed Charlie's key, and now > Alice's key is compromised, so Bob decides to remove Alice's signature from > Charlie's key. Why? Well, perhaps Alice is a manager and Charlie is an > employee, and Bob is the tech doing all the work. Bob is cleaning all the > underling's keys and doesn't want to ask Alice to get involved, or maybe > she is out of reach. > > So, why is it necessary to remove Alice's signature from Charlie's key? > Anyone who verifies Charlie's key will see that Alice's has been revoked > and will know to ignore it. If you're going to distribute this > second-party revokation of signatures, why not just send out a generic > "Alice's key is bad" revokation, and that implies that it ought to be > removed from certificates too? Exactly. It seems to make more sense to Bob for issue a general key revocation (sigclass 0x20) for Alice's key, rather than issue a certification revocation (sigclass 0x30) for Alice's signature on Charlie's key. The problem I'm having is that the RFC says that Bob can issue a certification revocation (0x30. NOT 0x20). I'm not saying this is smart, a good idea, or best practice, but the RFC explicitly says it is possible. If Bob does this, there is no way to differentiate between Bob's certification revocation (0x30) of Bob's certification (0x10) of Charlie's key and Bob's certification revocation (0x30) of Alice's certification (0x10) of Charlie's key. I'm including sigclasses here to help make what I'm saying clear. The words "certificate" and "certification" are just too similar and I think I swapped them once or twice in my original mail. Sorry folks. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Wed Feb 27 13:22:31 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 NAA08226 for ; Wed, 27 Feb 2002 13:22:30 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RI1F601922 for ietf-openpgp-bks; Wed, 27 Feb 2002 10:01:15 -0800 (PST) Received: from hotmail.com (oe28.law3.hotmail.com [209.185.240.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RI1D301917 for ; Wed, 27 Feb 2002 10:01:13 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Feb 2002 09:50:04 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <20020226235738.GF5246@akamai.com> Subject: Re: Revocation key difficulty Date: Wed, 27 Feb 2002 11:42:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 27 Feb 2002 17:50:04.0887 (UTC) FILETIME=[30088670:01C1BFB7] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "David Shaw" To: Sent: Tuesday, February 26, 2002 6:57 PM Subject: Re: Revocation key difficulty > > On Tue, Feb 26, 2002 at 05:22:35PM -0600, john.dlugosz@kodak.com wrote: > > > Hmm, so how would it be used? Alice had signed Charlie's key, and now > > Alice's key is compromised, so Bob decides to remove Alice's signature from > > Charlie's key. Why? ... > Exactly. It seems to make more sense to Bob for issue a general key > revocation (sigclass 0x20) for Alice's key, rather than issue a > certification revocation (sigclass 0x30) for Alice's signature on > Charlie's key. ... A possible reason why it may be beneficial to to have a revoker selectively revoke only the signature, may be if one is forced to give up an RSA encryption key. {Hopefully, this should never have to be, and the session key should be enough for the authorities, but if it 'were' to happen ...,} Then, to avoid anyone else signing with Alice's key {if it would be surrendered}, Alice may want two separate RSA keys, her original one for encrypting, and another one for signing. Alice then publicly declares that she is no longer signing with her original RSA key. Sometime later, someone else's key that Alice once signed, is now 'questionable', and Alice wants her signature removed. Now her designated revoker can accomplish this. vedaal From owner-ietf-openpgp@mail.imc.org Wed Feb 27 14:02:10 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 OAA10494 for ; Wed, 27 Feb 2002 14:02:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g1RIjLS02980 for ietf-openpgp-bks; Wed, 27 Feb 2002 10:45:21 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RIjJ302976 for ; Wed, 27 Feb 2002 10:45:19 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id NAA29016 for ; Wed, 27 Feb 2002 13:34:53 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA10802 for ; Wed, 27 Feb 2002 13:45:15 -0500 (EST) Message-ID: <003501c1bfbe$d06bc620$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> Subject: Revocation identification (was Re: Revocation key difficulty ) Date: Wed, 27 Feb 2002 13:44:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >A while back, someone suggested a "revocation target" signature > > subpacket for revocation signatures that would contain the hash of the > signature that was being revoked. That would fix this problem, but I was that someone. I still think it's a good idea. How can it possibly hurt to identify the exact signature being revoked? It can't be the few extra bytes... it would be a small fraction of the total, and revocations should be rare, anyway. Even if the current issue is resolved by removing the language about designated revokers issuing certification revocations, there are other ambiguities that this would solve. I think it is quite valid for one key to sign something multiple times, with a different: signature class; expiration time; notation; preferred algorithm; or, almost any other optional subpacket. Some have suggested using the timestamp to decide which signatures a revocation covers, but others have objected. I see no need to depend on timestamps -- the hash identifies the signature perfectly. When it last came up, Jon asked if anyone would implement it, and Werner said he would not. Since my implementation is not yet (and may never be) public, I didn't feel qualified to say "yes". But I suppose that either David or I could implement it in GnuPG, if Werner would pick up the change. I'm not asking for this to be a MUST. Old revocations (and even new V3 ones) will not have the subpacket, so no implementation should depend on it. I'd suggest making it a SHOULD. Any other supporters out there? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPH0o6lMkvpTT8vCGEQLzqgCg6XkUpNjS5upTC6T48I6N4oIN8pQAoLeG /Dd+yQd1b1vluVFKHD6fAa5H =epkZ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 27 14:44: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 OAA13394 for ; Wed, 27 Feb 2002 14:44:42 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1RJTJk03873 for ietf-openpgp-bks; Wed, 27 Feb 2002 11:29:19 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJTH303869 for ; Wed, 27 Feb 2002 11:29:17 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id OAA08482 for ; Wed, 27 Feb 2002 14:18:51 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA11052 for ; Wed, 27 Feb 2002 14:29:13 -0500 (EST) Message-ID: <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> Subject: Re: Revocation key difficulty Date: Wed, 27 Feb 2002 14:28:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my previous message, I mentioned the possibility of changing the designated revoker language to resolve this issue, but I didn't mean to recommend that. In fact, I might argue that the ability to revoke individual certifications is the only meaningful use of a designated revoker. If I want to limit my designated revoker to flushing my whole key, I can do that *much* more easily -- I can generate my own revocation, and encrypt it to my designated revoker. (If you're so afraid that your designee will lose the thing, put it in a notation packet in another signature, and ship it off to a keyserver for archiving. ;-) Doing it that way doesn't depend on everyone having my revoker's key for verification, or even knowing who the revoker might be. This seems so vastly superior to me that I can't imagine using the designated revoker facility for this purpose. (Am I missing something?) But if I'm in the habit of making dubious signatures, and want to let someone cancel specific ones, I would need to give my designee an encrypted revocation certificate for each of those as well. Not impossible, but a little more tedious. The designated revoker encoding is more compact. [You might ask: what kind of moron habitually issues questionable signatures? Perhaps an automated corporate ID generator. Why designate a revoker? You might want to destroy away the generator's private key periodically, to prevent additional certifications, but still want to be able to revoke things. A pretty weak example, but the best I can offer. Can anyone else provide a stronger example?] -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPH0zU1MkvpTT8vCGEQJf1gCg6KKDIOn7nir+hG6qDuSFxijshIAAnAmx v9P2qO6mkEVpjgL1XDrks9ia =aQeV -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Feb 27 22:58:45 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 WAA02808 for ; Wed, 27 Feb 2002 22:58:44 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S3eR414175 for ietf-openpgp-bks; Wed, 27 Feb 2002 19:40:27 -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 g1S3eQi14171 for ; Wed, 27 Feb 2002 19:40:26 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1S3ePV02393 for ietf-openpgp@imc.org; Wed, 27 Feb 2002 22:40:25 -0500 Date: Wed, 27 Feb 2002 22:40:25 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020228034024.GA678@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> User-Agent: Mutt/1.3.26i X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (99% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Feb 27, 2002 at 02:28:35PM -0500, Michael Young wrote: > In my previous message, I mentioned the possibility of changing the > designated revoker language to resolve this issue, but I didn't mean > to recommend that. In fact, I might argue that the ability to revoke > individual certifications is the only meaningful use of a designated > revoker. I can see both sides of this issue. On the one hand, additional flexibility in OpenPGP to handle more varied uses is probably good. Having a designated revoker that can revoke key certifications (0x30) has also been in the standard for a long time, though as far as I know, nobody has ever implemented it (I assume if someone had, they'd have had the same problem and raised the same question I did). On the other hand, I'm concerned that giving the designated revoker such fine-grained power to influence previous actions of the key owner could be dangerous. I rather like the idea that the absolute worst thing a rogue designated revoker could do is revoke your key. Even though the standard allows for more, as far as I know, the only implementation that does designated revokers is PGP, and it does only full key revocations (0x20). GnuPG will start doing designated revokers RSN, and I wrote the code to only do full key revocations as well, though I'm open to changing that. > If I want to limit my designated revoker to flushing my whole > key, I can do that *much* more easily -- I can generate my > own revocation, and encrypt it to my designated revoker. > (If you're so afraid that your designee will lose the thing, > put it in a notation packet in another signature, and > ship it off to a keyserver for archiving. ;-) Doing it that > way doesn't depend on everyone having my revoker's key for > verification, or even knowing who the revoker might be. > This seems so vastly superior to me that I can't imagine > using the designated revoker facility for this purpose. > (Am I missing something?) Think about this from the perspective of a large company, and it makes more sense. You'd want a company key to be designated revoker for everyone, but storing and keeping track of thousands of revocations is a pain. Having a revocation key that can be used when needed is far simpler. Also, it sounds a bit easier to automate putting the revocation key on each new company key as it is created than it is to automate generating a revocation and sending it to the right person for storage and later use. David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Thu Feb 28 16:10: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 QAA19828 for ; Thu, 28 Feb 2002 16:10:15 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SKPMH16735 for ietf-openpgp-bks; Thu, 28 Feb 2002 12:25:22 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SKPKi16731 for ; Thu, 28 Feb 2002 12:25:20 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id PAA08644 for ; Thu, 28 Feb 2002 15:14:43 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA18065 for ; Thu, 28 Feb 2002 15:25:06 -0500 (EST) Message-ID: <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> <20020228034024.GA678@akamai.com> Subject: Re: Revocation key difficulty Date: Thu, 28 Feb 2002 15:24:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "David Shaw" > Even though the standard allows for more, as far as I know, the only > implementation that does designated revokers is PGP, and it does only > full key revocations (0x20). GnuPG will start doing designated A while back, I tested a third-party scenario: (Alice's designated revoker) Bob revokes Alice's signature of Charlie's key/name. Not only would PGP not let Bob generate a revocation for a certification (unless Bob had also signed Alice's key himself), but it wouldn't recognize one that I manually injected. I don't recall trying to revoke a self-signature: Bob revokes one of Alice's names (not the key). Another aspect I didn't test is what PGP does when the designated revoker's key is not available. I suppose it could check for revocations with a matching "issuer" hint. (Anyone who could tweak the hint could destroy the revocation just as easily anyway.) Does it? If there is a match (but no key), what is the validity decision? > You'd want a company key to be designated revoker for everyone, but > storing and keeping track of thousands of revocations is a pain. Yes, but some pain is required. Something still has to hold onto the keys themselves, specifically the designated revoker subpackets. Otherwise, a user could throw away the designation. I think I'd have enhanced the corporate (key) server rather than complicating the client validity checking. But the whole V4 upgrade (especially the "placeholder for backward compatibility" :-) required changes to client understanding; in for a penny, in for a pound, I suppose. Anyway, sorry to poke at a dead horse... I'll let it go, now. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPH6R9FMkvpTT8vCGEQI47ACgyMoAd8IWgAFhTwjmc798XoFa3E0AnRv0 5T0Q6Y7gUv60fQY27hWG+MnG =dpV9 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Feb 28 18:56: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 SAA26817 for ; Thu, 28 Feb 2002 18:56:27 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1SNhcl21122 for ietf-openpgp-bks; Thu, 28 Feb 2002 15:43:38 -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 g1SNhbi21118 for ; Thu, 28 Feb 2002 15:43:37 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1SNhY109873 for ietf-openpgp@imc.org; Thu, 28 Feb 2002 18:43:34 -0500 Date: Thu, 28 Feb 2002 18:43:34 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020228234334.GE691@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> <20020228034024.GA678@akamai.com> <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> User-Agent: Mutt/1.3.26i X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (97% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Feb 28, 2002 at 03:24:26PM -0500, Michael Young wrote: > Another aspect I didn't test is what PGP does when the designated > revoker's key is not available. I suppose it could check for > revocations with a matching "issuer" hint. (Anyone who could tweak > the hint could destroy the revocation just as easily anyway.) > Does it? If there is a match (but no key), what is the validity decision? If the designated revoker's key is not present, then a key "revoked" by the designated revoker key is not treated as revoked. GnuPG - as of this morning - does it the same way. 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 g1SNhcl21122 for ietf-openpgp-bks; Thu, 28 Feb 2002 15:43:38 -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 g1SNhbi21118 for ; Thu, 28 Feb 2002 15:43:37 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1SNhY109873 for ietf-openpgp@imc.org; Thu, 28 Feb 2002 18:43:34 -0500 Date: Thu, 28 Feb 2002 18:43:34 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020228234334.GE691@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> <20020228034024.GA678@akamai.com> <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> User-Agent: Mutt/1.3.26i X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (97% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Feb 28, 2002 at 03:24:26PM -0500, Michael Young wrote: > Another aspect I didn't test is what PGP does when the designated > revoker's key is not available. I suppose it could check for > revocations with a matching "issuer" hint. (Anyone who could tweak > the hint could destroy the revocation just as easily anyway.) > Does it? If there is a match (but no key), what is the validity decision? If the designated revoker's key is not present, then a key "revoked" by the designated revoker key is not treated as revoked. GnuPG - as of this morning - does it the same way. 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 g1SKPMH16735 for ietf-openpgp-bks; Thu, 28 Feb 2002 12:25:22 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SKPKi16731 for ; Thu, 28 Feb 2002 12:25:20 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id PAA08644 for ; Thu, 28 Feb 2002 15:14:43 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA18065 for ; Thu, 28 Feb 2002 15:25:06 -0500 (EST) Message-ID: <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> <20020228034024.GA678@akamai.com> Subject: Re: Revocation key difficulty Date: Thu, 28 Feb 2002 15:24:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "David Shaw" > Even though the standard allows for more, as far as I know, the only > implementation that does designated revokers is PGP, and it does only > full key revocations (0x20). GnuPG will start doing designated A while back, I tested a third-party scenario: (Alice's designated revoker) Bob revokes Alice's signature of Charlie's key/name. Not only would PGP not let Bob generate a revocation for a certification (unless Bob had also signed Alice's key himself), but it wouldn't recognize one that I manually injected. I don't recall trying to revoke a self-signature: Bob revokes one of Alice's names (not the key). Another aspect I didn't test is what PGP does when the designated revoker's key is not available. I suppose it could check for revocations with a matching "issuer" hint. (Anyone who could tweak the hint could destroy the revocation just as easily anyway.) Does it? If there is a match (but no key), what is the validity decision? > You'd want a company key to be designated revoker for everyone, but > storing and keeping track of thousands of revocations is a pain. Yes, but some pain is required. Something still has to hold onto the keys themselves, specifically the designated revoker subpackets. Otherwise, a user could throw away the designation. I think I'd have enhanced the corporate (key) server rather than complicating the client validity checking. But the whole V4 upgrade (especially the "placeholder for backward compatibility" :-) required changes to client understanding; in for a penny, in for a pound, I suppose. Anyway, sorry to poke at a dead horse... I'll let it go, now. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPH6R9FMkvpTT8vCGEQI47ACgyMoAd8IWgAFhTwjmc798XoFa3E0AnRv0 5T0Q6Y7gUv60fQY27hWG+MnG =dpV9 -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1S3eR414175 for ietf-openpgp-bks; Wed, 27 Feb 2002 19:40:27 -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 g1S3eQi14171 for ; Wed, 27 Feb 2002 19:40:26 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1S3ePV02393 for ietf-openpgp@imc.org; Wed, 27 Feb 2002 22:40:25 -0500 Date: Wed, 27 Feb 2002 22:40:25 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020228034024.GA678@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> User-Agent: Mutt/1.3.26i X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Waning Gibbous (99% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Feb 27, 2002 at 02:28:35PM -0500, Michael Young wrote: > In my previous message, I mentioned the possibility of changing the > designated revoker language to resolve this issue, but I didn't mean > to recommend that. In fact, I might argue that the ability to revoke > individual certifications is the only meaningful use of a designated > revoker. I can see both sides of this issue. On the one hand, additional flexibility in OpenPGP to handle more varied uses is probably good. Having a designated revoker that can revoke key certifications (0x30) has also been in the standard for a long time, though as far as I know, nobody has ever implemented it (I assume if someone had, they'd have had the same problem and raised the same question I did). On the other hand, I'm concerned that giving the designated revoker such fine-grained power to influence previous actions of the key owner could be dangerous. I rather like the idea that the absolute worst thing a rogue designated revoker could do is revoke your key. Even though the standard allows for more, as far as I know, the only implementation that does designated revokers is PGP, and it does only full key revocations (0x20). GnuPG will start doing designated revokers RSN, and I wrote the code to only do full key revocations as well, though I'm open to changing that. > If I want to limit my designated revoker to flushing my whole > key, I can do that *much* more easily -- I can generate my > own revocation, and encrypt it to my designated revoker. > (If you're so afraid that your designee will lose the thing, > put it in a notation packet in another signature, and > ship it off to a keyserver for archiving. ;-) Doing it that > way doesn't depend on everyone having my revoker's key for > verification, or even knowing who the revoker might be. > This seems so vastly superior to me that I can't imagine > using the designated revoker facility for this purpose. > (Am I missing something?) Think about this from the perspective of a large company, and it makes more sense. You'd want a company key to be designated revoker for everyone, but storing and keeping track of thousands of revocations is a pain. Having a revocation key that can be used when needed is far simpler. Also, it sounds a bit easier to automate putting the revocation key on each new company key as it is created than it is to automate generating a revocation and sending it to the right person for storage and later use. 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 g1RJTJk03873 for ietf-openpgp-bks; Wed, 27 Feb 2002 11:29:19 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RJTH303869 for ; Wed, 27 Feb 2002 11:29:17 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id OAA08482 for ; Wed, 27 Feb 2002 14:18:51 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA11052 for ; Wed, 27 Feb 2002 14:29:13 -0500 (EST) Message-ID: <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> Subject: Re: Revocation key difficulty Date: Wed, 27 Feb 2002 14:28:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my previous message, I mentioned the possibility of changing the designated revoker language to resolve this issue, but I didn't mean to recommend that. In fact, I might argue that the ability to revoke individual certifications is the only meaningful use of a designated revoker. If I want to limit my designated revoker to flushing my whole key, I can do that *much* more easily -- I can generate my own revocation, and encrypt it to my designated revoker. (If you're so afraid that your designee will lose the thing, put it in a notation packet in another signature, and ship it off to a keyserver for archiving. ;-) Doing it that way doesn't depend on everyone having my revoker's key for verification, or even knowing who the revoker might be. This seems so vastly superior to me that I can't imagine using the designated revoker facility for this purpose. (Am I missing something?) But if I'm in the habit of making dubious signatures, and want to let someone cancel specific ones, I would need to give my designee an encrypted revocation certificate for each of those as well. Not impossible, but a little more tedious. The designated revoker encoding is more compact. [You might ask: what kind of moron habitually issues questionable signatures? Perhaps an automated corporate ID generator. Why designate a revoker? You might want to destroy away the generator's private key periodically, to prevent additional certifications, but still want to be able to revoke things. A pretty weak example, but the best I can offer. Can anyone else provide a stronger example?] -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPH0zU1MkvpTT8vCGEQJf1gCg6KKDIOn7nir+hG6qDuSFxijshIAAnAmx v9P2qO6mkEVpjgL1XDrks9ia =aQeV -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1RIjLS02980 for ietf-openpgp-bks; Wed, 27 Feb 2002 10:45:21 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RIjJ302976 for ; Wed, 27 Feb 2002 10:45:19 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id NAA29016 for ; Wed, 27 Feb 2002 13:34:53 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA10802 for ; Wed, 27 Feb 2002 13:45:15 -0500 (EST) Message-ID: <003501c1bfbe$d06bc620$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> Subject: Revocation identification (was Re: Revocation key difficulty ) Date: Wed, 27 Feb 2002 13:44:29 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >A while back, someone suggested a "revocation target" signature > > subpacket for revocation signatures that would contain the hash of the > signature that was being revoked. That would fix this problem, but I was that someone. I still think it's a good idea. How can it possibly hurt to identify the exact signature being revoked? It can't be the few extra bytes... it would be a small fraction of the total, and revocations should be rare, anyway. Even if the current issue is resolved by removing the language about designated revokers issuing certification revocations, there are other ambiguities that this would solve. I think it is quite valid for one key to sign something multiple times, with a different: signature class; expiration time; notation; preferred algorithm; or, almost any other optional subpacket. Some have suggested using the timestamp to decide which signatures a revocation covers, but others have objected. I see no need to depend on timestamps -- the hash identifies the signature perfectly. When it last came up, Jon asked if anyone would implement it, and Werner said he would not. Since my implementation is not yet (and may never be) public, I didn't feel qualified to say "yes". But I suppose that either David or I could implement it in GnuPG, if Werner would pick up the change. I'm not asking for this to be a MUST. Old revocations (and even new V3 ones) will not have the subpacket, so no implementation should depend on it. I'd suggest making it a SHOULD. Any other supporters out there? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPH0o6lMkvpTT8vCGEQLzqgCg6XkUpNjS5upTC6T48I6N4oIN8pQAoLeG /Dd+yQd1b1vluVFKHD6fAa5H =epkZ -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1RI1F601922 for ietf-openpgp-bks; Wed, 27 Feb 2002 10:01:15 -0800 (PST) Received: from hotmail.com (oe28.law3.hotmail.com [209.185.240.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1RI1D301917 for ; Wed, 27 Feb 2002 10:01:13 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Feb 2002 09:50:04 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: References: <20020226235738.GF5246@akamai.com> Subject: Re: Revocation key difficulty Date: Wed, 27 Feb 2002 11:42:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Message-ID: X-OriginalArrivalTime: 27 Feb 2002 17:50:04.0887 (UTC) FILETIME=[30088670:01C1BFB7] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Original Message ----- From: "David Shaw" To: Sent: Tuesday, February 26, 2002 6:57 PM Subject: Re: Revocation key difficulty > > On Tue, Feb 26, 2002 at 05:22:35PM -0600, john.dlugosz@kodak.com wrote: > > > Hmm, so how would it be used? Alice had signed Charlie's key, and now > > Alice's key is compromised, so Bob decides to remove Alice's signature from > > Charlie's key. Why? ... > Exactly. It seems to make more sense to Bob for issue a general key > revocation (sigclass 0x20) for Alice's key, rather than issue a > certification revocation (sigclass 0x30) for Alice's signature on > Charlie's key. ... A possible reason why it may be beneficial to to have a revoker selectively revoke only the signature, may be if one is forced to give up an RSA encryption key. {Hopefully, this should never have to be, and the session key should be enough for the authorities, but if it 'were' to happen ...,} Then, to avoid anyone else signing with Alice's key {if it would be surrendered}, Alice may want two separate RSA keys, her original one for encrypting, and another one for signing. Alice then publicly declares that she is no longer signing with her original RSA key. Sometime later, someone else's key that Alice once signed, is now 'questionable', and Alice wants her signature removed. Now her designated revoker can accomplish this. vedaal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1QNvi226612 for ietf-openpgp-bks; Tue, 26 Feb 2002 15:57:44 -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 g1QNvh326608 for ; Tue, 26 Feb 2002 15:57:43 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1QNvci11946 for ietf-openpgp@imc.org; Tue, 26 Feb 2002 18:57:38 -0500 Date: Tue, 26 Feb 2002 18:57:38 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020226235738.GF5246@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: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Full Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Feb 26, 2002 at 05:22:35PM -0600, john.dlugosz@kodak.com wrote: > Hmm, so how would it be used? Alice had signed Charlie's key, and now > Alice's key is compromised, so Bob decides to remove Alice's signature from > Charlie's key. Why? Well, perhaps Alice is a manager and Charlie is an > employee, and Bob is the tech doing all the work. Bob is cleaning all the > underling's keys and doesn't want to ask Alice to get involved, or maybe > she is out of reach. > > So, why is it necessary to remove Alice's signature from Charlie's key? > Anyone who verifies Charlie's key will see that Alice's has been revoked > and will know to ignore it. If you're going to distribute this > second-party revokation of signatures, why not just send out a generic > "Alice's key is bad" revokation, and that implies that it ought to be > removed from certificates too? Exactly. It seems to make more sense to Bob for issue a general key revocation (sigclass 0x20) for Alice's key, rather than issue a certification revocation (sigclass 0x30) for Alice's signature on Charlie's key. The problem I'm having is that the RFC says that Bob can issue a certification revocation (0x30. NOT 0x20). I'm not saying this is smart, a good idea, or best practice, but the RFC explicitly says it is possible. If Bob does this, there is no way to differentiate between Bob's certification revocation (0x30) of Bob's certification (0x10) of Charlie's key and Bob's certification revocation (0x30) of Alice's certification (0x10) of Charlie's key. I'm including sigclasses here to help make what I'm saying clear. The words "certificate" and "certification" are just too similar and I think I swapped them once or twice in my original mail. Sorry folks. 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 g1QNcoK26260 for ietf-openpgp-bks; Tue, 26 Feb 2002 15:38:50 -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 g1QNcn326256 for ; Tue, 26 Feb 2002 15:38:49 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1QNchQ10917; Tue, 26 Feb 2002 18:38:43 -0500 Date: Tue, 26 Feb 2002 18:38:43 -0500 From: David Shaw To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020226233843.GE5246@akamai.com> Mail-Followup-To: Jon Callas , ietf-openpgp@imc.org References: <20020226205856.GB5246@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: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Full Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Feb 26, 2002 at 02:52:33PM -0800, Jon Callas wrote: > > At 3:58 PM -0500 2/26/02, David Shaw wrote: > > >The problem with certificate revocations is that it is not possible in > >some cases to know which certificate is being revoked. For example, > >take Alice, Bob, and Charlie. Bob is Alice's designated revoker. > >Alice and Bob have both signed Charlie's key. Now Alice asks Bob to > >revoke her signature on Charlie's key. > > > >Since both Alice and Bob have signed Charlie's key, and the format of > >a revocation that is issued by a designated revoker is the same as a > >revocation issued by the key owner, the OpenPGP program has no way to > >tell which certification is being revoked: is it Bob's or is it > >Alice's? > > Ummm, that's certificate revocation, not certification revocation. A PGP > certificate (a.k.a. key) contains a collection of certifications. It is > these certifications (colloquially key signatures) that determine a > certificate's validity. > > A certificate revocation makes the certificate dead. It cancels the > *entire* certificate, regardless of anything else. Well understood and agreed, but I really did mean what I said. The RFC says (section 5.2.1): 0x30: Certification revocation signature This signature revokes an earlier user ID certification signature (signature class 0x10 through 0x13). It should be issued by the same key that issued the revoked signature or an authorized revocation key The signature should have a later creation date than the signature it revokes. Am I somehow misreading this? To my eye, this says an authorized revocation key can issue a genuine 0x30 *certification* revocation signature. 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 g1QNMhQ25924 for ietf-openpgp-bks; Tue, 26 Feb 2002 15:22:43 -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 g1QNMg325920 for ; Tue, 26 Feb 2002 15:22:42 -0800 (PST) Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g1QNMkK29840; Tue, 26 Feb 2002 18:22:46 -0500 (EST) Subject: Re: Revocation key difficulty To: dshaw@akamai.com Cc: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Tue, 26 Feb 2002 17:22:35 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 02/26/2002 06:22:38 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 ===== A while back, someone suggested a "revocation target" signature subpacket for revocation signatures that would contain the hash of the signature that was being revoked. That would fix this problem, but I'm open to any solution - does it even make sense to allow a revocation key to issue certificate revocations? I always thought of the revocation key as the "revoker of last resort" - more for emergency key revocations in case of compromise or secret key loss than for fine-grained control of previously issued signatures. ===== Hmm, so how would it be used? Alice had signed Charlie's key, and now Alice's key is compromised, so Bob decides to remove Alice's signature from Charlie's key. Why? Well, perhaps Alice is a manager and Charlie is an employee, and Bob is the tech doing all the work. Bob is cleaning all the underling's keys and doesn't want to ask Alice to get involved, or maybe she is out of reach. So, why is it necessary to remove Alice's signature from Charlie's key? Anyone who verifies Charlie's key will see that Alice's has been revoked and will know to ignore it. If you're going to distribute this second-party revokation of signatures, why not just send out a generic "Alice's key is bad" revokation, and that implies that it ought to be removed from certificates too? Received: by above.proper.com (8.11.6/8.11.3) id g1QMqsG25450 for ietf-openpgp-bks; Tue, 26 Feb 2002 14:52:54 -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 g1QMqr325446 for ; Tue, 26 Feb 2002 14:52:53 -0800 (PST) Received: from [63.73.97.188] (64.69.113.115) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3); Tue, 26 Feb 2002 14:52:43 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20020226205856.GB5246@akamai.com> References: <20020226205856.GB5246@akamai.com> Date: Tue, 26 Feb 2002 14:52:33 -0800 To: David Shaw , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Revocation key difficulty Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 3:58 PM -0500 2/26/02, David Shaw wrote: >The problem with certificate revocations is that it is not possible in >some cases to know which certificate is being revoked. For example, >take Alice, Bob, and Charlie. Bob is Alice's designated revoker. >Alice and Bob have both signed Charlie's key. Now Alice asks Bob to >revoke her signature on Charlie's key. > >Since both Alice and Bob have signed Charlie's key, and the format of >a revocation that is issued by a designated revoker is the same as a >revocation issued by the key owner, the OpenPGP program has no way to >tell which certification is being revoked: is it Bob's or is it >Alice's? Ummm, that's certificate revocation, not certification revocation. A PGP certificate (a.k.a. key) contains a collection of certifications. It is these certifications (colloquially key signatures) that determine a certificate's validity. A certificate revocation makes the certificate dead. It cancels the *entire* certificate, regardless of anything else. Here's a scenario like yours: Alice and Bob have both signed Charlie's key. Alice is also a designated revoker on Charlie's key. When Alice issues a certificate revocation for Charlie's key (a.k.a. certificate), then Charlie's key is revoked. It is an ex-certificate and has joined the Choir Eternal. It has ceased to be. It no longer matters that Bob signed Charlie's key. It no longer matters that David through Zelda inclusive has signed it. It is no longer valid. This is just like what would happen if Charlie issued that revocation himself. Now, then, there are some unresolved issues related to this. Is the contract that Bob signed two years ago with me now suddenly void? I think not. There are, however, people I respect who think it is. But that's a different discussion. Jon Received: by above.proper.com (8.11.6/8.11.3) id g1QKx7B22798 for ietf-openpgp-bks; Tue, 26 Feb 2002 12:59:07 -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 g1QKx4322794 for ; Tue, 26 Feb 2002 12:59:05 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g1QKwuB05601 for ietf-openpgp@imc.org; Tue, 26 Feb 2002 15:58:56 -0500 Date: Tue, 26 Feb 2002 15:58:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Revocation key difficulty Message-ID: <20020226205856.GB5246@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.26i X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-URL: http://www.jabberwocky.com/ X-Phase-Of-Moon: The Moon is Full Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi folks, While implementing revocation key ("designated revoker") support for GnuPG, I came across what seems to be a problem in the specificaiton of revocation keys. The RFC says the key designated as the revocation key can issue several types of revocations: key revocations (0x20), subkey revocations (0x28), and certificate revocations (0x30). The first two are not a problem since there is no confusion as to what they revoke. The problem with certificate revocations is that it is not possible in some cases to know which certificate is being revoked. For example, take Alice, Bob, and Charlie. Bob is Alice's designated revoker. Alice and Bob have both signed Charlie's key. Now Alice asks Bob to revoke her signature on Charlie's key. Since both Alice and Bob have signed Charlie's key, and the format of a revocation that is issued by a designated revoker is the same as a revocation issued by the key owner, the OpenPGP program has no way to tell which certification is being revoked: is it Bob's or is it Alice's? A while back, someone suggested a "revocation target" signature subpacket for revocation signatures that would contain the hash of the signature that was being revoked. That would fix this problem, but I'm open to any solution - does it even make sense to allow a revocation key to issue certificate revocations? I always thought of the revocation key as the "revoker of last resort" - more for emergency key revocations in case of compromise or secret key loss than for fine-grained control of previously issued signatures. 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 g1OAVWn00555 for ietf-openpgp-bks; Sun, 24 Feb 2002 02:31:32 -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 g1OAVS300541 for ; Sun, 24 Feb 2002 02:31:30 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Sun, 24 Feb 2002 12:26:34 0200 Message-ID: <3C78BFD9.A8FD4E7D@saiknes.lv> Date: Sun, 24 Feb 2002 12:26:33 +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: Alice, Bob, ... Foo, bar? 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 John Dlugosz wrote: > I know about Alice and Bob in general. But does anyone have a pointer to a > complete list of which names are commonly used, and what Roles those names > are used for? E.g. Eve is used for an evesdropper. Someone else (I forgot > who) can alter packets, though. > --John see: http://www.cs.man.ac.uk/~chl/scenarios.html __ 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/AwUBPHijjzBaTVEuJQxkEQPuGgCgsY7vvA6EvEUnoZJJMobVX+Jr/GgAoKN1 7Smem766Jyk8nVpP0bdqT/ff =HBeV -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1MMgd614883 for ietf-openpgp-bks; Fri, 22 Feb 2002 14:42:39 -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 g1MMgc314878 for ; Fri, 22 Feb 2002 14:42:38 -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 RAA22274; Fri, 22 Feb 2002 17:42:40 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA17631; Fri, 22 Feb 2002 17:42:37 -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 RAA17776; Fri, 22 Feb 2002 17:42:34 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA13772; Fri, 22 Feb 2002 17:42:34 -0500 (EST) To: "Dominikus Scherkl" Cc: From: Derek Atkins Subject: Re: OpenPGP vs. X.509/PKCS References: <3DD04EB2E6FBEB47896D9CD157CBB83D04520D@bbq1m003.biodata.org> Date: 22 Feb 2002 17:42:34 -0500 In-Reply-To: <3DD04EB2E6FBEB47896D9CD157CBB83D04520D@bbq1m003.biodata.org> Message-ID: Lines: 34 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: Give me a patent-free ECC algorithm that has reasonable performance. Replies to /dev/null, please. -derek "Dominikus Scherkl" writes: > > At the time PGP was created, there were a LOT of things that PGP > > could offer than X.509 could not. To name a few: > > > > - PGP certificates are MUCH smaller than X.509 in terms of > the number > > of bytes required to represent the same semantic content. > > If you see this as an important advantage, I can't understand why > still nobody is iteressted in integrating elliptic curves into the > openPGP standard (as I proposed in last august, you may find it at: > http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt). > > This Draft is now expired, but I still want it to become part > of openPGP. > > PS: my mail-account has changed: > > -- > Dominikus Scherkl > Mail: dominikusscherkl@glueckkanja.com > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MKUlB12446 for ietf-openpgp-bks; Fri, 22 Feb 2002 12:30:47 -0800 (PST) Received: from diplomatic.passport.ca (mail.passport.ca [204.225.103.222]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MKUj312442 for ; Fri, 22 Feb 2002 12:30:45 -0800 (PST) Received: from passport.ca ([207.112.115.244]) by diplomatic.passport.ca (8.11.3/8.11.3) with ESMTP id g1MKU5S10098; Fri, 22 Feb 2002 15:30:06 -0500 (EST) Message-ID: <3C76AA4D.D50778EA@passport.ca> Date: Fri, 22 Feb 2002 15:30:05 -0500 From: Paul Shields X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Joe Tag CC: rguerra@yahoo.com, john.dlugosz@kodak.com, ietf-openpgp@imc.org Subject: Re: Alice, Bob, ... Foo, bar? References: <20020222.144757.-713507.0.joe.tag@juno.com> 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: Also: Malcolm: the man in the middle, an active attacker who can alter messages, forge packets, certificates, etc. Joe Tag wrote: > Hi, > > You can also find the reference in Schneir __Applied_Crytography__ text; > and in > Pfleeger's __Security_in_Computing__ . > Koblitz in his __Number_Theory_and_Crypto__ used names like > 'Aida' and 'Bernardo'. > > I like 'Anna' ( think the old morse code naviation system " . _ " = a ; "_ > ." = n; and > ''Anna'' is a 'palindrome name' ; You could use also, "Alyssa" (think > Milano). > Boris (Russion), Bruce. > Carol, Carl, Carlos, Charles is the "Certificate Authority" > 'Evan' could also be an eavesdropper (just think Evil). > "Trent" is the "Digital 'Trusted' Notary. Also known as "Ted". > > Sincerely yours, > > Joe Tag,Jr. > > http://www.kean.edu/~jtag > > On Fri, 22 Feb 2002 12:51:55 -0500 (EST) Robert Guerra > writes: > > > > The Alice and Bob After Dinner Speech > > given at the Zurich Seminar, April 1984 > > by John Gordon > > > > http://www.conceptlabs.co.uk/alicebob.html > > > > On Fri, 22 Feb 2002 john.dlugosz@kodak.com wrote: > > > > > > From: John Dlugosz > > > > > > I know about Alice and Bob in general. But does anyone have a pointer > to a > > > complete list of which names are commonly used, and what Roles those > names > > > are used for? E.g. Eve is used for an evesdropper. Someone else > > > (I forgot who) can alter packets, though. > > > > > > --John Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MJmks11397 for ietf-openpgp-bks; Fri, 22 Feb 2002 11:48:46 -0800 (PST) Received: from m11.jersey.juno.com (m11.jersey.juno.com [64.136.16.74]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MJmj311391 for ; Fri, 22 Feb 2002 11:48:45 -0800 (PST) Received: from cookie.juno.com by cookie.juno.com for <"xS5dSbQuAOKnbKF9wbUrHN7eQ5MrSfHN1OQ+CU8aSxySJLirJ69MZg=="> Received: (from joe.tag@juno.com) by m11.jersey.juno.com (jqueuemail) id GUAC82KD; Fri, 22 Feb 2002 14:48:08 EST To: rguerra@yahoo.com Cc: john.dlugosz@kodak.com, ietf-openpgp@imc.org Date: Fri, 22 Feb 2002 14:47:56 -0500 Subject: Re: Alice, Bob, ... Foo, bar? Message-ID: <20020222.144757.-713507.0.joe.tag@juno.com> X-Mailer: Juno 5.0.33 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Juno-Line-Breaks: 0-1,3-7,9,11-25,27-58 From: Joe Tag Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, You can also find the reference in Schneir __Applied_Crytography__ text; and in Pfleeger's __Security_in_Computing__ . Koblitz in his __Number_Theory_and_Crypto__ used names like 'Aida' and 'Bernardo'. I like 'Anna' ( think the old morse code naviation system " . _ " = a ; "_ ." = n; and ''Anna'' is a 'palindrome name' ; You could use also, "Alyssa" (think Milano). Boris (Russion), Bruce. Carol, Carl, Carlos, Charles is the "Certificate Authority" 'Evan' could also be an eavesdropper (just think Evil). "Trent" is the "Digital 'Trusted' Notary. Also known as "Ted". Sincerely yours, Joe Tag,Jr. http://www.kean.edu/~jtag On Fri, 22 Feb 2002 12:51:55 -0500 (EST) Robert Guerra writes: > > The Alice and Bob After Dinner Speech > > given at the Zurich Seminar, April 1984 > > by John Gordon > > > http://www.conceptlabs.co.uk/alicebob.html > > On Fri, 22 Feb 2002 john.dlugosz@kodak.com wrote: > > > > > From: John Dlugosz > > > > I know about Alice and Bob in general. But does anyone have a > pointer to a > > complete list of which names are commonly used, and what Roles > those names > > are used for? E.g. Eve is used for an evesdropper. Someone else > (I forgot > > who) can alter packets, though. > > > > --John > > > > > > -- > Robert Guerra > Director, Computer Professionals for Social Responsibility (CPSR) > > ________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/web/. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHq4m08935 for ietf-openpgp-bks; Fri, 22 Feb 2002 09:52:04 -0800 (PST) Received: from tomts21-srv.bellnexxia.net (tomts21.bellnexxia.net [209.226.175.183]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MHq2308931 for ; Fri, 22 Feb 2002 09:52:02 -0800 (PST) Received: from [192.168.1.101] ([64.229.184.93]) by tomts21-srv.bellnexxia.net (InterMail vM.4.01.03.23 201-229-121-123-20010418) with ESMTP id <20020222175151.OOAZ805.tomts21-srv.bellnexxia.net@[192.168.1.101]>; Fri, 22 Feb 2002 12:51:51 -0500 Date: Fri, 22 Feb 2002 12:51:55 -0500 (EST) From: Robert Guerra X-X-Sender: rguerra@med.mine.nu To: john.dlugosz@kodak.com cc: ietf-openpgp@imc.org Subject: Re: Alice, Bob, ... Foo, bar? In-Reply-To: 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: The Alice and Bob After Dinner Speech given at the Zurich Seminar, April 1984 by John Gordon http://www.conceptlabs.co.uk/alicebob.html On Fri, 22 Feb 2002 john.dlugosz@kodak.com wrote: > > From: John Dlugosz > > I know about Alice and Bob in general. But does anyone have a pointer to a > complete list of which names are commonly used, and what Roles those names > are used for? E.g. Eve is used for an evesdropper. Someone else (I forgot > who) can alter packets, though. > > --John > > -- Robert Guerra Director, Computer Professionals for Social Responsibility (CPSR) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHFLZ08162 for ietf-openpgp-bks; Fri, 22 Feb 2002 09:15:21 -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 g1MHFJ308158 for ; Fri, 22 Feb 2002 09:15:20 -0800 (PST) Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g1MHFQi07180 for ; Fri, 22 Feb 2002 12:15:26 -0500 (EST) Subject: Alice, Bob, ... Foo, bar? To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Fri, 22 Feb 2002 11:15:15 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 02/22/2002 12:15:21 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 I know about Alice and Bob in general. But does anyone have a pointer to a complete list of which names are commonly used, and what Roles those names are used for? E.g. Eve is used for an evesdropper. Someone else (I forgot who) can alter packets, though. --John Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1MHCOO08075 for ietf-openpgp-bks; Fri, 22 Feb 2002 09:12:24 -0800 (PST) Received: from mail1.biodata.com (mail1.biodata.com [62.159.113.2] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1MHCN308070 for ; Fri, 22 Feb 2002 09:12:23 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: OpenPGP vs. X.509/PKCS Date: Fri, 22 Feb 2002 18:09:16 +0100 Message-ID: <3DD04EB2E6FBEB47896D9CD157CBB83D04520D@bbq1m003.biodata.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OpenPGP vs. X.509/PKCS Thread-Index: AcG7K+2Xu9ermtr6QdWw5CoNHgn1WwAbPSZgAAqybnA= From: "Dominikus Scherkl" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1MHCN308071 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > At the time PGP was created, there were a LOT of things that PGP > could offer than X.509 could not. To name a few: > > - PGP certificates are MUCH smaller than X.509 in terms of the number > of bytes required to represent the same semantic content. If you see this as an important advantage, I can't understand why still nobody is iteressted in integrating elliptic curves into the openPGP standard (as I proposed in last august, you may find it at: http://www.ietf.org/internet-drafts/draft-scherkl-openpgp-ecc-00.txt). This Draft is now expired, but I still want it to become part of openPGP. PS: my mail-account has changed: -- Dominikus Scherkl Mail: dominikusscherkl@glueckkanja.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LN2os03747 for ietf-openpgp-bks; Thu, 21 Feb 2002 15:02:50 -0800 (PST) Received: from muppet.faveve.uni-stuttgart.de (mail@muppet.faveve.uni-stuttgart.de [129.69.139.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LN2n303743 for ; Thu, 21 Feb 2002 15:02:49 -0800 (PST) Received: from delta by muppet.faveve.uni-stuttgart.de with local (Exim 3.13 #1) id 16e2Ec-0004Cl-00 for ietf-openpgp@imc.org; Fri, 22 Feb 2002 00:02:42 +0100 Date: Fri, 22 Feb 2002 00:02:42 +0100 From: Helmut Springer To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. X.509/PKCS Message-ID: <20020221230242.GZ15932@faveve.uni-stuttgart.de> 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: 1024/864FB4AD AE 42 C3 2C A1 3E 55 6D B3 AC 3C D2 F3 CF FF E7 X-pgp-key-url: http://www.citecs.de/pgpkey.delta.asc Organization: elite[tm] since running completely computer based FAX Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 21 Feb 2002 at 23:17 +0100, Leon Kuunders wrote: > So the question is: how could we turn OpenPGP into a > more-money-making infrastructure? And that comes down to: what Title : Extensions to TLS for OpenPGP keys Author(s) : W. Price, M. Elkins Filename : draft-ietf-tls-openpgp-02.txt Pages : 4 Date : 19-Feb-02 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-02.txt Comes to mind. Interoperability with SSH would be another step towards a "complete" PKI solution. But then you need both a need for PKIs and widely used software to generate real money... -- MfG/best regards, helmut springer "Freedom's just another word for nothing left to lose" Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMk1103406 for ietf-openpgp-bks; Thu, 21 Feb 2002 14:46:01 -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 g1LMk0303400 for ; Thu, 21 Feb 2002 14:46:00 -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 RAA11223; Thu, 21 Feb 2002 17:46:02 -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 RAA27857; Thu, 21 Feb 2002 17:46:02 -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 RAA20894; Thu, 21 Feb 2002 17:46:01 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id RAA12673; Thu, 21 Feb 2002 17:46:00 -0500 (EST) To: "Leon Kuunders" Cc: , From: "Derek Atkins" Subject: Re: OpenPGP vs. X.509/PKCS References: Date: 21 Feb 2002 17:46:00 -0500 In-Reply-To: Message-ID: Lines: 70 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: At the time PGP was created, there were a LOT of things that PGP could offer than X.509 could not. To name a few: - PGP certificates are MUCH smaller than X.509 in terms of the number of bytes required to represent the same semantic content. - at the time X.509 certificates could only carry a single signature, forcing users into a strict hierarchical model, whereas PGP allows the opportunity for a more web-like model that better mirrors real-world relationships. - PGP certificates are self-generated, and require no interaction with anybody in order to start using the system, wheras with X.509 you need to get your key signed by an authority before you can use it at all. Note that the question you are asking does not necessarily follow from the question that I answered. The question was about why PKCS was created. PKCS came from RSADSI, which was the company that owned the RSA patent. They created the PKCS standards. As for why X.509 took off? It took off because there was money to be made when you force users to use your services (read: you're a CA), and because you have a business whereas PGP does not. (Note that all this happened in the early 90s, well before PGP, Inc. existed). -derek "Leon Kuunders" writes: > So the question is: how could we turn OpenPGP into a more-money-making > infrastructure? And that comes down to: what kind of need would there be for > OpenPGP? If there is already X509? What can OpenPGP do what the other one > can't? And what kind of business model would go with that? > > Is it feasible to think that as long as the 'mainstream' is not convinced of > the fact that OpenPGP can bring them _more_ money than X509 - that this > battle is moving towards a definite end? > > -Leon. > > > From: Derek Atkins > > > > Because "they" weren't making any money off of PGP. :) > > > > -derek > > > > john.dlugosz@kodak.com writes: > > > > > From: John Dlugosz > > > > > > If PGP was indeed established as the first useful PK system, > > why did "they" > > > come up with PKCS standards that are totally different? Why > > did PKCS-style > > > files and formats propigate through Internet standards, when all along > > > everyone was using PGP, and had access to that code? > > > > > > > -- > > Derek Atkins > > Computer and Internet Security Consultant > > derek@ihtfp.com www.ihtfp.com > > > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LMI0c02822 for ietf-openpgp-bks; Thu, 21 Feb 2002 14:18:00 -0800 (PST) Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LMHx302818 for ; Thu, 21 Feb 2002 14:17:59 -0800 (PST) Received: from pc5211wxptfm (cp92837-a.dbsch1.nb.nl.home.com [217.120.34.92]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with SMTP id g1LMHlsX044210; Thu, 21 Feb 2002 23:17:47 +0100 (CET) From: "Leon Kuunders" To: "Derek Atkins" , Cc: Subject: RE: OpenPGP vs. X.509/PKCS Date: Thu, 21 Feb 2002 23:17:43 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: So the question is: how could we turn OpenPGP into a more-money-making infrastructure? And that comes down to: what kind of need would there be for OpenPGP? If there is already X509? What can OpenPGP do what the other one can't? And what kind of business model would go with that? Is it feasible to think that as long as the 'mainstream' is not convinced of the fact that OpenPGP can bring them _more_ money than X509 - that this battle is moving towards a definite end? -Leon. > From: Derek Atkins > > Because "they" weren't making any money off of PGP. :) > > -derek > > john.dlugosz@kodak.com writes: > > > From: John Dlugosz > > > > If PGP was indeed established as the first useful PK system, > why did "they" > > come up with PKCS standards that are totally different? Why > did PKCS-style > > files and formats propigate through Internet standards, when all along > > everyone was using PGP, and had access to that code? > > > > -- > Derek Atkins > Computer and Internet Security Consultant > derek@ihtfp.com www.ihtfp.com > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LLOZw01438 for ietf-openpgp-bks; Thu, 21 Feb 2002 13:24:35 -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 g1LLOY301434 for ; Thu, 21 Feb 2002 13:24:34 -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 QAA08942; Thu, 21 Feb 2002 16:24:36 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14024; Thu, 21 Feb 2002 16:24:35 -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 QAA18672; Thu, 21 Feb 2002 16:24:34 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id QAA08940; Thu, 21 Feb 2002 16:24:33 -0500 (EST) To: john.dlugosz@kodak.com Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: OpenPGP vs. X.509/PKCS References: Date: 21 Feb 2002 16:24:33 -0500 In-Reply-To: Message-ID: Lines: 18 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: Because "they" weren't making any money off of PGP. :) -derek john.dlugosz@kodak.com writes: > From: John Dlugosz > > If PGP was indeed established as the first useful PK system, why did "they" > come up with PKCS standards that are totally different? Why did PKCS-style > files and formats propigate through Internet standards, when all along > everyone was using PGP, and had access to that code? > -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LLBsi01129 for ietf-openpgp-bks; Thu, 21 Feb 2002 13:11:54 -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 g1LLBr301124 for ; Thu, 21 Feb 2002 13:11:53 -0800 (PST) Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g1LLC1a05770 for ; Thu, 21 Feb 2002 16:12:01 -0500 (EST) Subject: OpenPGP vs. X.509/PKCS To: ietf-openpgp@imc.org From: john.dlugosz@kodak.com Date: Thu, 21 Feb 2002 15:11:50 -0600 Message-ID: X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 02/21/2002 04:11:55 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 If PGP was indeed established as the first useful PK system, why did "they" come up with PKCS standards that are totally different? Why did PKCS-style files and formats propigate through Internet standards, when all along everyone was using PGP, and had access to that code? Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1LJlQO29057 for ietf-openpgp-bks; Thu, 21 Feb 2002 11:47:26 -0800 (PST) Received: from hotmail.com (oe20.law3.hotmail.com [209.185.240.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1LJlP329053 for ; Thu, 21 Feb 2002 11:47:25 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 21 Feb 2002 11:47:22 -0800 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: pgp oddities Date: Thu, 21 Feb 2002 14:38:14 -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: 21 Feb 2002 19:47:22.0830 (UTC) FILETIME=[947EE6E0:01C1BB10] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 have compiled a list of pgp oddities, composed of examples of what can be done to a pgp message and still have it decrypt / verify and what minor changes will invalidate it, and what differences there are between pgp and gnupg in how these changes are accepted. the site is here: http://www.angelfire.com/pr/pgpf/pgpoddities.html except for one clearsigned message done using winpt, all the messages were generated using pgp 6.5.8 ckt build 6 some of the examples may be helpful in considering any recommendations for open pgp format of pgp messages vedaal -----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 iQEVAwUBPHVMo2oFoLeFMG0lAQNQnwf/fv0hd7QAkhlDf1iU5bL/z8Qb4RgF0DGd 6HT5P+IcqN/8HQlC/DLIwt+gMP1PqbE6UVWu58pX6fZUPyeQugdRNIw+cW0me+rQ S38KxM8lBzvKmyx2qRz8K3CrdUiXWd2gxGSPFBW/tm8YtTsx1mOEs17tZuWFeRKp PG6B1tqK37XvQD6qCOzlH9YLp3QaC2u6Gc+8xPB2SBTLAuYdU1Box/RUfntDsnlb cQx1LvLWPKUr8QmOiFgZ5J6HxCT8GLhOqZDt3FMEq64RdBHvwZLJWZqiBLE7IX// kN3hWuwQrQArfPvO9WhXSUG2g9Xas/tsG78yKxJst7WgzzwUM6Xnog== =/VSu -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1H0MNQ07709 for ietf-openpgp-bks; Sat, 16 Feb 2002 16:22:23 -0800 (PST) Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1H0ML307703 for ; Sat, 16 Feb 2002 16:22:21 -0800 (PST) Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 2EE292C91 for ; Sun, 17 Feb 2002 01:22:13 +0100 (MET) Received: id ; Sun, 17 Feb 2002 01:21:14 +0100 (CET) Message-Id: Date: Sun, 17 Feb 2002 01:21:14 +0100 (CET) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME In-Reply-To: References: <20020213095005.GA6830@sobolev.does-not-exist.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas : > At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: >>> does not work with many mailing lists (that are configured to >>> remove attachments), >> Such mailing lists are broken. > As someone who runs a number of such "broken" mailing lists, I "broke" them > because I consider the security risk of my list being use to spread the > latest Outlook thingie to be much higher than the damage caused by breaking > them. So it's not about multipart messages, but about dangerous Content-Types? Dangerous Content-Type values have nothing to do with whether a message is a multipart message or not. Any Content-Type can be named directly in the main message headers, and completely harmless Content-Types can be named in the individual body parts of a multipart message. > It also prevents the inevitable newbie who sends a picture or movie > as an attachment, causing a dozen people to go over their mail quotas. Again, this has nothing to do with multiparts. If you want to prevent huge messages, set an appropriate message size limit. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FGduk07078 for ietf-openpgp-bks; Fri, 15 Feb 2002 08:39:56 -0800 (PST) Received: from xfw.transarc.ibm.com (xfw.transarc.ibm.com [192.54.226.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1FGdn307071 for ; Fri, 15 Feb 2002 08:39:54 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by xfw.transarc.ibm.com (AIX4.3/UCB 8.7/8.7) with ESMTP id LAA30068 for ; Fri, 15 Feb 2002 11:29:18 -0500 (EST) Received: from mwyoung (dhcp-195-23.transarc.ibm.com [9.38.195.223]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA04402 for ; Fri, 15 Feb 2002 11:39:28 -0500 (EST) Message-ID: <004d01c1b63f$4ce5ad80$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode Date: Fri, 15 Feb 2002 11:39:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >I want to mention that I want to keep a secret key in format OpenPGP not > > a plain text. In this context, the "multi-precision integers comprising the secret key data" are the plaintext. > 1) What value should I fill in IV? In the secret key context, the IV should be filled with random bits. That IV is included in the unencrypted section of the secret key packet. For message packets, the IV is initially zero, but the first material to be encrypted is random, which has similar effect. > 2) Are those BS+2 octets just for plain text or even for secret key > material? The "BS+2" scheme is only used in the Symmetrically Encrypted Data ("message") packets. Secret key material is encrypted in a pure CFB mode; see below. > >3. FRE is xored with the first BS octets of random data prefixed to > >the plaintext to produce C[1] through C[BS], the first BS octets > >of ciphertext. > > 3) Do the C[i] octets represent the final form for OpenPGP format? Yes. > 4) Let's assume that I encrypt the algorithm-specific portion with IDEA. > What it happens with the last block of data if the length of the > algorithm-specific portion is not multiple of 8 (64 bit)? (and, of > course, the last block it will be less than BS - in this case 8 octets) CFB mode can use any "block size". The underlying cipher is always applied to the "feedback register", which is a whole block, even if the CFB input is smaller. If the CFB input is N bytes, only the first N bytes of the encrypted feedback register are used; they are XORed with the CFB input to form the CFB output. The CFB output is then shifted into the feedback register. The "block size" under CFB can even change from one input to the next. To decrypt, you also need to know how the data was blocked. RFC2440 uses the phrase "resync" to describe where blocks smaller than the underlying cipher are processed. For example, at the front of a message packet, a full block of random material is processed, following by an 2-byte block of repeated material -- those two bytes are *not* combined with subsequent plaintext to form a "full block", but are processed by themselves. Also, version 3 secret keys are processed one MPI at a time (including only the data, not the length), so the last bytes of each MPI may be a short block. Here is some Java-like pseudo-code for CFB that isn't tied to the OpenPGP behavior. Cipher engine; // underlying cipher, used in "ECB" mode byte [] FR; // feedback register, block-sized; initialized with IV void cfb_encrypt(byte [] src, byte [] dest, int length) { // assumes length <= ECB block size; if not, reject or break up the input // encrypt the FR, and XOR first "length" bytes with src into dest byte [] FRE = engine.encrypt(FR); for (int i = 0; i < length; i++) dest[i] = src[i] ^ FRE[i]; // shift "length" bytes of result into FR int j = 0; for (int i = length; i < FR.length; i++) FR[j++] = FR[i]; for (int i = 0; j < FR.length; i++) FR[j++] = dest[i]; } -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPG048VMkvpTT8vCGEQLuywCgmiCqp2qjFiKH0fSqqFnhz7Z6LScAn21L OkR7fcgruGz8T/RzfX3jv+zm =PnMc -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1FEQJh00511 for ietf-openpgp-bks; Fri, 15 Feb 2002 06:26:19 -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 g1FEQI300503 for ; Fri, 15 Feb 2002 06:26:18 -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 JAA14420; Fri, 15 Feb 2002 09:26:18 -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 JAA24305; Fri, 15 Feb 2002 09:26:18 -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 JAA16900; Fri, 15 Feb 2002 09:26:16 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA27954; Fri, 15 Feb 2002 09:26:15 -0500 (EST) To: "Cornel GLIGAN" Cc: From: Derek Atkins Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode References: Date: 15 Feb 2002 09:26:15 -0500 In-Reply-To: Message-ID: Lines: 80 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: "Cornel GLIGAN" writes: > Hi! > > First fo all, I want to thank you for you answer me. > > Here are my problems: > > >OpenPGP does symmetric encryption using a variant of Cipher Feedback > >Mode (CFB mode). This section describes the procedure it uses in > >detail. This mode is what is used for Symmetrically Encrypted Data > >Packets; the mechanism used for encrypting secret key material is > >similar, but described in those sections above. > > In the "secret key material" section I found this: > >Encryption/decryption of the secret data is done in CFB mode using > >the key created from the passphrase and the Initial Vector from the > >packet. > > (and now, back to the CFB mode) > >OpenPGP CFB mode uses an initialization vector (IV) of all zeros, > >and prefixes the plaintext with BS+2 octets of random data, such > >that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB > >"resync" after encrypting those BS+2 octets. > > I want to mention that I want to keep a secret key in format OpenPGP not > a plain text. > 1) What value should I fill in IV? > 2) Are those BS+2 octets just for plain text or even for secret key > material? The OpenPGP CFB module uses an "Encrypted Initialization". The way this works is: 1) start with an IV of all zeros (in the CFB Context) 2) Create a buffer of "BS+2" bytes 3) Fill in the first BS bytes with random bytes 4) copy the last two bytes of BS into the extra two bytes at the end 5) CFB Encrypt the "BS+2" bytes <-- This is the encrypted IV 6) Re-Sync the CFB context. 7) Start ecnrypting your data. This is done EVERY TIME you initialize a CFB context. These extra BS+2 bytes are prefixed before every CFB encryption. > >3. FRE is xored with the first BS octets of random data prefixed to > >the plaintext to produce C[1] through C[BS], the first BS octets > >of ciphertext. > > 3) Do the C[i] octets represent the final form for OpenPGP format? Yes. Although C[0]..C[BS+2] are the encrypted IV bytes, not your data bytes. > >12. FRE is xored with the next BS octets of plaintext, to produce > >the next BS octets of ciphertext. These are loaded into FR and > >the process is repeated until the plaintext is used up. > > 4) Let's assume that I encrypt the algorithm-specific portion with IDEA. > What it happens with the last block of data if the length of the > algorithm-specific portion is not multiple of 8 (64 bit)? (and, of > course, the last block it will be less than BS - in this case 8 octets) You clearly don't understand how CFB mode works. You don't encrypt your input in block-sized chunks; you rotate your feedback register in block-sized chunks. The ciphertext is just an xor of the feedback register with the plaintext, and you rotate the feedback register by encrypting your output. So if the last block of plaintext is only 1 byte, you only use one byte from the last feedback and toss the rest of your feedback on the floor. > Thank you in advance, > > Cornel Gligan-Ignatescu -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: by above.proper.com (8.11.6/8.11.3) id g1F6lqL11506 for ietf-openpgp-bks; Thu, 14 Feb 2002 22:47:52 -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 g1F6lo311502 for ; Thu, 14 Feb 2002 22:47:51 -0800 (PST) Subject: RE: Need some explanations about privarte key in OpenPGP format, CFB mode Date: Fri, 15 Feb 2002 08:47:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need some explanations about privarte key in OpenPGP format, CFB mode Thread-Index: AcG1a5TOmj5/Hv5PTjSvDTXVS56KFgAe8Rdw From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1F6lq311503 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! First fo all, I want to thank you for you answer me. Here are my problems: >OpenPGP does symmetric encryption using a variant of Cipher Feedback >Mode (CFB mode). This section describes the procedure it uses in >detail. This mode is what is used for Symmetrically Encrypted Data >Packets; the mechanism used for encrypting secret key material is >similar, but described in those sections above. In the "secret key material" section I found this: >Encryption/decryption of the secret data is done in CFB mode using >the key created from the passphrase and the Initial Vector from the >packet. (and now, back to the CFB mode) >OpenPGP CFB mode uses an initialization vector (IV) of all zeros, >and prefixes the plaintext with BS+2 octets of random data, such >that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB >"resync" after encrypting those BS+2 octets. I want to mention that I want to keep a secret key in format OpenPGP not a plain text. 1) What value should I fill in IV? 2) Are those BS+2 octets just for plain text or even for secret key material? >3. FRE is xored with the first BS octets of random data prefixed to >the plaintext to produce C[1] through C[BS], the first BS octets >of ciphertext. 3) Do the C[i] octets represent the final form for OpenPGP format? >12. FRE is xored with the next BS octets of plaintext, to produce >the next BS octets of ciphertext. These are loaded into FR and >the process is repeated until the plaintext is used up. 4) Let's assume that I encrypt the algorithm-specific portion with IDEA. What it happens with the last block of data if the length of the algorithm-specific portion is not multiple of 8 (64 bit)? (and, of course, the last block it will be less than BS - in this case 8 octets) Thank you in advance, Cornel Gligan-Ignatescu Received: by above.proper.com (8.11.6/8.11.3) id g1EKbL122250 for ietf-openpgp-bks; Thu, 14 Feb 2002 12:37:21 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1EKbJ322241 for ; Thu, 14 Feb 2002 12:37:19 -0800 (PST) Received: (cpmta 28573 invoked from network); 14 Feb 2002 12:37:15 -0800 Received: from 217.225.22.235 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 14 Feb 2002 12:37:15 -0800 X-Sent: 14 Feb 2002 20:37:15 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE To: Kyser Soze , OpenPGP Subject: Re: rfc2015bis Date: Thu, 14 Feb 2002 21:34:56 +0100 X-Mailer: KMail [version 1.3.9] References: In-Reply-To: X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Message-Id: <200202142135.00392@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1EKbK322242 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 14 February 2002 18:44, Kyser Soze wrote: > Hi, > I searched the net, there are references to rfc2015bis, but I > can't seem to download it from anywhere. Where can it get it from? It's already an rfc (3152 or 3156 - I always keep forgetting). Marc - -- Marc Mutz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8bB9w3oWD+L2/6DgRArNlAKDFeT5THpUw1EVeE+Wcy7MqUHcbOgCdHACS Q0sj+5N7wlzXx0seEVItZj8= =zwRD -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1EJKWL16513 for ietf-openpgp-bks; Thu, 14 Feb 2002 11:20:32 -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 g1EJKU316507 for ; Thu, 14 Feb 2002 11:20:30 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16bRxM-00017d-00; Thu, 14 Feb 2002 20:54:12 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16bRNZ-0003Ke-00; Thu, 14 Feb 2002 20:17:13 +0100 To: OpenPGP CC: Kyser Soze Subject: Re: rfc2015bis References: From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Thu, 14 Feb 2002 20:17:13 +0100 In-Reply-To: (Kyser Soze's message of "Thu, 14 Feb 2002 11:44:03 -0600") Message-ID: <87g043ub46.fsf@alberti.gnupg.de> Lines: 19 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=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 14 Feb 2002 11:44:03 -0600, Kyser Soze said: > I searched the net, there are references to rfc2015bis, but I can't seem > to download it from anywhere. Where can it get it from? This has been published ad rfc3156. BTW, we need to release another draft: draft-ietf-openpgp-rfc2440bis-03.txt Expires Feb 2002 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 g1EHi7T11346 for ietf-openpgp-bks; Thu, 14 Feb 2002 09:44:07 -0800 (PST) Received: from smtpout.mac.com ([204.179.120.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1EHi6311342 for ; Thu, 14 Feb 2002 09:44:06 -0800 (PST) Received: from smtp-relay02.mac.com (server-source-si02 [10.13.10.6]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g1EHi7oU011119 for ; Thu, 14 Feb 2002 09:44:07 -0800 (PST) Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay02.mac.com (Netscape Messaging Server 4.15 relay02 Jun 21 2001 23:53:48) with ESMTP id GRJALI00.PEK for ; Thu, 14 Feb 2002 09:44:06 -0800 Received: from [192.68.187.6] ([208.180.64.78]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 21 2001 23:53:48) with ESMTP id GRJALI00.R30 for ; Thu, 14 Feb 2002 09:44:06 -0800 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Thu, 14 Feb 2002 11:44:03 -0600 Subject: rfc2015bis From: Kyser Soze To: OpenPGP Message-ID: 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: Hi, I searched the net, there are references to rfc2015bis, but I can't seem to download it from anywhere. Where can it get it from? Thanks K. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EFNLt05998 for ietf-openpgp-bks; Thu, 14 Feb 2002 07:23:21 -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 g1EFNK305993 for ; Thu, 14 Feb 2002 07:23:20 -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 KAA18959; Thu, 14 Feb 2002 10:23:19 -0500 (EST) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA12357; Thu, 14 Feb 2002 10:23:16 -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 KAA09481; Thu, 14 Feb 2002 10:23:12 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA06737; Thu, 14 Feb 2002 10:23:11 -0500 (EST) To: "Cornel GLIGAN" Cc: Reply-To: From: Derek Atkins Subject: Re: Need some explanations about privarte key in OpenPGP format, CFB mode References: Date: 14 Feb 2002 10:23:11 -0500 In-Reply-To: Message-ID: Lines: 95 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: What, in particular, are you confused about? (comment inline) "Cornel GLIGAN" writes: > Hi! > > I tried to store a private key in OpenPGP format, using the CFB mode as > described in http://www.imc.org/draft-ietf-openpgp-rfc2440bis : > > 12.8. OpenPGP CFB mode > > OpenPGP does symmetric encryption using a variant of Cipher Feedback > Mode (CFB mode). This section describes the procedure it uses in > detail. This mode is what is used for Symmetrically Encrypted Data > Packets; the mechanism used for encrypting secret key material is > similar, but described in those sections above. > > In the description below, the value BS is the block size in octets > of the cipher. Most ciphers have a block size of 8 octets. The AES > and Twofish have a blocksize of 16 octets. Also note that the > description below assumes that the IV and CFB arrays start with an > index of 1 (unlike the C language, which assumes arrays start with a > zero index). > > OpenPGP CFB mode uses an initialization vector (IV) of all zeros, > and prefixes the plaintext with BS+2 octets of random data, such > that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB > "resync" after encrypting those BS+2 octets. > > Thus, for an algorithm that has a block size of 8 octets (64 bits), > the IV is 10 octets long and octets 7 and 8 of the IV are the same > as octets 9 and 10. For an algorithm with a blocksize of 16 octets > (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate > octets 15 and 16. Those extra two octets are an easy check for a > correct key. > > Step by step, here is the procedure: > > 1. The feedback register (FR) is set to the IV, which is all zeros. What this really says is "The CFB feedback register, which acts at the Initialization Vector as per the CFB FIPS, is initialized to all zeros. > 2. FR is encrypted to produce FRE (FR Encrypted). This is the > encryption of an all-zero value. > > 3. FRE is xored with the first BS octets of random data prefixed to > the plaintext to produce C[1] through C[BS], the first BS octets > of ciphertext. > > 4. FR is loaded with C[1] through C[BS]. > > 5. FR is encrypted to produce FRE, the encryption of the first BS > octets of ciphertext. > > 6. The left two octets of FRE get xored with the next two octets of > data that were prefixed to the plaintext. This produces C[BS+1] > and C[BS+2], the next two octets of ciphertext. > > 7. (The resync step) FR is loaded with C[3] through C[BS+2]. > > 8. FR is encrypted to produce FRE. > > 9. FRE is xored with the first BS octets of the given plaintext, > now that we have finished encrypting the BS+2 octets of prefixed > data. This produces C[BS+3] through C[BS+(BS+2)], the next BS > octets of ciphertext. > > 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 > for an 8-octet block). > > 11. FR is encrypted to produce FRE. > > 12. FRE is xored with the next BS octets of plaintext, to produce > the next BS octets of ciphertext. These are loaded into FR and > the process is repeated until the plaintext is used up. > > Is anybody who can explain to me in details how CFB works because I am > very confused. I didn't understand anything after I read this text? Well, it's explained pretty thoroughly above. The step-by-step instructions pretty much tell you what you need to know. What exactly are you confused about? > Thank you in advance, > > Cornel Gligan-Ignatescu -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1EF3XA04610 for ietf-openpgp-bks; Thu, 14 Feb 2002 07:03:33 -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 g1EF3V304606 for ; Thu, 14 Feb 2002 07:03:31 -0800 (PST) Subject: Need some explanations about privarte key in OpenPGP format, CFB mode Date: Thu, 14 Feb 2002 17:03:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need some explanations about privarte key in OpenPGP format Thread-Index: AcG0bRt+tIORbBYdS7ulqicxphY8EAA+iUoA From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1EF3W304607 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! I tried to store a private key in OpenPGP format, using the CFB mode as described in http://www.imc.org/draft-ietf-openpgp-rfc2440bis : 12.8. OpenPGP CFB mode OpenPGP does symmetric encryption using a variant of Cipher Feedback Mode (CFB mode). This section describes the procedure it uses in detail. This mode is what is used for Symmetrically Encrypted Data Packets; the mechanism used for encrypting secret key material is similar, but described in those sections above. In the description below, the value BS is the block size in octets of the cipher. Most ciphers have a block size of 8 octets. The AES and Twofish have a blocksize of 16 octets. Also note that the description below assumes that the IV and CFB arrays start with an index of 1 (unlike the C language, which assumes arrays start with a zero index). OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with BS+2 octets of random data, such that octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB "resync" after encrypting those BS+2 octets. Thus, for an algorithm that has a block size of 8 octets (64 bits), the IV is 10 octets long and octets 7 and 8 of the IV are the same as octets 9 and 10. For an algorithm with a blocksize of 16 octets (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate octets 15 and 16. Those extra two octets are an easy check for a correct key. Step by step, here is the procedure: 1. The feedback register (FR) is set to the IV, which is all zeros. 2. FR is encrypted to produce FRE (FR Encrypted). This is the encryption of an all-zero value. 3. FRE is xored with the first BS octets of random data prefixed to the plaintext to produce C[1] through C[BS], the first BS octets of ciphertext. 4. FR is loaded with C[1] through C[BS]. 5. FR is encrypted to produce FRE, the encryption of the first BS octets of ciphertext. 6. The left two octets of FRE get xored with the next two octets of data that were prefixed to the plaintext. This produces C[BS+1] and C[BS+2], the next two octets of ciphertext. 7. (The resync step) FR is loaded with C[3] through C[BS+2]. 8. FR is encrypted to produce FRE. 9. FRE is xored with the first BS octets of the given plaintext, now that we have finished encrypting the BS+2 octets of prefixed data. This produces C[BS+3] through C[BS+(BS+2)], the next BS octets of ciphertext. 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block). 11. FR is encrypted to produce FRE. 12. FRE is xored with the next BS octets of plaintext, to produce the next BS octets of ciphertext. These are loaded into FR and the process is repeated until the plaintext is used up. Is anybody who can explain to me in details how CFB works because I am very confused. I didn't understand anything after I read this text? Thank you in advance, Cornel Gligan-Ignatescu Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1E9Od211384 for ietf-openpgp-bks; Thu, 14 Feb 2002 01:24:39 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1E9Ob311374 for ; Thu, 14 Feb 2002 01:24:37 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id g1E9Oap11511; Thu, 14 Feb 2002 09:24:36 GMT Message-ID: Date: Thu, 14 Feb 2002 09:23:22 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: OpenPGP vs. OpenPGP/MIME References: <3C6A1945.9D6B25EB@saiknes.lv> <20020213095005.GA6830@sobolev.does-not-exist.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed;boundary="=_Turnpike_KjRzeFB6H4a84L4A="; protocol="application/pgp-signature";micalg=pgp-sha1 User-Agent: Turnpike/6.01-Alpha-6-M () Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a PGP signed message sent according to RFC3156 [PGP/MIME] --=_Turnpike_KjRzeFB6H4a84L4A= Content-Type: text/plain;charset=us-ascii;format=flowed Content-Transfer-Encoding: quoted-printable On Wed, 13 Feb 2002, Jon Callas wrote: > >At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: > >>>does not work with many mailing lists (that are configured to >>>remove attachments), >> >>Such mailing lists are broken. [] >I must respectfully disagree with this assessment. People who maintain >computer systems used by a number of people have a responsibility to >protect that shared resource. Stopping attachments on mailing lists is not >any more "broken" than putting up a firewall is. Yes, but there is no reason why mailing-list software should regard=20 application/pgp-signature as an "attachment" when protecting=20 mailing-lists against misplaced or dangerous attachments. (This sent PGP/MIME signed, just to see what happens on this list!) --=20 Ian Bell T U R N P I K E --=_Turnpike_KjRzeFB6H4a84L4A= Content-Type: application/pgp-signature Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: PGPsdk 2.1a246 iQA/AwUAPGuCCL3aNYn/fmK7EQJqQgCeO39or+XFgS7IpxEjHCWQXqZQVYQAnjTc 5L/pjQ/TLzgMXJU1sek1Z5Eh =ITJC -----END PGP SIGNATURE----- --=_Turnpike_KjRzeFB6H4a84L4A=-- Received: by above.proper.com (8.11.6/8.11.3) id g1E9C8M10202 for ietf-openpgp-bks; Thu, 14 Feb 2002 01:12:08 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1E9C6310195 for ; Thu, 14 Feb 2002 01:12:06 -0800 (PST) Received: (cpmta 7664 invoked from network); 14 Feb 2002 01:12:01 -0800 Received: from 129.70.24.67 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 14 Feb 2002 01:12:01 -0800 X-Sent: 14 Feb 2002 09:12:01 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE To: Jon Callas , ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Date: Wed, 13 Feb 2002 23:09:53 +0100 X-Mailer: KMail [version 1.3.9] References: <3C6A1945.9D6B25EB@saiknes.lv> <20020213095005.GA6830@sobolev.does-not-exist.org> In-Reply-To: X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Message-Id: <200202132309.55041@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1E9C6310196 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 13 February 2002 20:09, Jon Callas wrote: > At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: > >>does not work with many mailing lists (that are configured to > >>remove attachments), > > > >Such mailing lists are broken. > I must respectfully disagree with this assessment. People who > maintain computer systems used by a number of people have a > responsibility to protect that shared resource. Stopping attachments > on mailing lists is not any more "broken" than putting up a firewall > is. A mailing list software isn't broken because it filters out attachments, but because it can't distinguish pgp/mime signed plain text messages from attachments. Not everything consisting of a mulitpart contains an attachment. In fact, it would be totally legal for me to always send multipart messages, where, for instance, the first nested body part contains the text of the mail and the secons one my signature. I can't speak for Thomas, but that's probably what he meant: That mailing list software needs to be able to distinguish between attachments and signed messages. (Though I can understand why Thomas could find ml's which filter all "attachments" broken: You can't even forward a message to them (needs a multipart/mixed with nested message/rfc822 - eek)). Marc - -- Marc Mutz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8auQx3oWD+L2/6DgRAlJPAKCrS7BzalfRAck+5T2X+RipCbz7vgCePn2e Vq6YiYsBw36Qd/aF0cXA54U= =cA/N -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DJJfl28657 for ietf-openpgp-bks; Wed, 13 Feb 2002 11:19:41 -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 g1DJJe328653 for ; Wed, 13 Feb 2002 11:19:40 -0800 (PST) Received: from [192.168.1.19] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.3) for ; Wed, 13 Feb 2002 11:19:39 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20020213095005.GA6830@sobolev.does-not-exist.org> References: <3C6A1945.9D6B25EB@saiknes.lv> <20020213095005.GA6830@sobolev.does-not-exist.org> Date: Wed, 13 Feb 2002 11:09:45 -0800 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: 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: At 10:50 AM +0100 2/13/02, Thomas Roessler wrote: >>does not work with many mailing lists (that are configured to >>remove attachments), > >Such mailing lists are broken. As someone who runs a number of such "broken" mailing lists, I "broke" them because I consider the security risk of my list being use to spread the latest Outlook thingie to be much higher than the damage caused by breaking them. It also prevents the inevitable newbie who sends a picture or movie as an attachment, causing a dozen people to go over their mail quotas. My message to my users is that if it's important, put it somewhere and provide a URL. If it's important, I'll even provide disk space for it. I must respectfully disagree with this assessment. People who maintain computer systems used by a number of people have a responsibility to protect that shared resource. Stopping attachments on mailing lists is not any more "broken" than putting up a firewall is. Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DBbCk08446 for ietf-openpgp-bks; Wed, 13 Feb 2002 03:37:12 -0800 (PST) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1DBbA308442 for ; Wed, 13 Feb 2002 03:37:10 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id g1DBbAp13147; Wed, 13 Feb 2002 11:37:10 GMT Message-ID: <15pcYfZa+ka8IA0i@pillar.turnpike.com> Date: Wed, 13 Feb 2002 11:35:54 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: OpenPGP vs. OpenPGP/MIME References: <3C6A1945.9D6B25EB@saiknes.lv> In-Reply-To: <3C6A1945.9D6B25EB@saiknes.lv> MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit User-Agent: Turnpike/6.01-Alpha-6-M () Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 13 Feb 2002, disastry@saiknes.lv wrote: >PGP/MIME is evil. It is the only sensible way to properly secure an entire MIME message with PGP. In the case of signed messages, it allows the recipient to be sure that the sender signed _all_ of the message, including attachments: it allows arbitrarily complex messages to be signed successfully: in principle it allows the sender to send a signed message to a group of people, some of whom are not interested in PGP at all since the act of signing does not pollute the actual message in any way. Of course the last point depends on basic MIME compliance of users' MUAs, and there are some common clients that treat multipart/unknown differently to multipart/mixed :-(( In the case of encrypted messages, it allows the sender to be sure that no-one intercepting the message can know if any attachments are present and what types of attachments there are. It allows encryption of arbitrarily complex messages. >can not save message to disk and decrypt the decryption is easy; but you will be left with a MIME message which will need to be interpreted (by munpack etc) which is a barrier. Best thing is to encourage PGP/MIME support in MUAs. >and/or verify later outside MUA, verify is easy if the message source is available. >some virus checking software removes attachments, some virus checking software removes/quarantines _all_ PGP encrypted material. >does not work with many mailing lists (that are configured to remove >attachments), Best thing is to encourage PGP/MIME support in mailing-lists. [[ Actually, best thing is to encourage MIME support in mailing lists (some lists append text material to the end of messages - which in the case of multipart/* messages gets hidden by MIME MUAs!) ]] >does not work with newsgroups. have a look at alt.security.pgp and see how much PGP clear-signed material is quoted/requoted etc Many messages consist mainly of redundant fragments of quoted ascii-armor. This seems to me to be a serious barrier to the routine use of PGP in newsgroups/mailing-lists. How about the opposite contention: "Clear-signed messages are evil" The ascii-armor is intrusive, so that the use of PGP is restricted to arenas where people will put up with such material "in their faces". The ascii-armor breaks the UseNet signature convention ("-- " becomes "- -- "): another barrier to routine use of PGP in UseNet. Clear signing is often done "behind the MUAs back" - leading to wrapping problems (how many users have to be told how to balance the wrapping action of their MUAs against the wrapping action of their PGP settings?) Clear-signing starts breaking when messages are not simple us-ascii and can't be used to properly secure messages with attachments. [As an example of the first case, I will clear sign this message via the clipboard. The signature will fail. because the '€' character will be signed by PGP as a Windows-1252 character (which is what the clipboard will contain), but my MUA will send it utf-8.] In practice, clear-signing can be made to interoperate for simple us- ascii messages, and PGP/MIME support is indeed patchy, but I hope PGP/MIME support does grow because of its inherent advantages. And if it doesn't, the "world's most popular clients" can still sign and encrypt arbitrary MIME messages securely - they include seamless S/MIME support. - -- Ian Bell T U R N P I K E -----BEGIN PGP SIGNATURE----- Version: PGP 7.1 iQA/AwUBPGpO573aNYn/fmK7EQL3YACfTxQv/5/eL2F+i33MIvIQMkNwONAAn26A QNdP0tJK59utXegMPXCjcwT7 =bSLW -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1DA4XA00371 for ietf-openpgp-bks; Wed, 13 Feb 2002 02:04:33 -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 g1DA4V300366 for ; Wed, 13 Feb 2002 02:04:31 -0800 (PST) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 16awnM-0001eg-00; Wed, 13 Feb 2002 11:37:48 +0100 Received: from wk by alberti.gnupg.de with local (Exim 3.33 #1 (Debian)) id 16awEe-0008FM-00; Wed, 13 Feb 2002 11:01:56 +0100 To: "Cornel GLIGAN" Cc: Subject: Re: Need some explanations about privarte key in OpenPGP format References: From: Werner Koch Organisation: g10 Code GmbH X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com Date: Wed, 13 Feb 2002 11:01:55 +0100 In-Reply-To: ("Cornel GLIGAN"'s message of "Wed, 13 Feb 2002 11:01:43 +0200") Message-ID: <87vgd1wvho.fsf@alberti.gnupg.de> Lines: 58 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=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 13 Feb 2002 11:01:43 +0200, Cornel GLIGAN said: > I have some questions about the last three paragraphs: > - Is the Initial Vector encrypted with the algorithm-specific > portion? The IV is a parameter to the CFB (Cipher Feed Back) encryption mode. > - Let's assume that I encrypt the algorithm-specific portion with > IDEA. What it happens if the length of the algorithm-specific portion is > not multiple of 8 (64 bit)? How can I fill the last block of the > algorithm-specific portion to be an 8 byte (64 bit) block? Padding is not required with CFB. Don't hardwire the 64 bits; you have to use the blocksize of the used cipher (e.g. 128 for AES). You find more information about encryption modes in the standard literature: @Book{Men:96:HAC, author = "Alfred J. Menezes and Paul van Oorschot and Scott Vanstone", title = "Handbook of Applied Cryptography", language = "USenglish", publisher = pub-CRC, address = pub-CRC:adr, pages = "xxvii + 780", year = "1996", ISBN = "0-8493-8523-7", keywords = "cryptograpy", } There is an online resource for it, IIRC: http://cacr.math.uwaterloo.ca/hac/ or @Book{Sch:96:AC, author = "Bruce Schneier", title = "Applied Cryptography", language = "USenglish", edition = "second", publisher = pub-WIL, address = pub-WIL:adr, pages = "xxiii + 758", year = "1996", ISBN = "0-471-11709-9", } Hth, 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 g1D9rdZ28326 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:53:39 -0800 (PST) Received: from c000.snv.cp.net (c000-h000.c000.snv.cp.net [209.228.32.64]) by above.proper.com (8.11.6/8.11.3) with SMTP id g1D9rc328322 for ; Wed, 13 Feb 2002 01:53:38 -0800 (PST) Received: (cpmta 11128 invoked from network); 13 Feb 2002 01:53:32 -0800 Received: from 217.82.92.236 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.64) with SMTP; 13 Feb 2002 01:53:32 -0800 X-Sent: 13 Feb 2002 09:53:32 GMT Content-Type: text/plain; charset="us-ascii" From: Marc Mutz Organization: KDE To: disastry@saiknes.lv, ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Date: Wed, 13 Feb 2002 10:53:17 +0100 X-Mailer: KMail [version 1.3.9] References: <3C6A1945.9D6B25EB@saiknes.lv> In-Reply-To: <3C6A1945.9D6B25EB@saiknes.lv> X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Message-Id: <200202131053.18910@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D9rc328323 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 13 February 2002 08:44, disastry@saiknes.lv wrote: > PGP/MIME is evil. I disagree. pgp/miem isn't evil at all. It's the broken mail software out there that is the problem. And I restate that deprecating pgp/mime (or whatever this should lead to) will take the strain off of those "vendors" to fix their "products"... > can not save message to disk and decrypt and/or verify later outside > MUA, For "decrypt", this is usually wrong, since exactly one part contains the encrypted data, the other only contains metadata, which is either superfluous or could be translated into options for the OpenPGP backend when decrypting... So the real problem is signing: The MUA could offer to convert the multipart/signed part to a file/detached sig pair of files on save. Remember: You can't also view asian text/plain, wihc is usually encoded in base64, without the help of the MUA. > some virus checking software removes attachments, which is broken behaviour... > does not work with many mailing lists (that are configured to remove > attachments), those ml's are broken (since multipart/signed is _not_ an attachment). > does not work with web archives of mailing lists (for > example http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html), broken software used there, too. > does not work with newsgroups. Care to explain what's the problem there? So why are all those packages broken? Because pgp/mime is so rare that they don't need to fix their stuff. Marc - -- Marc Mutz -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ajeN3oWD+L2/6DgRArrOAKCcP+SvN6sXtJDTFn8iVrLK3EUnegCePj2p AhtyoZ0724pmBvNxC+2BpjU= =o0f3 -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1D9rBb28312 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:53:11 -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 g1D9r9328307 for ; Wed, 13 Feb 2002 01:53:09 -0800 (PST) Received: from sobolev.does-not-exist.org (unknown [194.162.148.86]) by mail.mediacompany.com (Postfix) with ESMTP id 240CE4802; Wed, 13 Feb 2002 10:53:08 +0100 (CET) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id DAF112ED15; Wed, 13 Feb 2002 10:50:05 +0100 (CET) Date: Wed, 13 Feb 2002 10:50:05 +0100 From: Thomas Roessler To: disastry@saiknes.lv Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP vs. OpenPGP/MIME Message-ID: <20020213095005.GA6830@sobolev.does-not-exist.org> Mail-Followup-To: disastry@saiknes.lv, ietf-openpgp@imc.org References: <3C6A1945.9D6B25EB@saiknes.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3C6A1945.9D6B25EB@saiknes.lv> User-Agent: Mutt/1.5.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-02-13 09:44:05 +0200, disastry@saiknes.lv wrote: >can not save message to disk and decrypt and/or verify later >outside MUA, Where do you get the expectation from that you can handle e-mail messages without software able to parse their format? (And, BTW, you can certainly do all you desire outside the MUA. You just have to do some _very_ basic MIME parsing yourself. >some virus checking software removes attachments, Such virus checking software is broken. >does not work with many mailing lists (that are configured to >remove attachments), Such mailing lists are broken. >does not work with web archives of mailing lists (for example >http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html), That's not an example for PGP/MIME, but an example for mailing list archiving software not being able to cope with RFC announcements as sent out by the RFC editor. This is another instance of broken software. Nice try, though. >does not work with newsgroups. Why not? -- Thomas Roessler Received: by above.proper.com (8.11.6/8.11.3) id g1D9m1A28177 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:48:01 -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 g1D9lx328173 for ; Wed, 13 Feb 2002 01:47:59 -0800 (PST) Received: from sobolev.does-not-exist.org (unknown [62.144.244.99]) by mail.mediacompany.com (Postfix) with ESMTP id 4A6BB4802; Wed, 13 Feb 2002 10:47:46 +0100 (CET) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 3CC552ED19; Wed, 13 Feb 2002 10:45:11 +0100 (CET) Date: Wed, 13 Feb 2002 10:45:11 +0100 From: Thomas Roessler To: ietf-openpgp@imc.org, Will Price Subject: Re: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh Message-ID: <20020213094511.GZ6830@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org, Will Price References: <20020124224603.GA3429@sobolev.does-not-exist.org> <3.0.5.32.20020212210415.01c95008@localhost> <3C69F8A6.86DB7647@cyphers.net> <20020124224603.GA3429@sobolev.does-not-exist.org> <3.0.5.32.20020212210415.01c95008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <3C69F8A6.86DB7647@cyphers.net> <3.0.5.32.20020212210415.01c95008@localhost> User-Agent: Mutt/1.5.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2002-02-12 21:04:15 -0800, Carl Ellison wrote: >One would think that a good standard wouldn't allow any such >variability. One would also think that a good implementation won't crash when encountering standard compliant messages (it shouldn't even crash when receiving junk). On 2002-02-12 21:24:54 -0800, Will Price wrote: >In recent versions, we accomodated the Mutt way of encoding >PGP/MIME. I don't recall exactly which version that went into. The >current Eudora plugin version is 7.1.1 which is of course part of >PGP 7.1.1. May I ask what particular detail of mutt's way of encoding had to be specifically accomodated? I'm asking because _if_ mutt is violating the standard, this would be something I'd really like to see fixed. (Yes, I am aware that earlier versions of mutt have possibly generated wrong micalg parameters, unless users paid attention. This particular problem has, however, been fixed quite thoroughly.) Writing with the "current mutt maintainer" hat, -- Thomas Roessler Received: by above.proper.com (8.11.6/8.11.3) id g1D91lj21153 for ietf-openpgp-bks; Wed, 13 Feb 2002 01:01:47 -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 g1D91j321139 for ; Wed, 13 Feb 2002 01:01:45 -0800 (PST) Subject: Need some explanations about privarte key in OpenPGP format Date: Wed, 13 Feb 2002 11:01:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MS-Has-Attach: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 X-MS-TNEF-Correlator: Thread-Topic: Need some explanations about privarte key in OpenPGP format Thread-Index: AcG0bRt+tIORbBYdS7ulqicxphY8EA== From: "Cornel GLIGAN" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D91k321147 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! I read and re-read the rfc 2440 and I am confused about few things. (from http://www.imc.org/draft-ietf-openpgp-rfc2440bis) ... 5.5.3. Secret Key Packet Formats The Secret Key and Secret Subkey packets contain all the data of the Public Key and Public Subkey packets, with additional algorithm-specific secret key data appended, in encrypted form. The packet contains: - A Public Key or Public Subkey packet, as described above - One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 indicates that a string-to-key specifier is being given. Any other value is a symmetric-key encryption algorithm specifier. - [Optional] If string-to-key usage octet was 255, a one-octet symmetric encryption algorithm. - [Optional] If string-to-key usage octet was 255, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above. So far so good. - [Optional] If secret data is encrypted, Initial Vector (IV) of the same length as the cipher's block size. - Encrypted multi-precision integers comprising the secret key data. These algorithm-specific fields are as described below. - Two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536). This checksum is encrypted together with the algorithm- specific fields. I have some questions about the last three paragraphs: - Is the Initial Vector encrypted with the algorithm-specific portion? - In case that the Initial Vector is encrypted with the algorithm-specific portion, does the plain text of the the algorithm-specific portion, on that the checksum is made, include the Initial vector or not? - Let's assume that I encrypt the algorithm-specific portion with IDEA. What it happens if the length of the algorithm-specific portion is not multiple of 8 (64 bit)? How can I fill the last block of the algorithm-specific portion to be an 8 byte (64 bit) block? Is anybody who can answer to my questions? Thank you in advance, Cornel Gligan-Ignatescu Received: by above.proper.com (8.11.6/8.11.3) id g1D7nbk08730 for ietf-openpgp-bks; Tue, 12 Feb 2002 23:49:37 -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 g1D7nY308726 for ; Tue, 12 Feb 2002 23:49:35 -0800 (PST) Received: from saiknes.lv (unverified [127.0.0.1]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Wed, 13 Feb 2002 09:44:05 0200 Message-ID: <3C6A1945.9D6B25EB@saiknes.lv> Date: Wed, 13 Feb 2002 09:44:05 +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: OpenPGP vs. OpenPGP/MIME 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 PGP/MIME is evil. can not save message to disk and decrypt and/or verify later outside MUA, some virus checking software removes attachments, does not work with many mailing lists (that are configured to remove attachments), does not work with web archives of mailing lists (for example http://www.imc.org/ietf-openpgp/mail-archive/msg03690.html), does not work with newsgroups. __ 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/AwUBPGn8yjBaTVEuJQxkEQMUzQCeLUZwDzQvKzAQSs2W/Pjjn2jJKl4AoIh8 5CpDyEHwN/ceJqcN9ZdvtHs5 =eFfP -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1D5OrM25785 for ietf-openpgp-bks; Tue, 12 Feb 2002 21:24:53 -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 g1D5Oq325780 for ; Tue, 12 Feb 2002 21:24:52 -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 GRGKH400.55M; Tue, 12 Feb 2002 22:24:40 -0800 Message-ID: <3C69F8A6.86DB7647@cyphers.net> Date: Tue, 12 Feb 2002 21:24:54 -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: Carl Ellison CC: ietf-openpgp@imc.org Subject: Re: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh References: <20020124224603.GA3429@sobolev.does-not-exist.org> <3.0.5.32.20020212210415.01c95008@localhost> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D5Oq325781 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes, it is because you're using an old version of PGP (6.5.8) which was released in June of 1999 (in other words, many years ago). In recent versions, we accomodated the Mutt way of encoding PGP/MIME. I don't recall exactly which version that went into. The current Eudora plugin version is 7.1.1 which is of course part of PGP 7.1.1. Carl Ellison wrote: > Does anyone know why PGP/MIME messages from Mutt consistently crash > Eudora while those from Evolution or exmh don’t? > > One would think that a good standard wouldn’t allow any such > variability. - -- Will Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. -----BEGIN PGP SIGNATURE----- Version: PGP 7.5 (Build 151) Beta iQA/AwUBPGn4nKy7FkvPc+xMEQIzlgCdE7nJM3KVDq58+nvLwBTqWNnzCxgAn3/P 3n/9TJ+KF79Q9yiTqgXy3jpw =I69h -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1D545r25337 for ietf-openpgp-bks; Tue, 12 Feb 2002 21:04:05 -0800 (PST) Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1D544325333 for ; Tue, 12 Feb 2002 21:04:04 -0800 (PST) Received: from p4 ([12.224.51.110]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020213050404.KMZT1214.rwcrmhc54.attbi.com@p4>; Wed, 13 Feb 2002 05:04:04 +0000 Message-Id: <3.0.5.32.20020212210415.01c95008@localhost> X-Sender: cme@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 12 Feb 2002 21:04:15 -0800 To: Jon Callas , ietf-openpgp@imc.org From: Carl Ellison Subject: (Open)PGP/MIME - Mutt vs. Evolution vs. exmh In-Reply-To: <200202120829.01245@sendmail.mutz.com> References: <20020124224603.GA3429@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g1D544325334 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone know why PGP/MIME messages from Mutt consistently crash Eudora while those from Evolution or exmh don’t? One would think that a good standard wouldn’t allow any such variability. - Carl -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPGnzz3PxfjyW5ytxEQLhJgCgp9w4C3w34EPKarXNkwrSJkQACfQAn0g4 KNIqsxq11W3VB2Wz1kYx/Q/c =ZpBn -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://world.std.com/~cme | | PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 | +--Officer, officer, arrest that man. He's whistling a dirty song.-+ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1C7T9u24251 for ietf-openpgp-bks; Mon, 11 Feb 2002 23:29:09 -0800 (PST) Received: from mail.uni-bielefeld.de (IDENT:72@mail2.uni-bielefeld.de [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C7T4324223 for ; Mon, 11 Feb 2002 23:29:04 -0800 (PST) Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GRE00GL7SSD15@mail.uni-bielefeld.de> for ietf-openpgp@imc.org; Tue, 12 Feb 2002 08:29:02 +0100 (MET) Date: Tue, 12 Feb 2002 08:28:59 +0100 From: Marc Mutz Subject: Re: OpenPGP vs. OpenPGP/MIME In-reply-to: To: Jon Callas , Thomas Roessler , Simon Josefsson Cc: ietf-openpgp@imc.org Message-id: <200202120829.01245@sendmail.mutz.com> Organization: KDE MIME-version: 1.0 X-Mailer: KMail [version 1.3.9] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PGP-Key: 0xBDBFE838 References: <20020124224603.GA3429@sobolev.does-not-exist.org> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 25 January 2002 01:48, Jon Callas wrote: > 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. So we should prolong the lifespan of a broken design (just think i18n) just because the mime interop of some widely deployed mail software is less than optimal? What about encouraging people to implement PGP/MIME and see its wide deployment force others to fix their stuff? Just the opinion of someone implementing of a MIME parser: Plain pgp is ugly as hell, PGP/MIME resp. rfc1847 sucks much less. Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aMQ83oWD+L2/6DgRAt+HAKCeWc2K6gwdgissULdwxB2u+tcjMQCg9Ycz ncJLzXIiRSGx11o5HLL2CkA= =DTck -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g1C7K5E22314 for ietf-openpgp-bks; Mon, 11 Feb 2002 23:20:05 -0800 (PST) Received: from mail.uni-bielefeld.de (IDENT:72@mail2.uni-bielefeld.de [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1C7K3322303 for ; Mon, 11 Feb 2002 23:20:03 -0800 (PST) Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <0GRE00I7QSDC1N@mail.uni-bielefeld.de> for ietf-openpgp@imc.org; Tue, 12 Feb 2002 08:20:01 +0100 (MET) Date: Tue, 12 Feb 2002 08:19:41 +0100 From: Marc Mutz Subject: Re: OpenPGP vs. OpenPGP/MIME In-reply-to: To: john.dlugosz@kodak.com, ietf-openpgp@imc.org Message-id: <200202120819.43542@sendmail.mutz.com> Organization: KDE MIME-version: 1.0 X-Mailer: KMail [version 1.3.9] Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PGP-Key: 0xBDBFE838 References: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 25 January 2002 18:07, john.dlugosz@kodak.com wrote: > 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. I guess labelling this as re: compatibility is stretching the sense at best. If Notes doesn't handle MIME, what's the point in arguing that PGP/MIME is bad for interop and citing Notes as an example. > 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. As long as MIME parsers follow the rule to treat unknown multipart/* as multipart/mixed, no problem would arise. It's the broken mail software that causes problems here. > 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. - From the point of view of a MIME parser implementor, old-fashioned pgp messages are pure horror. While you can trust that with PGP/MIME signed and/or encrypted body parts are correctly labelled, for plain PGP messages you have to scan all possible body parts (ie. at least those labelled text/plain) to check for pgp message blocks. Worse: Your nice DOM that you built around the concepts of rfc(2)822, rfc2015, rfc204x and friends is totally wrecked when you have to deal with body parts embedded in body parts other that multipart/* or message/*. The same issue arises with uuencoded messages. You have to introduce fake body parts when you want to actually keep your DOM. Don't start to think about those broken flat message digests with multiple pgp message blocks in them :-( OTOH, letting aside the cryptographic functions, implementing rfc1847 is dead easy. > 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. See above for why this is a bad idea. Marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8aMIO3oWD+L2/6DgRAjOMAJ9NnKy2i4rCUss+sMtvKkxYjJmvMwCgmroj KjCN6jL6OYiLTms/+6VjL+Q= =dy2i -----END PGP SIGNATURE-----