From owner-ietf-openpgp@mail.imc.org Tue Mar 5 16:00: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 QAA28339 for ; Tue, 5 Mar 2002 16:00:00 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g25KjXV00668 for ietf-openpgp-bks; Tue, 5 Mar 2002 12:45:33 -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 g25KjL800659 for ; Tue, 5 Mar 2002 12:45:31 -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 PAA28386 for ; Tue, 5 Mar 2002 15:34:45 -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 PAA12349 for ; Tue, 5 Mar 2002 15:45:12 -0500 (EST) Message-ID: <008f01c1c486$773c8040$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> <20020228034024.GA678@akamai.com> <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> <20020228234334.GE691@akamai.com> Subject: Re: Revocation key difficulty Date: Tue, 5 Mar 2002 15:43:54 -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 David Shaw noted this PGP (and now GnuPG) behavior: > 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. I would argue that silently ignoring a missing revoker is a bad default. GnuPG is generally very good about issuing warnings (and offering options :-). Would you be willing to do so here (at least when a potential revocation is present)? I know this doesn't thwart would-be attackers. They can always remove the revocation itself. A warning would simply help recognize that the key is effectively incomplete, and that the revoker should be retrieved. (Or, have you adjusted GnuPG to automatically retrieve revokers after retrieving a key from a server?) A signed CRL could provide the means to defeat removal attacks. I thought that I'd seen a draft that had considered some form of CRL, but I can't find it now. Did that ever come up? I understand that this requires a bunch of specification, so I can see why it might have been rejected. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPIUuAlMkvpTT8vCGEQLxDQCg+VudpJtp0Thxi10zmmUeYvWpIvQAnjFd iPLf2F3uF+S3Nopxh6SBq+3/ =JZpX -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Mar 6 13:58:46 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 NAA27666 for ; Wed, 6 Mar 2002 13:58:46 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g26Ijbf18571 for ietf-openpgp-bks; Wed, 6 Mar 2002 10:45:37 -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 g26IjZ818567 for ; Wed, 6 Mar 2002 10:45:36 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g26IjRL04261 for ietf-openpgp@imc.org; Wed, 6 Mar 2002 13:45:27 -0500 Date: Wed, 6 Mar 2002 13:45:27 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020306184527.GB692@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> <20020228234334.GE691@akamai.com> <008f01c1c486$773c8040$dfc32609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008f01c1c486$773c8040$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 Crescent (43% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 05, 2002 at 03:43:54PM -0500, Michael Young wrote: > David Shaw noted this PGP (and now GnuPG) behavior: > > 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. > > I would argue that silently ignoring a missing revoker is a bad default. > GnuPG is generally very good about issuing warnings (and offering > options :-). Would you be willing to do so here (at least when > a potential revocation is present)? Good idea. I think a warning during key import if a key has a potential revocation on it is appropriate. > I know this doesn't thwart would-be attackers. They can always > remove the revocation itself. A warning would simply help > recognize that the key is effectively incomplete, and that the > revoker should be retrieved. (Or, have you adjusted GnuPG to > automatically retrieve revokers after retrieving a key from a server?) It doesn't, but that's a good idea as well (to be optional, of course). David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Thu Mar 21 15:53:06 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 PAA25087 for ; Thu, 21 Mar 2002 15:53:06 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LKa1H02361 for ietf-openpgp-bks; Thu, 21 Mar 2002 12:36:01 -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 g2LKZx402357 for ; Thu, 21 Mar 2002 12:36:00 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g2LKZr303852 for ietf-openpgp@imc.org; Thu, 21 Mar 2002 15:35:53 -0500 Date: Thu, 21 Mar 2002 15:35:53 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Tailing whitespace, armor lines, and clearsigned messages Message-ID: <20020321203553.GA3498@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 Waxing Crescent (47% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would really appreciate a bit of clarification with some of the wording in 2440bis. In section 6.2 ("Forming ASCII Armor"), the text says (and it's a MUST) that there should be nothing after the second set of dashes in the armor header line. That is: "-----BEGIN PGP SIGNED MESSAGE-----" is okay, but "-----BEGIN PGP SIGNED MESSAGE----- " is not okay due to the extra space on the end. In section 7.1 ("Dash-Escaped text"), the text says that a signature on a clearsigned message ignores trailing whitespace. I've read that the intent behind that is to give some measure of robustness to the message so it can get through mail systems that add or remove whitespace at the end of lines. Now here's the part I don't quite get - if it is okay to allow trailing whitespace in the message contents, why is it not okay to allow trailing whitespace after the armor header? If the intent behind ignoring trailing whitespace was to help with mail corruption, the fact that the message data allows trailing whitespace doesn't really help since the armor headers surrounding the message data would also become invalid with any added trailing whitespace. I do understand the armor header is not part of the message, and this is likely just another example of "be conservative in what you generate, liberal in what you accept". If I've misread this somewhere, can someone please help clarify? Thanks! David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies From owner-ietf-openpgp@mail.imc.org Thu Mar 21 17:32:55 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 RAA27863 for ; Thu, 21 Mar 2002 17:32:54 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2LMJIb06934 for ietf-openpgp-bks; Thu, 21 Mar 2002 14:19:18 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LMJH406927 for ; Thu, 21 Mar 2002 14:19:17 -0800 (PST) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g2LNBPg02925; Thu, 21 Mar 2002 15:11:25 -0800 Date: Thu, 21 Mar 2002 15:11:25 -0800 From: "Hal Finney" Message-Id: <200203212311.g2LNBPg02925@finney.org> To: dshaw@akamai.com, ietf-openpgp@imc.org Subject: Re: Tailing whitespace, armor lines, and clearsigned messages Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > Now here's the part I don't quite get - if it is okay to allow > trailing whitespace in the message contents, why is it not okay to > allow trailing whitespace after the armor header? The reason for specifying the treatment of trailing whitespace in the message contents is because that portion is hashed. What the spec means here is that trailing whitespace is not included in the hash. The BEGIN line is not hashed so there is no need to say what to do with trailing whitespace there. Technically an implementation could reject messages with trailing whitespace on the BEGIN line. However this would violate the principle of "be liberal in what you accept and conservative in what you send". The right thing to do, according to this principle, is to create the BEGIN line with no trailing whitespace, and to ignore any trailing whitespace on incoming BEGIN lines. Hal From owner-ietf-openpgp@mail.imc.org Thu Mar 21 17:59:44 2002 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28768 for ; Thu, 21 Mar 2002 17:59:43 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id g2LMmDf07979 for ietf-openpgp-bks; Thu, 21 Mar 2002 14:48:13 -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 g2LMmC407975 for ; Thu, 21 Mar 2002 14:48:12 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g2LMm2k09038; Thu, 21 Mar 2002 17:48:02 -0500 Date: Thu, 21 Mar 2002 17:48:02 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Tailing whitespace, armor lines, and clearsigned messages Message-ID: <20020321224802.GH784@akamai.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <200203212311.g2LNBPg02925@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203212311.g2LNBPg02925@finney.org> 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 Waxing Crescent (46% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 21, 2002 at 03:11:25PM -0800, Hal Finney wrote: > David Shaw writes: > > Now here's the part I don't quite get - if it is okay to allow > > trailing whitespace in the message contents, why is it not okay to > > allow trailing whitespace after the armor header? > > The reason for specifying the treatment of trailing whitespace in the > message contents is because that portion is hashed. What the spec > means here is that trailing whitespace is not included in the hash. > The BEGIN line is not hashed so there is no need to say what to do with > trailing whitespace there. Aha, it just clicked. "These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit." It's just forcing that anything on the armor header line isn't considered content. Thanks, David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: by above.proper.com (8.11.6/8.11.3) id g2LMmDf07979 for ietf-openpgp-bks; Thu, 21 Mar 2002 14:48:13 -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 g2LMmC407975 for ; Thu, 21 Mar 2002 14:48:12 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g2LMm2k09038; Thu, 21 Mar 2002 17:48:02 -0500 Date: Thu, 21 Mar 2002 17:48:02 -0500 From: David Shaw To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Tailing whitespace, armor lines, and clearsigned messages Message-ID: <20020321224802.GH784@akamai.com> Mail-Followup-To: Hal Finney , ietf-openpgp@imc.org References: <200203212311.g2LNBPg02925@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200203212311.g2LNBPg02925@finney.org> 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 Waxing Crescent (46% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Mar 21, 2002 at 03:11:25PM -0800, Hal Finney wrote: > David Shaw writes: > > Now here's the part I don't quite get - if it is okay to allow > > trailing whitespace in the message contents, why is it not okay to > > allow trailing whitespace after the armor header? > > The reason for specifying the treatment of trailing whitespace in the > message contents is because that portion is hashed. What the spec > means here is that trailing whitespace is not included in the hash. > The BEGIN line is not hashed so there is no need to say what to do with > trailing whitespace there. Aha, it just clicked. "These line endings are considered a part of the Armor Header Line for the purposes of determining the content they delimit." It's just forcing that anything on the armor header line isn't considered content. Thanks, David -- David Shaw | Technical Lead | Enterprise Content Delivery 617-250-3028 | Akamai Technologies Received: by above.proper.com (8.11.6/8.11.3) id g2LMJIb06934 for ietf-openpgp-bks; Thu, 21 Mar 2002 14:19:18 -0800 (PST) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LMJH406927 for ; Thu, 21 Mar 2002 14:19:17 -0800 (PST) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g2LNBPg02925; Thu, 21 Mar 2002 15:11:25 -0800 Date: Thu, 21 Mar 2002 15:11:25 -0800 From: "Hal Finney" Message-Id: <200203212311.g2LNBPg02925@finney.org> To: dshaw@akamai.com, ietf-openpgp@imc.org Subject: Re: Tailing whitespace, armor lines, and clearsigned messages Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > Now here's the part I don't quite get - if it is okay to allow > trailing whitespace in the message contents, why is it not okay to > allow trailing whitespace after the armor header? The reason for specifying the treatment of trailing whitespace in the message contents is because that portion is hashed. What the spec means here is that trailing whitespace is not included in the hash. The BEGIN line is not hashed so there is no need to say what to do with trailing whitespace there. Technically an implementation could reject messages with trailing whitespace on the BEGIN line. However this would violate the principle of "be liberal in what you accept and conservative in what you send". The right thing to do, according to this principle, is to create the BEGIN line with no trailing whitespace, and to ignore any trailing whitespace on incoming BEGIN lines. Hal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LKa1H02361 for ietf-openpgp-bks; Thu, 21 Mar 2002 12:36:01 -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 g2LKZx402357 for ; Thu, 21 Mar 2002 12:36:00 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g2LKZr303852 for ietf-openpgp@imc.org; Thu, 21 Mar 2002 15:35:53 -0500 Date: Thu, 21 Mar 2002 15:35:53 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Tailing whitespace, armor lines, and clearsigned messages Message-ID: <20020321203553.GA3498@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 Waxing Crescent (47% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I would really appreciate a bit of clarification with some of the wording in 2440bis. In section 6.2 ("Forming ASCII Armor"), the text says (and it's a MUST) that there should be nothing after the second set of dashes in the armor header line. That is: "-----BEGIN PGP SIGNED MESSAGE-----" is okay, but "-----BEGIN PGP SIGNED MESSAGE----- " is not okay due to the extra space on the end. In section 7.1 ("Dash-Escaped text"), the text says that a signature on a clearsigned message ignores trailing whitespace. I've read that the intent behind that is to give some measure of robustness to the message so it can get through mail systems that add or remove whitespace at the end of lines. Now here's the part I don't quite get - if it is okay to allow trailing whitespace in the message contents, why is it not okay to allow trailing whitespace after the armor header? If the intent behind ignoring trailing whitespace was to help with mail corruption, the fact that the message data allows trailing whitespace doesn't really help since the armor headers surrounding the message data would also become invalid with any added trailing whitespace. I do understand the armor header is not part of the message, and this is likely just another example of "be conservative in what you generate, liberal in what you accept". If I've misread this somewhere, can someone please help clarify? Thanks! 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 g26Ijbf18571 for ietf-openpgp-bks; Wed, 6 Mar 2002 10:45:37 -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 g26IjZ818567 for ; Wed, 6 Mar 2002 10:45:36 -0800 (PST) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g26IjRL04261 for ietf-openpgp@imc.org; Wed, 6 Mar 2002 13:45:27 -0500 Date: Wed, 6 Mar 2002 13:45:27 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Revocation key difficulty Message-ID: <20020306184527.GB692@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> <20020228234334.GE691@akamai.com> <008f01c1c486$773c8040$dfc32609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008f01c1c486$773c8040$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 Crescent (43% of Full) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Mar 05, 2002 at 03:43:54PM -0500, Michael Young wrote: > David Shaw noted this PGP (and now GnuPG) behavior: > > 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. > > I would argue that silently ignoring a missing revoker is a bad default. > GnuPG is generally very good about issuing warnings (and offering > options :-). Would you be willing to do so here (at least when > a potential revocation is present)? Good idea. I think a warning during key import if a key has a potential revocation on it is appropriate. > I know this doesn't thwart would-be attackers. They can always > remove the revocation itself. A warning would simply help > recognize that the key is effectively incomplete, and that the > revoker should be retrieved. (Or, have you adjusted GnuPG to > automatically retrieve revokers after retrieving a key from a server?) It doesn't, but that's a good idea as well (to be optional, of course). 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 g25KjXV00668 for ietf-openpgp-bks; Tue, 5 Mar 2002 12:45:33 -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 g25KjL800659 for ; Tue, 5 Mar 2002 12:45:31 -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 PAA28386 for ; Tue, 5 Mar 2002 15:34:45 -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 PAA12349 for ; Tue, 5 Mar 2002 15:45:12 -0500 (EST) Message-ID: <008f01c1c486$773c8040$dfc32609@transarc.ibm.com> From: "Michael Young" To: References: <20020226205856.GB5246@akamai.com> <004b01c1bfc4$f39666e0$dfc32609@transarc.ibm.com> <20020228034024.GA678@akamai.com> <003401c1c095$f0e3b700$dfc32609@transarc.ibm.com> <20020228234334.GE691@akamai.com> Subject: Re: Revocation key difficulty Date: Tue, 5 Mar 2002 15:43:54 -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 David Shaw noted this PGP (and now GnuPG) behavior: > 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. I would argue that silently ignoring a missing revoker is a bad default. GnuPG is generally very good about issuing warnings (and offering options :-). Would you be willing to do so here (at least when a potential revocation is present)? I know this doesn't thwart would-be attackers. They can always remove the revocation itself. A warning would simply help recognize that the key is effectively incomplete, and that the revoker should be retrieved. (Or, have you adjusted GnuPG to automatically retrieve revokers after retrieving a key from a server?) A signed CRL could provide the means to defeat removal attacks. I thought that I'd seen a draft that had considered some form of CRL, but I can't find it now. Did that ever come up? I understand that this requires a bunch of specification, so I can see why it might have been rejected. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPIUuAlMkvpTT8vCGEQLxDQCg+VudpJtp0Thxi10zmmUeYvWpIvQAnjFd iPLf2F3uF+S3Nopxh6SBq+3/ =JZpX -----END PGP SIGNATURE-----